Hacker News new | past | comments | ask | show | jobs | submit login

On the one hand i am glad that ECB dies officially as a mode on the other hand i wonder what NIST officially recommends when you want to encrypt data that's shorter than one block. xD

regarding finally transitioning away from SHA1: about fucking time :D




All other modes are valid for short data.

For instance the CTR mode can be used to encrypt any number of bits, down to a single bit.

The problem of the other modes vs. ECB is that they require the generation and the transmission of an "intialization vector", i.e. either a counter value or a random number, depending on the mode, so besides the short encrypted data a longer whole block must be transmitted. This can be avoided only when a set of small data are considered as parts of a long sequence of encrypted data, so the encryption mode is not reinitialized at each new message, but the last state is remembered.

ECB is a valid encryption mode only when it is used to encrypt random numbers having the length of the block (or other kind of data for which there is a strong guarantee that there will be no repeated values). It is secure for challenge-response authentication, if the challenges are unpredictable random numbers. ECB would be a perfectly secure method for encrypting other encryption keys, which must be random, except that one might want to encrypt together with the values of the keys other data, such as identifiers or error detection codes, in which case ECB could not be used to encrypt the additional non-random data.


Any other mode? You can't preserve the original length if you're authenticating anyways.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: