Re: [Cfrg] [TLS] Document on increasing the lifetime of session keys

[Евгений Алексеев <[e-mail]>]

Hello, Eric and Mihir!
One other consideration about the connection between key meshing and usage of KDFs (with session keys derived from a master key in the moment of “Key update”): they can (and in a lot of cases they should) be used together, if you have really strict limitations on key lifetime. In these cases KDF may be used for deriving keys for the message (or packet or some other block of data that is to be handled separately) and key meshing to make it possible to handle rather long messages.
For example, if you have to limit key usage with 4 KB (e.g. your potential adversary has truly powerful capabilities of intercepting side-channel leakage of a key on operations with it) and you handle messages of variable length, you can KDF a new session key for each message and then work as usual – knowing that when the length of a message exceeds 4 KB, key meshing will work and you would be able to continue working. And it’ll be done transparently – just like you are using a modified block cipher mode, which expands key lifetime.
Otherwise you’ll have either to limit the size of messages (which is not always suitable), or get several KDFed session keys from the master key for a message if it’s long enough – which means hard fragmentation of messages and additional costs for starting/stopping encryption thread.
 --  Regards,
Evgeny Alekseev
CryptoPro


>Воскресенье, 28 августа 2016, 17:42 +03:00 от "Stanislav V. Smyshlyaev" <[e-mail]>:
>
>‎Dear Eric,
>
>Thank you for your comment - indeed, re-keying mechanisms based on secret state are widely used in the protocols (key trees are usual practice in ESP with GOSTs for more than 10 years, for example). My point is that a simple (e.g. without any additional keys or structures) and effective mechanism to increase ‎block cipher modes limitations on plaintext size can be helpful itself, without incorporating to a protocol. 
>
>About connection with TLS 1.3 draft - for example, we don't want the GCM mode be defined inside some protocol RFC, it should be defined separately, isn't it?  So the question is that if such mechanisms are needed, than separate documents on them can be a better solution.
>
>And my primary point here is about stateless techniques: as follows from t‎he preprint I cited before, the key lifetime for CTR can be increased quadratically, for example. 
>
>Kindest regards,
>Stanislav
>
>От:  Eric Rescorla
>Отправлено:  воскресенье, 28 августа 2016 г., 16:52
>Кому:  Stanislav V. Smyshlyaev
>Копия:  [e-mail]; Mihir Bellare; Paul Lambert; Paterson, Kenny; Mike Hamburg; < [e-mail] >
>Тема:  Re: [TLS] Document on increasing the lifetime of session keys
>
>Stanislav,
>
>TLS 1.3 incorporates a rekeying mechanism (KeyUpdate) similar to that if Abdalla and Bellare 1(b).
>
>-Ekr
>
>
>On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev  < [e-mail] > wrote:
>>Dear colleagues,
>>Since there is a considerable interest to the question of increasing session keys lifetime (several productive off-the-list personal discussions about CryptoPro key meshing algorithms and  http://eprint.iacr.org/2016/628  started after the Friday posting), maybe we should think about getting started a work on a document on efficient re-keying (about techniques without secret state and/or techniques with it (like in M. Abdalla and M. Bellare work,  https://cseweb.ucsd.edu/~mihir/papers/rekey.html )) mechanisms for common cipher modes (CTR, CCM, GCM, CBC, CFB) in CFRG? 
>>If you consider it reasonable, we can prepare a first version of such a draft based on our results (both included in that our preprint and new ones which we are working on currently) before IETF 97 to be able to have a discussion on this issue there in Seoul.
>>Kindest regards,
>>Stanislav Smyshlyaev
>>_______________________________________________
>>TLS mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg