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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sun, 28 Aug 2016 13:48:01 +0300

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Aug 2016 06:51:52 -0700

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 <[email-masked]>
wrote:

> about CryptoPro key meshing algorithms and http://eprint.iacr.org/2016/628 started
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sun, 28 Aug 2016 17:42:20 +0300

‎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

Копия: [email-masked]; Mihir Bellare; Paul Lambert; Paterson, Kenny; Mike Hamburg; <[email-masked]>

Тема: 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 <[email-masked]> 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

[email-masked]

---

From: Евгений Алексеев <[email-masked]>
Date: Wed, 31 Aug 2016 19:02:59 +0300

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" <[email-masked]>:
>
>‎Dear Eric,
>
>Копия:  [email-masked]; Mihir Bellare; Paul Lambert; Paterson, Kenny; Mike Hamburg; < [email-masked] >
>On Sun, Aug 28, 2016 at 3:48 AM, Stanislav V. Smyshlyaev  < [email-masked] > 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? 
>Cfrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/cfrg