On Wed, Apr 18, 2012 at 9:04 AM, Edward Ned Harvey <open...@nedharvey.com> wrote: >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >> us...@openssl.org] On Behalf Of Jeffrey Walton >> >> On Tue, Apr 17, 2012 at 9:47 PM, Edward Ned Harvey >> <open...@nedharvey.com> wrote: >> >> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- >> >> us...@openssl.org] On Behalf Of Ken Goldman >> >> >> >> The standard answer: If this is a real security project, hire an >> >> expert. If you design your own crypto algorithm, you will get it wrong. >> >> >> >> If this is just for fun, to learn about openssl, CTR mode will give you >> >> random access. >> > >> > The thing about CTR mode is that it needs a nonce. >> NIST 800-38A approves two ways to use counter mode. See Appendix B for >> guidance on choosing the initial value and the increment function. > > I think what you're saying is that it doesn't necessarily need to be a nonce, > and it doesn't necessarily need to be a increment (++), as long as you have > any method for ensuring uniqueness and generating sequentially unique counter > blocks across all messages. Right? Or have I missed the point? > > This seems to affirm what I said - If you're using CTR mode, you'll need to > store something (be it a second key, or a nonce, or something functionally > equivalent) encrypted along with your encrypted data. Whatever you choose as > your incrementing function is irrelevant, as long as it satisifes the > conditions of being sequentially repeatable, and always unique. ... If > you're doing something like my other suggestion - encrypting the block number > and then using the result as the IV - it satisfies all the requirements > described in Appendix B, where m=128 (in other words, you have no nonce, and > you're using all the bits for incrementing function.) There's an important > restriction there - Presumably Maumau would want to encrypt more than one > file. He'll either need to treat all the blocks of all the files as > sequential blocks, or choose a different key for each file. > > It seems, no matter how you cut it, you'll need a different key (or nonce or > something unique) for each file. > > Furthermore, as Matt said, it works fine if you write once and read many > times. But if you want to write a block, then change it, then change it back > to what it used to be... Given the same key, plaintext, and IV, the block > cipher will produce the same output. So an attacker could know you changed > it, and then put it back. Maybe you don't care about that, but ideally you > would have a way of keeping track of a new key/nonce/whatever ... Encryption alone is usually not enough. You should be able to detect copy/paste attacks with an authenticator. http://www.codeproject.com/Articles/34380/Authenticated-Encryption.
Disk blocks are kind of unique in that you usually can't tolerate the authentication tag. See "AES-CBC + Elephant diffuser: A Disk Encryption Algorithm for Windows Vista" by Niels Furgeson and the way Microsoft attempted to solve it using Poor Man's Authentication. http://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608.pdf. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
