rakesh aggarwal wrote:
As far as I understand the RFCs (and English in general ;-) ), there exists the ability for anyone to implement it's "own" CTR mode, as the RFC says : " The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs)." This lets you choose the size(s) of the counter(s) into the IV, even the ability to keep part of this IV as a random value. Well, at least some "private" implementation of the CTR as been done like that on top of openssl library by a subcontractor for some crypto oriented project (file encryption, not network oriented) we once had. In this implementation the IV is composed of three parts : a "high level" counter, a "low level" one and an initially (when counters are set to zero) random value. On some conditions linked to overall volume and counter values, the random part may be changed, or even the key renewed. And I can't find how this implementation is bending the rules of this RFC3686. But as I said as a preamble, I may well be wrong due to my misunderstandings. -- Luc Perthuis, Team Leader, Backup and Restore Technologies luc.perth...@atempo.com T +33 (0)2 97 68 40 26 | M +33 (0)6 89 16 96 37 http://www.atempo.com Atempo | Data Management, Simplified.______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org |
- Complete implementation for CTR mode rakesh aggarwal
- Re: Complete implementation for CTR mode Luc Perthuis