shake stabilizes, we hope to update our work. At this point in
time, we hope that our analysis can provide some cryptographic insights
for the so-far achieved and further development of TLS 1.3.
We welcome your comments and suggestions.
Benjamin Dowling, Marc Fischlin, Felix Günther, and Douglas
ire and the reconstructed context. At least from a crypto
perspective, this would be the safest bet. But again, this is
extrapolating beyond what our analyses cover, hence just my two cents.
Best,
Felix
[1] Marc Fischlin, Felix Günther, Christian Janson. Robust Channels:
Handling Unrel
Hi,
On 2020-05-15 22:04 +0200, Eric Rescorla wrote:
> Actually, the full epoch is included in the overall sequence number and
> hence used to generate the nonce.
>
> https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4
>
> Does that help?
Sorry, I forgot about reading this difference
' to the logical
header I don't know. Not saying this can't work, but our analysis
doesn't speak to that.
> Would you expect a change in proof complexity when switching
> to explicit length and sequence number authentication in the AEAD?
Length: no.
Sequence number (and
Hi,
On 2020-05-17 07:35 +0200, Hanno Becker wrote:
> So, we're here at the moment:
> (1) Only the CID issue really _needs_ fixing somehow.
> (2) Other header fields are currently authenticated through a mixture of
> AAD, nonce, and implicit properties of the AEAD,
> and proof complexity doesn't s
Hi,
On 06/06/2016 11:53 +0200, Antoine Delignat-lavaud wrote:
> Le 2016-06-04 16:51, Eric Rescorla a écrit :
>> I wanted to call out to cryptographers/analysts that this formalizes
>> the existing practice (going back to RFC 5077) of having multiple
>> ticket values tied to the same basic secret (
I also prefer (2).
Cheers,
Felix
On 14/06/2016 14:45 +0200, Cas Cremers wrote:
> It is not quite as simple as saying "(1) makes proofs more complicated"
> since it depends on what you are trying to prove.
>
> (1) makes some styles of standard AKE property proofs (key secrecy,
> authentication) h
Hi Martin,
just to clarify: you add an additional HKDF.Expand step, not
HKDF.Extract, right?
You mentioned extract in the email and PR text, but in code it's a
second expand---which makes sense, as only expand allows to add context
(here: label).
Cheers,
Felix
On 23/02/2017 20:30 -0800, Martin
Hi Peter,
We discussed this among the [DOWLING] authors; Douglas asked me to chime
in here as he's offline the next couple of days.
It is indeed true that the PRF-ODH assumption, as stated in [DOWLING]
and https://ia.cr/2017/517, wouldn't be compatible when using the
x-coordinate only, or wi
Hi Peter,
If your question is about what assumption the PQ KEM you still need to
make in case it's not IND-CCA secure anymore and you want to fall back
to [DOWLING] for the (EC)DH result, I think the answer is: none.
(Beyond ensuring unambiguous encoding of KDF inputs, as the draft
mandates t
ssible that I'm missing something obvious and a different
part of the proof rules this out.
Best,
Peter
-Original Message-
From: Felix Günther
Sent: Friday, August 2, 2024 2:05 PM
To: Peter C ; Marc Fischlin
Cc: tls@ietf.org
Subject: Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid
I think it would be
a significant deviation from the usual security notion.
Sorry for all the details. Hopefully, it's clear enough!
Best,
Peter
-Original Message-
From: Felix Günther
Sent: Tuesday, August 13, 2024 10:51 AM
To: Peter C ; Marc Fischlin
Cc: tls@ietf.org
Subject: R
12 matches
Mail list logo
