David McGrew writes:
>What is especially cool about counter mode encryption is how its real world
>security degrades more gracefully than CBC mode encryption.
Uhh... how does CTR "degrade gracefully" compared to CBC? With CTR, any kind
of problem with the IV/CTR leads to a catastrophic loss of
What is especially cool about counter mode encryption is how its real
world security degrades more gracefully than CBC mode encryption. I
am not sure that the FSE paper did a good job of saying it in English
as opposed to math (except for the last sentence of Section 4), but
even though CTR may b
Hi Quynh,
> On Jul 13, 2016, at 9:58 AM, Dang, Quynh (Fed) wrote:
>
>
>
> On 7/13/16, 9:26 AM, "Watson Ladd" wrote:
>
>> On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx
>> wrote:
>>> Hey Quynh,
>>>
How can one use the distinguishing attack with the data complexity
bound I
sugges
On Mon, Jul 18, 2016 at 06:03:08PM +0200, Eric Rescorla wrote:
> On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara
> wrote:
>
> > I think the end result was insane. The problem that makes it so difficult
> > is that legacy signature types, group types and protection/PRFs interact,
> > so not all s
On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara
wrote:
> On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote:
> > On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote:
> >
> > > There have been a lot of discussions about whether we should try to
> > > refactor cipher-suite negotiation to
On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk
wrote:
> I do not have an objection to option 1 if re-phrased as
> Option 1 - use the same key for protecting both *post*-handshake and
> applications messages..
>
> I believe this is what was intended by that option anyway. Let me clarify.
>
> I unde
On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara
wrote:
> > Tl;dr: I think this is a good approach because it eliminates much of the
> > existing negotiation redundancy/complexity and combinatorial explosion in
> > the 1.3+ ciphersuite menu.
>
> I recently tried to write code to handle this ciphe
On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote:
> On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote:
>
> > There have been a lot of discussions about whether we should try to
> > refactor cipher-suite negotiation to be less monolithic in the cipher
> > suite. I've generally been on
On Mon, Jul 18, 2016 at 3:06 AM, Dan Harkins wrote:
>
> Hi Robert,
>
> This draft moves the NamedCurve/EllipticCurveList into the
> ClientHello, and since the client sends X1 and ZKP(X1) in the
> ClientHello it means that is going to be a list of 1. It basically
> moves the client's key exchan
If we keep trying to salvage the ClientHello version number, we will be
chasing down intolerance forever. (And I'm honestly bored of doing that.)
I'd prefer we move it to an extension. Either an empty indicator extension
for each version or a single version extension with a list of versions. Or
may
On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla wrote:
> There have been a lot of discussions about whether we should try to
> refactor cipher-suite negotiation to be less monolithic in the cipher
> suite. I've generally been on the "no" side of that on cost/benefit
> grounds as well as not quite
On Mon, Jul 18, 2016 at 01:08:43PM +0200, Hanno Böck wrote:
> Hi,
>
> Recently both Adam Langley [1] and David Benjamin [2] indicated that
> they expect with TLS 1.3 Browsers will have to bring back the infamous
> version falbacks that caused so much trouble in the past (POODLE etc.)
> to work aro
On Monday 18 July 2016 13:08:43 Hanno Böck wrote:
> * There don't seem to be any straightforward tools that test for
> version intolerance. The SSL Labs test does detect version
> intolerance, but it's limited to public facing https servers and it
> doesn't seem to detect some of the weirder
Hi,
Recently both Adam Langley [1] and David Benjamin [2] indicated that
they expect with TLS 1.3 Browsers will have to bring back the infamous
version falbacks that caused so much trouble in the past (POODLE etc.)
to work around broken implementations of the TLS handshake.
I don't blame browser
Hi Robert,
This draft moves the NamedCurve/EllipticCurveList into the
ClientHello, and since the client sends X1 and ZKP(X1) in the
ClientHello it means that is going to be a list of 1. It basically
moves the client's key exchange portion from ClientKeyExchange into
ClientHello. So basically,
15 matches
Mail list logo
