Huge +1 to this I-D, just some minor comments:
* I wonder if the document should be more forthright in specifying that the
ChaCha20/Poly1305 implementations SHOULD actually attempt to use
constant-time and constant-access patterns that the algorithm is designed
to facilitate. If that's a selling p
On 3 November 2015 at 08:02, Brian Smith wrote:
>> The major change in this version is that the nonce is constructed
>> using the scheme that's currently in TLS 1.3.
>
>
> Would it be possible to do something similar for the additional data, so
> that there is no additional data in TLS 1.2, just l
Adam Langley wrote:
> The major change in this version is that the nonce is constructed
> using the scheme that's currently in TLS 1.3.
>
Would it be possible to do something similar for the additional data, so
that there is no additional data in TLS 1.2, just like in TLS 1.3 for
application_dat
> On 3 Nov 2015, at 4:59 AM, Brian Smith wrote:
>
> Watson Ladd mailto:watsonbl...@gmail.com>> wrote:
> For these results a
> sender of 2^60 messages can tolerate 2^60 forgery attempts while the
> probability of forgery is at most 1.002/2^52.
>
> TLS only allows one forgery attempt per connecti
On Mon, Nov 2, 2015 at 2:06 PM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security Working Group of
> the IETF.
>
> Title : ChaCha20-Poly1305 Cipher Suites for Transport Layer
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : ChaCha20-Poly1305 Cipher Suites for Transport Layer
Security (TLS)
Authors : Adam Langl
Now, you talked about a MAC function (with AES). I previously talked about
encryption.
If I , the only person, uses the MAC key, when I generate more than 2^64 MAC
values (Let's say each MAC value is 96 bits), I have many collided MAC pairs.
But, I am the only one (beside the person(s) verifyi
Watson Ladd wrote:
> For these results a
> sender of 2^60 messages can tolerate 2^60 forgery attempts while the
> probability of forgery is at most 1.002/2^52.
TLS only allows one forgery attempt per connection (thus per key). That is,
as soon as a TLS implementation fails to verify a record's
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : Transport Layer Security (TLS) False Start
Authors : Adam Langley
Dear all,
All modes have a limit on how much data can be encrypted before bad
things start to happen, i.e. IND-$ becoming false, or authenticity
becoming false. In this email I will discuss what those limits are for
AES-GCM and ChaCha20-Poly1305, assuming the usual assumptions about
the ciphers: t
Hi,
We've posted a new version of "Use of KCipher-2 with Poly1305
in Transport Layer Security" (draft-kiyomoto-kcipher2-tls-02)
that address to add a cipher suite, KCipher-2 [RFC7008] and
Poly1305 running with AEAD for TLS1.2.
Name: draft-kiyomoto-kcipher2-tls
Revision: 02
Title:
Hi,
We've posted a new version of “Use of KCipher-2 with Poly1305
in Transport Layer Security” (draft-kiyomoto-kcipher2-tls-02)
that address to add a cipher suite, KCipher-2 [RFC7008] and
Poly1305 running with AEAD for TLS1.2.
Name: draft-kiyomoto-kcipher2-tls
Revision: 02
Title:
On Nov 2, 2015 2:14 AM, "Dang, Quynh" wrote:
>
> Hi Eric,
>
>
> As you asked the question about how many ciphertext blocks should be safe
under a single key, I think it is safe to have 2^96 blocks under a given
key if the IV (counter) is 96 bits.
This is wrong for PRP, right for PRF. It's not tha
13 matches
Mail list logo
