Aes which mode to use

Note: if not stated otherwise everything applies equally to Java and Android. In our example we use a randomly generated bit key. Java will automatically choose the correct mode when you pass a key with and bit length. Then we have to create our initialization vector.

For GCM a 12 byte not 16! Then initialize your cipher. If it happens to be not available install a custom crypto provider like BouncyCastle , but the default provider is usually preferred. We choose an authentication tag of size bit. Add optional associated data if you want for instance meta data. Encrypt; if you are encrypting big chunks of data look into CipherInputStream so the whole thing doesn't need to be loaded to the heap. Now concat all of it to a single message.

Optionally encode it with e. Base64 if you require a string representation. Android does have a standard implementation of this encoding, the JDK only from version 8 on I would avoid Apache Commons Codec if possible since it is slow and a messy implementation.

For constructing the message, the IV, the encrypted data and the authentication tag are appended to a single byte array. It is best practice to try to wipe sensible data like a cryptographic key or IV from memory as fast as possible. Be mindful to not overwrite data that is still used somewhere else. Now to the decrypt part; It works similar to the encryption.

Initialize the cipher with the IV and add the optional associated data and decrypt:. There are 3 properties we want for securing our data. Just consider the following:. Security is my passion. Sign in.

Submit Archive About Events droidcon. Patrick Favre-Bulle Follow. Summary There are 3 properties we want for securing our data Confidentiality: The ability to prevent eavesdroppers from discovering the plaintext message, or information about the plaintext message. Integrity: The ability to prevent an active attacker from modifying the message without the legitimate users noticing. Authenticity — The ability to prove that a message was generated by a particular party, and prevent forgery of new messages.

Note that authenticity automatically implies integrity. Just consider the following: Use a 12 byte initialization vector that is never reused with the same key use a strong pseudorandom number generator like SecureRandom Use a bit authentication tag length Use a bit key length you will be fine!

Per default…. ProAndroidDev Follow. Written by Patrick Favre-Bulle Follow. More From Medium. Stephen Vinouze. Fahri Can in Nerd For Tech. Tony Tannous. UI Automator Testing Recyclerview. Pratik To get the next block of keystream the previous block of keystream is encrypted again, with the same key.

This is repeated until enough keystream is generated for the entire length of the message. This is fine in theory, but in practice there are questions about its safety. Block transforms are designed to be secure when performed once, but there is no guarantee that E E m,k ,k is secure for every independently secure block cipher - there may be strange interactions between internal primitives that haven't been studied properly.

If implemented in a way that provides partial block feedback i. In general you should avoid OFB. CFB - Cipher Feedback. Another stream cipher mode, quite similar to CBC performed backwards. Its major advantage is that you only need the encryption transform, not the decryption transform, which saves space when writing code for small devices.

It's a bit of an oddball and I don't see it mentioned frequently. CTR - Counter Mode. This essentially involves encrypting a sequence of incrementing numbers prefixed with a nonce number used once to produce a keystream, and again is a stream cipher mode. This mode does away with the problems of repeatedly running transforms over each other, like we saw in OFB mode.

It's generally considered a good mode. Bad points: Not many. Some question the security of the "related plaintext" model but it's generally considered to be safe. Padding modes can be tricky, but in general I would always suggest PKCS 7 padding, which involves adding bytes that each represent the length of the padding, e.

The benefit over some other padding mechanisms is that it's easy to tell if the padding is corrupted - the longer the padding, the higher the chance of random data corruption, but it also increases the number of copies of the padding length you have.

It's also trivial to validate and remove, with no real chance of broken padding somehow validating as correct. That being said, there are new modes! The primary benefit is that both are authenticated modes , in that they build the authenticity checks into the cipher mode itself, rather than having to apply one separately. This fixes some problems with padding oracle attacks and various other trickery. These modes aren't quite as simple to explain let alone implement but they are considered to be very strong.

Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Attacks and poor provable-security bounds in the presence of substantial tag truncation. Questionable choice to allow nonces other than bits. Recommend restricting nonces to bits and tags to at least 96 bits.

You might want to chose based on what is widely available. I had the same question and here are the results of my limited research. Have you start by reading the information on this on Wikipedia - Block cipher modes of operation?

I know one aspect: Although CBC gives better security by changing the IV for each block, it's not applicable to randomly accessed encrypted content like an encrypted hard disk. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Ask Question. Asked 12 years, 3 months ago.

Active 9 months ago. Viewed k times. Which of them are preferred in which circumstances? See what I mean by "list of evaluation criteria and applicability of each criterion"?? This isn't really programming related but it is algorithm related. Cheeso Cheeso k 95 95 gold badges silver badges bronze badges. Add a comment. Active Oldest Votes. Please consider long and hard if you can't get around implementing your own cryptography The ugly truth of the matter is that if you are asking this question you will probably not be able to design and implement a secure system.

What to do if you need to encrypt data For live connections use TLS be sure to check the hostname of the certificate and the issuer chain. Comparison of the modes Encryption only: Modes that require padding : Like in the example, padding can generally be dangerous because it opens up the possibility of padding oracle attacks. The easiest defense is to authenticate every message before decryption.

See below. ECB encrypts each block of data independently and the same plaintext block will result in the same ciphertext block. I don't know of any use case where ECB would be acceptable. Stream cipher modes : These modes generate a pseudo random stream of data that may or may not depend the plaintext.

Similarly to stream ciphers generally, the generated pseudo random stream is XORed with the plaintext to generate the ciphertext. As you can use as many bits of the random stream as you like you don't need padding at all. That also means that changing the message requires complete reencryption, if the original message could have been obtained by an attacker.

All of the following steam cipher modes only need the encryption operation of the block cipher, so depending on the cipher this might save some silicon or machine code space in extremely constricted environments.

For efficiency reasons changing some data on the disc must only require the rewrite of at most one disc block bytes or 4kib. They are out of scope of this answer as they have vastly different usage scenarios than the other. Don't use them for anything except block level disc encryption.

Authenticated encryption: To prevent padding oracle attacks and changes to the ciphertext, one can compute a message authentication code MAC on the ciphertext and only decrypt it if it has not been tampered with. Using two block cipher encryptions per block it is very slow. OCB is faster but encumbered by patents.

For free as in freedom or non-military software the patent holder has granted a free license , though. Its wide use in important network standards like TLS 1. Recommendation: Considering the importance of authentication I would recommend the following two block cipher modes for most use cases except for disk encryption purposes : If the data is authenticated by an asymmetric signature use CBC, otherwise use GCM.

Perseids Perseids So maybe relax a little. RobertMacLean True, but in contrary to a lot of other fields in IT you won't get security right by try and error. Whereas with web design, application scalability etc you can actively check your requirements, testing security aspects ranges from hard to impossible.

Unfortunately that is a lesson that is seldom taught. Most resources tell you how cryptography works and not the myriad ways it fails in practice without you even being aware of it. The only way out is to know a lot about the subject.

And that's the morale of the post: — Perseids. Either invest enough time to get to know cryptography thoroughly or avoid it as far as possible and use strong abstractions. And in the theme of learning how cryptography breaks the first paragraph is much more on-topic than the description of the modes.

Minus one: the starting headline is wrong; it should say "If you're asking this question you're going in the right direction, keep it up and you'll excel! FerminSilva: True, but another aspect of the argument is that it is often easier to use true and tested solutions than to copy-paste crypto code. Show 24 more comments. ECB should not be used if encrypting more than one block of data with the same key. CTR is used if you want good parallelization ie.

If you cannot guarantee they are random , use OCB as it only requires a nonce , not an IV , and there is a distinct difference. A nonce does not drop security if people can guess the next one, an IV can cause this problem. Erwan Legrand 3, 25 25 silver badges 26 26 bronze badges. CTR is amenable to parallelization because you can split the message into chunks, each chunk having a range of counter values associated with it, and encrypt or decrypt each chunk independently.

By contrast, CFB relies on the output from the previous block as one of the inputs to the next, so it is rigorously sequential and inherently non-parallelizable. Similar for the other modes mentioned. Even if you are encrypting only one block, ECB should not be used if you will be encrypting that one block more than once even possibly more than once with the same key.

GCM is very similar to OCB performance and other properties , but it is not encumbered by any patents, so it is the best choice.

The only downside is the fact that the implementation is highly complex — but you don't have to worry about that if you use a library. Show 6 more comments. I am not aware of IP issues. Now to the good stuff from Professor Rogaway: Block ciphers modes, encryption but not message integrity ECB : A blockcipher, the mode enciphers messages that are a multiple of n bits by separately enciphering each n-bit piece.

GCM mode: Given that most on SO have little to no knowledge of encryption, will not use any mode correctly, generally not using authentication and often using ECB mode GCM mode is probably they best choice here. Unfortunately the lack of platform implementations, in some cases iOS no vendor support, poor vetting in many cases lack of hardware support it is currently problematic. Otherwise it is good for the uninitiated in encryption since it has authentication built in and seems to be the future.

Even Microsoft has screwed this up at least a couple of times. Padding Oracles, while an issue, are easily remediated by simply ignoring and not returning padding errors. Some implementations e. Common Crypto do not report padding errors in an essentially successful way of avoiding them at the API level.

It may seem easy but there have been major failures in mass market code. If you are claiming that one can recover keys when an IV is reused for AES-CTR, then you would be the first to be making such a claim, and the burden would be upon you to provide evidence.

Honestly, I can promise you that that claim simply is not true. Show 17 more comments.