How AES and IV should be used with file upload?

Question

I am developing an application in which the application tracks the user location, writes them to a file and send the file to a server periodically (in this example per hour). Then, people will decrypt and read the data from server.

I am using AES with PBE (first answer in this question)

However, since a lot of phones will use this and new IVs will be generated for each phone and each file sending operation. It looks like an overkill for me to send each IV to the server and associate them with the corresponding files in the server.

Can I use AES without IV's, like with only a password? Is this against the logic of AES? I am not experienced in Cryptography can you show me a way to overcome this "a lot of file encryption and decryption" thing?

Thanks in advance.

Answer 1

You need to ask your self "What am I protecting myself from?" then develop a security policy around that. I think you are using the wrong tools for the job and should not be using any encryption you don't understand how to set up as you will likely make major security holes in the process.

Here are a few situations I can think of what you are trying to protect and how you would solve it.

Protect someone from capturing the data as it is transmitted to your server and getting a copy of the data:
If all you need to to is protect the information between the phone and the server just use a SSL connection between you and the server. It is easy to set up and hard to mess up.

Protect peoples personal data on the server so in the event the data is stolen from the server it is not accessible:.
For this you need to encrypt the data on the server as it is "in rest". The best way to do this is use a symmetric key algorithm so it has fast encryption and decryption, the key to that algorithm should be protected by either having it only client side (but if the client looses their key client side there is no way of recovering their data, and only the device that generated the data can decrypt it so no "Web interfaces". Or you must protect the key in a way that loss of the database would not allow a attacker to decrypt the data (Like a Hardware Security Module)

Protect the data cached on the phone so if someone had root access to the phone they could not decrypt past data that the app recorded:
To do this you simply use a symmetric key to encrypt the data, then encrypt the symmetric key with your public key for the app, then delete the copy of the symmetric key on the app. With this method once the symmetric key has been deleted there is no way for the user of the app to get the data back as the only person who can recover the symmetric key is you by using your private key to decrypt the symmetric key for the data. Note that this will not protect you if someone is monitoring the app as it runs (there is no way to prevent that), this will only protect data that was recorded before the monitoring started.

I hope this helps you out and will let you make a more secure program.

_{Disclaimer: When I say "No way to decrypt" I mean no way to decrypt without using a brute force attack on the key and trying every key.}

Answer 2

You can use AES without an IV if you encrypt in ECB mode, but it's not a good idea. In ECB mode, the same plaintext always encrypts into the same ciphertext, so patterns in the plaintext can "show through" as recognizable patterns in the ciphertext. Use of ECB mode is discouraged.

To avoid the problems of ECB mode, the cipher can combine each block of the plaintext with the result of encrypting the preceding block, which is known as CBC mode. This prevents patterns in the plaintext from being recognizable in the ciphertext, since the same plaintext will produce different ciphertext depending on where it's located in the stream. But if you're combining each block with the one before it, what do you combine the first block with? That's what the IV is for.

Sending an IV together with the ciphertext isn't a big deal. It's small, just 16 bytes for AES — hardly "overkill" to transmit. Think of it as part of the encrypted file.

---

Your question brings up a related question of key management, though. AES is a symmetric cipher, which means that whoever decrypts the data needs to have the same key that the phone used to encrypt it. If you have lots of phones all sending AES-encrypted data to a server, that's lots of different keys that you have to keep track of.

(I'm assuming that each phone uses a different key, because otherwise you have no security. If all the phones encrypt using the same key, anyone who has your app can extract that key and use it to decrypt data from other people's phones.)

If you were using TLS to send data to the server, it would take care of generating a temporary encryption key for each connection, and automatically encrypting the data on the phone and decrypting it on the server. You wouldn't have to deal directly with AES at all.

But since you're implementing your crypto "manually", you also have to implement your key management manually. How does the server know the phone's key? The "right" answer would be to use Diffie-Hellman key exchange. The "wrong" answer would be for the phone to generate a key and then send it to the server, because anyone who could intercept an encrypted file could intercept the key too.

You should consider using public-key cryptography for encrypting the files sent to the server. That way, the phone only needs to know the server's public key, which doesn't need to be kept secret.

Answer 3

No. Send the randomly generated IV along with the payload. There was a flaw discovered in TLS because of predictable IVs. Don't commit the same mistake.

As further explanation, sending two messages with the same key and same IV violates the principle of semantic security. Each message should have a unique IV which is never reused in combination with the key.