hi Peter, (one of the authors here)
thanks a lot for you comments.
As for the case with Nikos we take on board and well appreciate
comments/feedbacks.
Will pass the message.
Thanks a lot and regards
antonio
On Oct 20, 2016, at 2:13 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos writes:
>
Nikos Mavrogiannopoulos writes:
>I am not sure that the recommendations of this paper should be blindly
>trusted. There are some inaccurate facts about a library I work on [0], but a
>part of the abstract is also concerning: "We examine over 20 open-source
>cryptographic libraries and application
I have not read the paper in detail, but I agree with the high level
conclusions. If it were not for quantum computers, I think IETF should
move to curve25519 as quickly as possible. With quantum computers the
picture is more complicated as ECC would anyway need to be replaced with
PQC in the not t
On Tue, Oct 18, 2016 at 8:46 PM, John Mattsson
wrote:
> New paper “Measuring small subgroup attacks against Diffie-Hellman”
> https://eprint.iacr.org/2016/995.pdf
> “Cryptographic recommendations from standards committees are often too
> weak or vague”
> “However, the tangle of RFCs and standards
New paper “Measuring small subgroup attacks against Diffie-Hellman”
https://eprint.iacr.org/2016/995.pdf
“Cryptographic recommendations from standards committees are often too
weak or vague”
“However, the tangle of RFCs and standards attempting to define current
best practices in key generation
Paul,
It's been over 8 years since this RFC was published, and I have not
looked at it since then. My recollection is that we wrote 5114 because
an IPsec developer approached me and said that he wanted to support
these groups in a product. He said that he wanted test vectors for the
groups,
On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen wrote:
> Yoav Nir writes:
>> I’m not entirely comfortable with calling something a MUST NOT when all we
>> have is conjecture, but I have no love and no need of those DH groups.
>
> Same here, and it also makes it so that we cannot say our
> implementa
On Tue, 18 Oct 2016, Yoav Nir wrote:
It's a little more than conjecture.
1) It has been proven that malicious 1024 bit DH values can be generated
by academia that cannot be independantly discovered. Therefore any
nationstate with access to the same theory and more CPU power could
have don
Yoav Nir writes:
> > Same here, and it also makes it so that we cannot say our
> > implementation is conforming rfc4307bis, even when we do already have
> > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to
> > implement algorithms in the new document, but we do also have code to
> > pr
> On 18 Oct 2016, at 13:33, Tero Kivinen wrote:
>
> Yoav Nir writes:
>> I’m not entirely comfortable with calling something a MUST NOT when all we
>> have is conjecture, but I have no love and no need of those DH groups.
>
> Same here, and it also makes it so that we cannot say our
> implementa
Yoav Nir writes:
>Someone can trapdoor 1024-bit values, therefore someone else can trapdoor
>2048-bit values.
Yep, space aliens. However I'm really not too worried about those at the
moment.
Peter.
___
IPsec mailing list
IPsec@ietf.org
https://www.i
> On 17 Oct 2016, at 19:19, Paul Wouters wrote:
>
> On Mon, 17 Oct 2016, Yoav Nir wrote:
>
>> I’m not entirely comfortable with calling something a MUST NOT when all we
>> have is conjecture,
>
> It's a little more than conjecture.
>
> 1) It has been proven that malicious 1024 bit DH values
Yoav Nir writes:
> I’m not entirely comfortable with calling something a MUST NOT when all we
> have is conjecture, but I have no love and no need of those DH groups.
Same here, and it also makes it so that we cannot say our
implementation is conforming rfc4307bis, even when we do already have
sup
On Mon, 17 Oct 2016, Yoav Nir wrote:
I’m not entirely comfortable with calling something a MUST NOT when all we have
is conjecture,
It's a little more than conjecture.
1) It has been proven that malicious 1024 bit DH values can be generated
by academia that cannot be independantly discove
I’m not entirely comfortable with calling something a MUST NOT when all we have
is conjecture, but I have no love and no need of those DH groups.
I don’t believe anyone else depends on these groups (at least in IPsec), so I’m
fine with such a change.
Yoav
> On 17 Oct 2016, at 18:54, Daniel Mig
In fact is there anyone opposing their status becomes MUST NOT in
rfc4307bis.
On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson
wrote:
> > I'm proposing it is time to change this to MUST NOT for 4307bis.
>
>
>
> +1
>
> On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
> wrote:
>
> >
> >Release
16 matches
Mail list logo
