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" ><smys...@gmail.com>: > >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 the >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 >Копия: c...@irtf.org; Mihir Bellare; Paul Lambert; Paterson, Kenny; Mike >Hamburg; < tls@ietf.org > >Тема: 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 < smys...@gmail.com >> 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 >>TLS@ietf.org >>https://www.ietf.org/mailman/listinfo/tls >> > > >_______________________________________________ >Cfrg mailing list >c...@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
