Hi Quynh:
Not sure where to start (there is vast literature on side channel
attacks and other implementation attacks). A good starting point would
be the book [1], but one could also look at some NIST publications [2].
Side channel attacks differs from cryptanalytic attacks in that it does
not merely study I/O behavior of crypto contructs, but also looks into
what information can be obtained from what is going on "under the hood"
of the computations (power consumption, radiation, timing, etc; or even
invasive attacks). Most commonly one looks at crypto building blocks,
but ultimately side channels can comprise any system behavior ("Lucky13"
does, e.g., exploit this, if I remember correctly).
From the last page of [2]: Finally, the most important conclusion from
this paper is that it is not only a necessity but also a must, in the
coming version of FIPS 140-3 standard, to evaluate cryptographic modules
for their resistivity against SCA attacks.
Ref:
[1] Stefan Mangard, Elisabeth Oswald, Thomas Popp, "Power Analysis
Attacks - Revealing the Secrets of Smart Cards", Springer, 2007.
[2]
http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-3/physec/papers/physecpaper19.pdf
[2]
On 2/10/2017 1:47 PM, Dang, Quynh (Fed) wrote:
Hi Rene,
From: TLS <tls-boun...@ietf.org <mailto:tls-boun...@ietf.org>> on
behalf of Rene Struik <rstruik....@gmail.com
<mailto:rstruik....@gmail.com>>
Date: Friday, February 10, 2017 at 10:51 AM
To: Sean Turner <s...@sn3rd.com <mailto:s...@sn3rd.com>>,
"<tls@ietf.org <mailto:tls@ietf.org>>" <tls@ietf.org
<mailto:tls@ietf.org>>
Cc: IRTF CFRG <c...@irtf.org <mailto:c...@irtf.org>>
Subject: Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
(#765/#769)
Dear colleagues:
I would suggest adding the following paragraph at the end of
Section 5.5:
[current text of Section 5.5]
There are cryptographic limits on the amount of plaintext which
can be safely encrypted under a given set of keys.[AEAD-LIMITS]
<https://tlswg.github.io/tls13-spec/#AEAD-LIMITS>provides an
analysis of these limits under the assumption that the underlying
primitive (AES or ChaCha20) has no weaknesses. Implementations
SHOULD do a key updateSection 4.6.3
<https://tlswg.github.io/tls13-spec/#key-update>prior to reaching
these limits.
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may
be encrypted on a given connection while keeping a safety margin
of approximately 2^-57 for Authenticated Encryption (AE) security.
For ChaCha20/Poly1305, the record sequence number would wrap
before the safety limit is reached.
[suggested additional text]
The above upper limits do not take into account potential side
channel attacks, which - in some implementations - have been shown
to be successful at recovering keying material with a relatively
small number of messages encrypted using the same key. While
results are highly implementation-specific, thereby making it hard
to provide precise guidance, prudence suggests that
implementations should not reuse keys ad infinitum.
Implementations SHALL therefore always implement the key update
mechanism of Section 4.6.3.
{editorial note: perhaps, one should impose the limit 2^20, just
to make sure people do not "forget" to implement key updates?}
How do you do side channel attacks on TLS ? Do these side-channel
attacks work for AES-GCM only in TLS 1.3 ?
See also my email of August 29, 2016:
https://mailarchive.ietf.org/arch/msg/cfrg/SUuLDg0wTvjR7H46oNyEtyGVdno
On 2/10/2017 12:07 AM, Sean Turner wrote:
All,
We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13
Section 5.5 “Limits on Key Usage”. As it relates to rekeying, these limits
have been discussed a couple of times and we need to resolve once and for all
whether the TLS WG wants to:
a) Close these two PRs and go with the existing text [0]
b) Adopt PR#765 [1]
c) Adopt PR#769 [2]
Please indicate you preference to the TLS mailing list before Feb 17. Note
that unless there’s clear consensus to change the text will remain as is (i.e.,
option a).
J&S
[0]https://tlswg.github.io/tls13-spec/#rfc.section.5.5
[1]https://github.com/tlswg/tls13-spec/pull/765
[2]https://github.com/tlswg/tls13-spec/pull/769
_______________________________________________
Cfrg mailing list
Cfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
--
email:rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
