On Tue, Nov 3, 2015 at 8:25 AM, Benjamin Kaduk wrote:
> % 1. The 64-bit record sequence number is serialized as an 8-byte,
> % big-endian value and padded on the left with 4 zeroes.
>
> I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...)
>
> "padded on the left" als
On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos wrote:
> I agree that protecting the length of the communicated data is
> important, but there is nothing specific to this cipher. All modern TLS
> ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so
> they offer the same pro
On Tue, Nov 3, 2015 at 11:29 AM, Brian Smith wrote:
> Brian Smith wrote:
>>
>> This way, one Poly1305 invocation per record could be saved, potentially,
>> forapplication_data records, which is the common case.
>
>
> This is still true, but...
>
>>
>> An implementation that avavoids sending encry
Brian Smith wrote:
> This way, one Poly1305 invocation per record could be saved, potentially,
> forapplication_data records, which is the common case.
>
>
This is still true, but...
> An implementation that avavoids sending encrypted alerts and avoids
> renegotiation could avoid writing code
On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos
wrote:
>
> I agree that protecting the length of the communicated data is
> important, but there is nothing specific to this cipher.
I wouldn't contest that; I just think the I-D is over-selling ChaCha20's
side-channel resistance. I would a
On 11/02/2015 04:06 PM, internet-dra...@ietf.org wrote:
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01
>
>
Section 2,
% 1. The 64-bit record sequence number is serialized as an 8-byte,
% big-endian value and padded on t
On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote:
> * 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 c
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 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
12 matches
Mail list logo
