I am using encryption/decryption between Objective c(iPad end) and C#(.net, server site). I am using code from this link:
iPhone/C# AES Encryption
We are encrypting a XML on server end and sending it to iPad end using web services. At the iPad end when i am trying to decrypt, it is creating decrypted data but is not able to convert that data into the string. There is some problem coming in converting data into string using NSUTF8StringEncoding.
Before sending from server to iPad we are converting it into base64 String.
The same XML file when encrypted and decrypted at iPad end works fine.
I believe there are some special characters in the encrypted data coming from from server end ,therefore it is not decrypted at iPad end.
Can anybody give me any suggestion on this.
Thank you!
You can not send encrypted string over the network.
you need to convert encrypted NSString into Base64 String.
Then send this Base 64 string to ipad.
Related
I have a SQL Server table with 1 column containing encrypted data.
The data was encrypted using the answer provided by #CraigTP to this question... Encrypting & Decrypting a String in C#
I need to retrieve & decrypt this data using only T-SQL. Is that possible? How?
Where should I store the IV (byte array) needed for AES decryption in my Android app? I've tried converting it to a string in Base64 and saving it to shared preferences, but kept getting a bad padding exception. I tried to change the padding, but it didn't work.
I also saved the IV (byte array) to the keystore's provider and that worked, but while debugging in Visual Studio for Mac, the provider's content (in this case the IV) gets erased every time I run the app. The provider is still there but nothing is saved in the provider. Android's documentation says that "Each provider... is configured in each runtime it is installed in." Will this be an issue once the app is installed on an actual device?
I am coding in c# in Visual Studio for Mac.
Edit
this is my code using Base64 encoding:
string ivString = Base64.EncodeToString(ivByteArray, Base64Flags.Default);
byte[] decodedIV = Base64.Decode(ivString, Base64Flags.Default);
when I print out the original byte array and the decoded byte array, they are exactly the same but I keep getting a bad padding exception
I am using AES, CBC, and EncryptionPaddingPkcs7
I've tried converting it to a string in Base64 and saving it to shared preferences, but kept getting a bad padding exception.
Storing IV in SharedPreferences should work. You probably got a base64 encoding issue.
I also saved the IV (byte array) to the keystore's provider and that worked, but while debugging in Visual Studio for Mac, the provider's content (in this case the IV) gets erased every time I run the app.
A java.security.Provider it is not the place to store a bytearray. Do you mean Android Keystore System or other implementation of java.security.KeyStore. Please be specific
Where to store IV that is needed for decryption in Android app?
Just prepend the initialiation vector to the ciphertext
[IV][ciphertext]
Whatsapp is change the message db to .crypt 7, and now my little app that written in c# not working now (i have a little app for myself for viewing my history chats) because it written for old crypt db of whatsapp.
Now, i see that whatsapp is useing new crypt - .crypt7 - what is it? and how i can convert it? i see also have there local key for decrypt? how i can use it with my little c# for decrypt and read it?
Thanks!
You have to get encryption key. if you have root, you can copy /data/data/com.whatsapp/files/key here. As far as i know whatsapp using "aes" for encryption.
A college's mailroom is in dire need of new software to help with their operations. The current program was written back in the early '90s in what they believe is python. Two others and myself, are modernizing it. I am in charge of the networking and the server. The school requires that we encrypt any sensitive student data being sent across the network. Since we are using two different languages (Java and C#), I had to do a little digging to find the commonalities in encryptions. AES128/CBC/ISO10126 is the common one. The problem I am having, is that if I send to the client, the server key and IV so that the client can encrypt and return the session key and IV, when the server reads it I am missing 3 bytes of data and I cant get it to decrypt at all. Here is how I am reading on the server side after something is sent back
ICryptoTransform decrypter = myProvider.CreateDecryptor(myProvider.Key, myProvider.IV);
byte[] sKey = new byte[myClient.ReceiveBufferSize];
Console.WriteLine(ASCIIEncoding.ASCII.GetString(sKey));
Console.WriteLine("Key Length: " + sKey.Length);
byte[] sessionKey = new byte[sKey.Length];
sessionKey = decrypter.TransformFinalBlock(sessionKey, 0, sessionKey.Length);
Any ideas what might be causing me to somehow drop 3 bytes of data? Normally I wouldn't be upset, but the three bytes are important to a secure connection.
I am trying to encrypt a file when I save it to disk and I have looked at the Crypto namespace in C#, but am unsure how I should do it. Basically I need the ability for my program to be able to both encrypt and decrypt a file. The file is just an xml file that is serialized by my program, but it can contain sensitive data like connection strings for SQL servers. My clients want the ability to email these profiles to others and open them in our application to apply the settings to their system.
I tried the AES classes in the Crypto namespace, but I don't know where to store the IV and the key so that my program on another machine will be able to decrypt it.
In a typical scenario, the flow for handling something like this would go:
The IV is static and known to the client
The end machine generates an RSA keypair, and gives the public key only to the party sending the data (the XML file)
Your AES key is generated, and encrypted using the RSA public key and sent to the client, now only the client is able to obtain that AES key using the private key it generated previously.
You encrypt the data using the AES key you securely sent to the client earlier
This means that even if someone captured the complete data stream, they wouldn't be able to decrypt your data because they don't have the private key required to obtain the AES key.