Hi Ben,
>> If that is going to be changed, the early adopters run into trouble with
>> their deployments!
>
> I'm not sure I follow. Are you saying that if there is a theoretical
> problem with the construction it would have been exposed by
implementation
> testing?
No, I don't say that.
> This is speculation of course.
I retract this part of my message due to
the fact that the format of the primes in
the recent spec is the same as the format
going back to the original MODP primes.
Mike
___
TLS mailing list
TLS@ietf.org
Hi Achim,
Sorry again for the delayed response. (Inline.)
On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote:
> Hi Ben,
>
>
> Am 16.09.20 um 08:31 schrieb Achim Kraus:
> > Hi Ben,
> >
> >>>
> >>> If I did't get it, it may be easier to discus this as issue in the
> >>> github repo.
>
Hi Achim,
Sorry for the long silence on this front; my attention had cycled elsewhere
and I was just overall operating slowly for a couple weeks (sick, maybe,
but no clear symptoms).
My primary concern is not actually about a specific situation where
injection occurs, but rather for
> -Original Message-
> From: TLS On Behalf Of Michael D'Errico
> Sent: Thursday, October 08, 2020 1:54 PM
> To: TLS List
> Subject: [TLS] DH generator 2 problem?
>
> Using finite-field Diffie-Hellman with a generator of 2 is probably not the
> best
> choice. Unfortunately all of the
>Should we define some new DH parameters which use a
different generator? Maybe the primes are fine
I think the efforts these days are focused on using X25519, X448, etc.
___
TLS mailing list
TLS@ietf.org
Using finite-field Diffie-Hellman with a generator
of 2 is probably not the best choice. Unfortunately
all of the published primes (RFCs 2409, 3526, and
7919) use 2 for the generator. Any other generator
would likely be (not sure how much?) more secure.
The problem is that 2^X consists of a
