> 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 ... ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
