Re: [TLS] [Cfrg] Collision issue in ciphertexts.

[Watson Ladd]

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 that hard to find the right
result.

>
>
> When there is a collision between two ciphertext blocks when two
different counter values are used , the chance of the same plaintext was
used twice is 1^128.  Collisions start to happen a lot when the number of
ciphertext blocks are above 2^64. However, each collision just reveals that
the corresponding plaintext blocks are probably different ones.

Which breaks IND-$. Let's not be clever, but stick to ensuring proven
definitions are true.

>
>
>
> Quynh.
>
>
> ___
> 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

[TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02)

[Yoshiaki Hori]

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:  Use of KCipher-2 with Poly1305 in Transport Layer Security
Document date:  2015-11-01
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-02.txt
Status:
https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
Htmlized:   https://tools.ietf.org/html/draft-kiyomoto-kcipher2-tls-02
Diff:
https://www.ietf.org/rfcdiff?url2=draft-kiyomoto-kcipher2-tls-02

Abstract:
   This document describes the use of the KCipher-2 stream cipher with
   Poly1305 in Transport Layer Security (TLS) protocols version 1.2 and
   Datagram Transport Layer Security (DTLS) protocols.  KCipher-2 is a
   stream cipher with a 128-bit key and a 128-bit initialization vector,
   which provides fast, efficient encryption and decryption.

We address alternative stream cipher suite for TLS because we
concern a risk of “single stream cipher suite, Chacha20 with
Poly1305. Our colleague is preparing KCipher-2 with Poly1305
code based on openssl-1.0.2 which will be available as an open
source soon.

The current Kcipher-2 with Poly1305 implementation can run with
around 60% or more throughput comparing with Chacha20-Poly1305
under a small block size, e.g. 16 bytes and 64 bytes.
We expect performance improvement with further optimization
because the current code development in an early stage.

We have tentative two performance reports run with different
environment, which are indicated with [i] and [k] respectively.
The case [i] is running with Intel(R) Core(TM) i5-4300U
CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.
Also, the case [k] is with Intel(R) Core(TM) i7-4770K 3.50GHz /
 Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10
64bit with 7GB / gcc 4.9.1.

Performance Results:

(1) in case [i] environment: with Intel(R) Core(TM) i5-4300U
CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.

chacha20-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
  16   31,586.83
  64  101,580.14
 256  188,614.93
1024  248,756.57
8192  272,231.08

kc2-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
  16   16,938.10
  64   54,679.51
 256  156,798.30
1024  294,867.97
8192  388,743.17

(2) in case [k] environment: with Intel(R) Core(TM) i7-4770K
3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS:
Ubuntu 14.10 64bit with 7GB / gcc 4.9.1

chacha20-poly1305 with no-SIMD [k]:

block size [byte]   throughput [kbytes/sec]
  16   51,704.44
  64  173,918.85
 256  403,878.27
1024  616,232.62
8192  721,810.77

kc2-poly1305 [k]:

block size [byte]   throughput [kbytes/sec]
  16   30,338.55
  64  101,063.15
 256  284,340.82
1024  544,837.63
8192  736,327.00

Yoshiaki Hori
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02)

[堀 良彰]

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:  Use of KCipher-2 with Poly1305 in Transport Layer Security
Document date:  2015-11-01
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-tls-02.txt
Status:
https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/
Htmlized:   https://tools.ietf.org/html/draft-kiyomoto-kcipher2-tls-02
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-kiyomoto-kcipher2-tls-02

Abstract:
   This document describes the use of the KCipher-2 stream cipher with
   Poly1305 in Transport Layer Security (TLS) protocols version 1.2 and
   Datagram Transport Layer Security (DTLS) protocols.  KCipher-2 is a
   stream cipher with a 128-bit key and a 128-bit initialization vector,
   which provides fast, efficient encryption and decryption.

We address alternative stream cipher suite for TLS because we
concern a risk of single stream cipher suite, Chacha20 with
Poly1305. Our colleague is preparing KCipher-2 with Poly1305
code based on openssl-1.0.2 which will be available as an open
source soon.

The current Kcipher-2 with Poly1305 implementation can run with
around 60% or more throughput comparing with Chacha20-Poly1305
under a small block size, e.g. 16 bytes and 64 bytes.
We expect performance improvement with further optimization
because the current code development in an early stage.

We have tentative two performance reports run with different
environment, which are indicated with [i] and [k] respectively.
The case [i] is running with Intel(R) Core(TM) i5-4300U
CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.
Also, the case [k] is with Intel(R) Core(TM) i7-4770K 3.50GHz /
 Host OS: Windows 7 64bit with 32GB / Guest OS: Ubuntu 14.10
64bit with 7GB / gcc 4.9.1.

Performance Results:

(1) in case [i] environment: with Intel(R) Core(TM) i5-4300U
CPU@1.90GHz 2.50GHz / RAM 8.00GB / openSUSE13.2 64bit.

chacha20-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
  16   31,586.83
  64  101,580.14
 256  188,614.93
1024  248,756.57
8192  272,231.08

kc2-poly1305 [i]:

block size [byte]   throughput [kbytes/sec]
  16   16,938.10
  64   54,679.51
 256  156,798.30
1024  294,867.97
8192  388,743.17

(2) in case [k] environment: with Intel(R) Core(TM) i7-4770K
3.50GHz / Host OS: Windows 7 64bit with 32GB / Guest OS:
Ubuntu 14.10 64bit with 7GB / gcc 4.9.1

chacha20-poly1305 with no-SIMD [k]:

block size [byte]   throughput [kbytes/sec]
  16   51,704.44
  64  173,918.85
 256  403,878.27
1024  616,232.62
8192  721,810.77

kc2-poly1305 [k]:

block size [byte]   throughput [kbytes/sec]
  16   30,338.55
  64  101,063.15
 256  284,340.82
1024  544,837.63
8192  736,327.00

Yoshiaki Hori

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe?

[Watson Ladd]

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: that is PRP for AES and PRF for ChaCha20. These limits
are due to Iwata et. al. and Bernstein. All I have done in this email
is evaluate them carefully.

We start by noting that TLS encrypts messages of at most 2^14 bytes,
and so at most 2^16 16-byte blocks. This is a ridiculous overestimate,
but it doesn't need to be tightened, as I will explain later.

Bernstein proves general results on Carter-Wegman authenticators,
found in http://cr.yp.to/papers.html#securitywcs. 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. I think that's
sufficient. These apply to AES-GCM. For ChaCha20-Poly1305 there is a
different result where the number of messages does not appear, but
only the length: this result gives a much stronger 1/2^87. This is due
to generating a different authentication key for every nonce.

ChaCha20 is a PRF. As a result we can go beyond the birthday bound,
and send use all 2^96 messages.

AES is a PRP. Therefore there is a quadratic security loss, and the
result from Iwata-Ohashai-Minematsu states the probability of success
is upper bounded by (s+q+1)^2/2^127, where s is the total number of
blocks encrypted and q the number of queries made by the attacker. The
sum must therefore be below 2^32 to have the same level of security as
the authenticator, and so we are limited to a total amount of
encryption with a given key of 2^32 blocks, or 2^36 bytes. We could be
slightly more aggressive, but cannot hit anywhere close to 2^64.

Please double-check the above analysis, in particular the assumptions
about how ChaCha20-Poly1305 actually works.  I haven't dug up other
recommendations to see if I got in the right ballpark.

Sincerely,
Watson

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-falsestart-01.txt

[internet-drafts]

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
  Nagendra Modadugu
  Bodo Moeller
Filename: draft-ietf-tls-falsestart-01.txt
Pages   : 10
Date: 2015-11-02

Abstract:
   This document specifies an optional behavior of TLS client
   implementations, dubbed False Start.  It affects only protocol
   timing, not on-the-wire protocol data, and can be implemented
   unilaterally.  A TLS False Start reduces handshake latency to one
   round trip.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-falsestart-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-falsestart-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe?

[Brian Smith]

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 authentication
tag, it must shut down the connection. Thus, it would be more useful to
state the analysis as "Observing X signed records over Y bytes increases
the odds of the attacker forging the next record to Z."

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] Collision issue in ciphertexts.

[Dang, Quynh]

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) verifying my MACs) who knows the 
MAC key in order to generate those  verified MAC values.


If the MAC length is k bits, an attacker is allowed to send 2^n failed 
verifications, his or her chance of success is approximately 2^n / 2^k. Let's 
imagine n is 64 and k is 96, the success chance is 1/2^36 which is practically 
ZERO!


If I am an attacker, I would choose a message that I want to be verified, and I 
keep changing the MAC key to generate different MAC values with different keys 
and hope one of them will get verified.  Let's assume the MAC key to be 96 bits 
( 96 bits of random bits, the other 32 bits are known). In theory, when I get 
close to 2^96 attempts, I would expect some chance of success. To deal with 
this attacker, one would change the MAC key when the number of failed attempts 
gets close to a number that you don't want. For example, if you don't want a 
success chance of an attack to be above 1 / 2^36, then you need to change your 
MAC key when the number of failed verifications reaches 2^64 when your MAC 
length is 96 bits.


After you change the MAC key, I ( the attacker) will have to start everything 
again because all of the failed MACs I generated before are useless now.


From: Watson Ladd 
Sent: Monday, November 2, 2015 5:07 AM
To: Dang, Quynh
Cc: tls@ietf.org; c...@ietf.org; Eric Rescorla
Subject: Re: [Cfrg] Collision issue in ciphertexts.


On Nov 2, 2015 2:14 AM, "Dang, Quynh" 
mailto:quynh.d...@nist.gov>> 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 that hard to find the right 
result.

>
>
> When there is a collision between two ciphertext blocks when two different 
> counter values are used , the chance of the same plaintext was used twice is 
> 1^128.  Collisions start to happen a lot when the number of ciphertext blocks 
> are above 2^64. However, each collision just reveals that the corresponding 
> plaintext blocks are probably different ones.

Which breaks IND-$. Let's not be clever, but stick to ensuring proven 
definitions are true.

>
>
>
> Quynh.
>
>
> ___
> 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

[TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[internet-drafts]

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 Langley
  Wan-Teh Chang
  Nikos Mavrogiannopoulos
  Joachim Strombergson
  Simon Josefsson
Filename: draft-ietf-tls-chacha20-poly1305-01.txt
Pages   : 7
Date: 2015-11-02

Abstract:
   This document describes the use of the ChaCha stream cipher and
   Poly1305 authenticator in the Transport Layer Security (TLS) and
   Datagram Transport Layer Security (DTLS) protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Adam Langley]

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 
> Security (TLS)
> Authors : Adam Langley
>   Wan-Teh Chang
>   Nikos Mavrogiannopoulos
>   Joachim Strombergson
>   Simon Josefsson
> Filename: draft-ietf-tls-chacha20-poly1305-01.txt
> Pages   : 7
> Date: 2015-11-02
>
> Abstract:
>This document describes the use of the ChaCha stream cipher and
>Poly1305 authenticator in the Transport Layer Security (TLS) and
>Datagram Transport Layer Security (DTLS) protocols.

Dear all,

I've submitted the above version of the ChaCha20-Poly1305 draft in the
hopes of getting consensus that it's basically what the group wants
and thus is suitable for early code-point assignment.

The major change in this version is that the nonce is constructed
using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS
1.2 uses a four-byte, fixed nonce fragment with an explicit,
eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to
eliminate these eight bytes in each record by using the TLS sequence
number. (On this I believe that we basically have agreement.)

The TLS 1.3 spec already specifies that AEADs use the sequence number
and has a construction where a fixed value (from the handshake output)
is XORed with it. (See
https://tlswg.github.io/tls13-spec/#record-payload-protection.) This
draft apes that in the hopes that the TLS 1.3 construction doesn't
change before its final.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AES-GCM and ChaCha-Poly1305: how many bytes are safe?

[Yoav Nir]

> 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 connection (thus per key). That is, 
> as soon as a TLS implementation fails to verify a record's authentication 
> tag, it must shut down the connection. Thus, it would be more useful to state 
> the analysis as "Observing X signed records over Y bytes increases the odds 
> of the attacker forging the next record to Z.”

That is true for TLS, but not for DTLS, so I guess we have to state it both 
ways.

Yoav


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Brian Smith]

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_data records?

This is the TLS 1.2 definition of additional_data is:

additional_data = seq_num  +

  TLSCompressed.type +

  TLSCompressed.version +

  TLSCompressed.length;


In particular, I think we could define the cipher suite to preprocess
the AAD so that if it were equal to this:


 (seq_num XOR client_write_iv)[4..] || 23 || 3 || 3 || HI(len) || LO(len)


then the AAD could be replaced with zero bytes of AAD; otherwise, the
AAD be equal to the input AAD. In other words, compress the AAD with a
very simple function prior to passing it to the RFC 7539
chacha20-poly1305 AEAD function.


This way, one Poly1305 invocation per record could be saved,
potentially, for application_data records, which is the common case.
An implementation that avavoids sending encrypted alerts and avoids
renegotiation could avoid writing code for the case where non-empty
AAD is needed, and could share the exact same code between TLS 1.2 and
TLS 1.3 for ChaCha20-Poly1305.


Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Martin Thomson]

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 like in TLS 1.3 for
> application_data records?

The construction in TLS 1.3 will have no AAD.  I believe that the rationale is:

seq_num is masked into the nonce
TLSCompressed(sic).type is under encryption
TLSCompressed.version is covered by key derivation via the handshake hash
TLSCompressed.length was included in the AAD in 1.2 in error

Unfortunately, I don't believe that all of the above is true for TLS
1.2.  Your proposed construction covers some of these things.  If you
are willing to rely on session hash, you might drop the version, which
leaves this with the type.  We have to authenticate the content type
somehow, and I like your hack for that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Colm MacCárthaigh]

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 point then I wonder if it's worth being
specific about that. On that point: I'm curious if those properties are
implementable in a variety of languages, or if it requires near-assembly
(e.g. C) levels of precision. If it's the latter, then I wonder if it's
legitimate to include those selling points.

* I think the statement "can be implemented easily without being vulnerable
to software side-channel attacks" is too strong, unless one wants to really
litigate what "software side-channels are". Unless I'm mistaken, as a
stream cipher ChaCha20 is *more* vulnerable to a class of size-based
 side-channels than a block cipher would be.

A simple form of attack would be to monitor connections to wikipedia and
identify which pages a user is browsing; from observing just the size of
requests and responses [*] it's pretty easy for an attacker to (offline)
create a graph of HTML page sizes and the sizes of the images they load and
then (in real time) to correlate things such that they can uniquely
identify the page loaded. This attack is feasible with both stream and
block ciphers, but it is far easier with a stream cipher. Similarly, the
compressed map tiles attack that shows where an online maps user is
browsing is much more effective with a stream cipher. [
http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html]

These kinds of simple correlation attack are vastly more practical than the
kinds of time and cache access side-channels that CBC verification is weak
against. They are also inherently passive and undetectable. On the whole
the I-D reads as if ChaCha20 is more side-channel resistant, but I think
reasonable people could disagree about this - and it's worth some
discussion in the security section.

[*] Consider also that in the case of Wikipedia an attacker can control the
size of a target page they may be interested in.



On Mon, Nov 2, 2015 at 2:12 PM, Adam Langley  wrote:

> 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 Security (TLS)
> > Authors : Adam Langley
> >   Wan-Teh Chang
> >   Nikos Mavrogiannopoulos
> >   Joachim Strombergson
> >   Simon Josefsson
> > Filename: draft-ietf-tls-chacha20-poly1305-01.txt
> > Pages   : 7
> > Date: 2015-11-02
> >
> > Abstract:
> >This document describes the use of the ChaCha stream cipher and
> >Poly1305 authenticator in the Transport Layer Security (TLS) and
> >Datagram Transport Layer Security (DTLS) protocols.
>
> Dear all,
>
> I've submitted the above version of the ChaCha20-Poly1305 draft in the
> hopes of getting consensus that it's basically what the group wants
> and thus is suitable for early code-point assignment.
>
> The major change in this version is that the nonce is constructed
> using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS
> 1.2 uses a four-byte, fixed nonce fragment with an explicit,
> eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to
> eliminate these eight bytes in each record by using the TLS sequence
> number. (On this I believe that we basically have agreement.)
>
> The TLS 1.3 spec already specifies that AEADs use the sequence number
> and has a construction where a fixed value (from the handshake output)
> is XORed with it. (See
> https://tlswg.github.io/tls13-spec/#record-payload-protection.) This
> draft apes that in the hopes that the TLS 1.3 construction doesn't
> change before its final.
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls