Subject: [Curdle] minutes for IETF98

From: Daniel Migault <[email-masked]>
Date: Mon, 27 Mar 2017 18:49:31 -0500

Hi,

Thank you Melinda for taking the minutes[1] and Yoav for taking care of
jabber.

Please let us know if you have any correction to bring.

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/minutes-98-curdle/

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 28 Mar 2017 09:54:28 -0700

Thank you Melinda for taking the minutes for the Curdle meeting 
on March 27, 2017.

https://datatracker.ietf.org/doc/minutes-98-curdle/ says:

> draft-ietf-curdle-ssh-modp-dh-sha2
> ============
> EKR: I'm surprised you're not using the ones we're
> standardizing in TLS.  Rich: we're reflecting what's in the
> deployed base.  DKG: Shouldn't use the same groups being
> specified for TLS, although we should use defined groups
> AGL: the draft is documenting reality, but why wouldn't you
> want to use the same groups?  DKG: the rules for generating
> strong groups are well-understood, but you might not want to
> use them cross-domain.  These are also same groups used by
> IKE.  Rich: will encourage discussion on the list, we'll
> pollute IKE and TLS, too.  Tero: these are the groups being
> used in IKE.  Might be premature for last call, needs
> discussion

draft-ietf-curdle-ssh-modp-dh-sha2 is using RFC 3526 MODP primes
based on "pi" instead of RFC7919 primes (TLS) based on "e".

Group modulus security strength estimates (RFC3526)
+--------+----------+---------------------+---------------------+
| Group  | Modulus  | Strength Estimate 1 | Strength Estimate 2 |
|        |          +----------+----------+----------+----------+
|        |          |          | exponent |          | exponent |
|        |          | in bits  | size     | in bits  | size     |
+--------+----------+----------+----------+----------+----------+
|  14    | 2048-bit |      110 |     220- |      160 |     320- |
|  15    | 3072-bit |      130 |     260- |      210 |     420- |
|  16    | 4096-bit |      150 |     300- |      240 |     480- |
|  17    | 6144-bit |      170 |     340- |      270 |     540- |
|  18    | 8192-bit |      190 |     380- |      310 |     620- |
+--------+----------+---------------------+---------------------+

as has been mentioned, the RFC3526 groups are all being used in IKE
and group14 has been used in SSH since RFC4253 was first approved.

RFC7919 seems to provide the following:
+-------+------------+----------+----------+
| Group | Name       | Modulus  | Strength |
|       |            |          | Estimate |
|       |            |          | in bits  |
+-------+------------+----------+----------+
|  256  | ffdhe2048  | 2048-bit |      103 |
|  257  | ffdhe3072  | 3072-bit |      125 |
|  258  | ffdhe4096  | 4096-bit |      150 |
|  259  | ffdhe6144  | 6144-bit |      175 |
|  260  | ffdhe8192  | 8192-bit |      192 |
+-------+------------+----------+-----------

All of thee groups given above are safe primes with a generator g = 2
and q = (p-1)/2.

I have no objections to adding the additional five groups to the draft
if that is desirable to the Curdle WG at large.

Would the following additions make everyone happy?

    diffie-hellman-group256-sha512
    diffie-hellman-group257-sha512
    diffie-hellman-group258-sha512
    diffie-hellman-group259-sha512
    diffie-hellman-group260-sha512

Or are there other issues to be discussed?

	Thank you,
	-- Mark

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Mar 2017 18:19:43 +0000

I think the in-room consensus was that since this is deployed and used in IKE, it's okay and that no work is needed.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Mar 2017 13:31:20 -0500

> I think the in-room consensus was that since this is deployed and used in IKE, it's okay and that no work is needed.

I would advise against defining more options without strong justification.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Mar 2017 13:39:35 -0500

+1

Using the IKE groups is fine. Using the TLS groups is fine. No need for new SSH groups generated in the same way.

(note that I said the same when DKG proposed generating new groups for TLS rather than use the IKE groups)

> On 28 Mar 2017, at 13:19, Salz, Rich <[email-masked]> wrote:
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Mar 2017 05:41:14 +0000

Salz, Rich <[email-masked]> writes:

>I think the in-room consensus was that since this is deployed and used in
>IKE, it's okay and that no work is needed.

There is one obvious counter-argument and that's diversification.  The problem
with the DH1024 group that was pointed out in the Logjam paper is that
absolutely everything ended up using it, making it an incredibly attractive
target because if you break that you break everything that uses it.  Having
everything use the 3526 groups, or similar, just moves the problem to a
slightly larger key size.  So using known-good parameter sets that differ from
what everyone else is using, and in particular IKE and SSL, which are much
large targets than SSH, wouldn't be a bad idea.

In -LTS, one of the suggestions I make is:

  If this isn't possible, an alternative option is to pre-generate a selection
  of DH parameters and choose one set at random for each new handshake, or
  again roll them over from time to time from the pre-generated selection, so
  that an attacker has to attack multiple sets of parameters rather than just
  one.

So one possibility would be to generate, say, 16 NUMS DH parameters for each
size and publish those, and have the server select one at random.  This adds
security both in terms of diversifying from the IKE/SSL values that everyone
else uses, and forcing an attacker to break all 16 parameter sets instead of
just the one.

Peter.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 28 Mar 2017 23:17:37 -0700

Hi Peter,

Peter Gutmann <[email-masked]> writes:

> There is one obvious counter-argument and that's diversification. The
> problem with the DH1024 group that was pointed out in the Logjam paper
> is that absolutely everything ended up using it, making it an
> incredibly attractive target because if you break that you break
> everything that uses it. Having everything use the 3526 groups, or
> similar, just moves the problem to a slightly larger key size. So
> using known-good parameter sets that differ from what everyone else is
> using, and in particular IKE and SSL, which are much large targets
> than SSH, wouldn't be a bad idea.

This is probably the argument which led to the creation of RFC4419.

Of course, there is also the possibility of a dishonest or subverted
server which is using a backdoor DH:

   How to Backdoor Diffie-Hellman
   David Wong, NCC Group, June 2016
   URL: https://eprint.iacr.org/2016/644.pdf

>   If this isn't possible, an alternative option is to pre-generate a
>   selection of DH parameters and choose one set at random for each new
>   handshake, or again roll them over from time to time from the
>   pre-generated selection, so that an attacker has to attack multiple
>   sets of parameters rather than just one.
> 
> So one possibility would be to generate, say, 16 NUMS DH parameters
> for each size and publish those, and have the server select one at
> random. This adds security both in terms of diversifying from the
> IKE/SSL values that everyone else uses, and forcing an attacker to
> break all 16 parameter sets instead of just the one.

Another possibility would be pre-generate a number of provable primes
that are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter,
Qgen_counter, g, Q, P} from the server to the client to prove to the
client that P and Q are primes and then commence the key exchange.

The benefit of safe primes is that q (a Sophie Germain Prime) has a very
large cyclic subgroup. The downside is that there are not as many safe
primes in the number space as there are primes. While I do not know of a
method to attack this weakness, it is something about the structure of
safe primes that makes me wonder sometimes.

Using a q prime with an order that is roughly half of p is still plenty
large enough for slowing down a sieve and would also still be a bit
harder to break in a Post-Quantum Computer universe even if it does not
have as large an order as a sophie germain prime.

Given the provable prime parameters, the client could verify the
primality of q and p and that g is a proper generator for the q-ordered
subgroup. Especially if g is chosen to be 2... :-)

In this way the client will be able to avoid using a backdoor DH.

Would a Draft RFC dealing with the creation of such provable primes be
something that is useful to the Curdle WG? Is it likely that something
like this would be adopted by more than just SSH?

	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Mar 2017 07:11:24 +0000

Mark D. Baushke <[email-masked]> writes:

>Another possibility would be pre-generate a number of provable primes that
>are NOT safe primes and pass {FSeed,vPseed, Qseed, Pgen_counter,
>Qgen_counter, g, Q, P} from the server to the client to prove to the client
>that P and Q are primes and then commence the key exchange.

That would require both a change in the SSH protocol and for everyone to
implement the full FIPS 186 / Shawe-Taylor algorithms, which seems unlikely.
The point of NUMS values is that anyone can verify them, not that everyone
should have to implement the code to verify them.  

You do however need to get one or more people to actually verify them.  Until
I asked about this a few years ago and Henrick Hellström (who probably doesn't
work for the NSA or CIA :-) kindly obliged by running the tests, I don't know
if anyone else had ever independently verified the values in RFC 2409 and 3526
(someone may have, but if they did they didn't publish the fact).

I would go for the most generic form, safe prime, g = 2, and generation from
some NUMS seed in a manner that doesn't require implementing an exotic
algorithm for verification.

(And we can debate whether "2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64
 - 1 + kitchen_sink - pink_flamingo + speed_of_light_in_a_glass_of_milk"
 qualifies as NUMS or not).

>something that is useful to the Curdle WG?

This came up a while back and but fizzled out based on an inability to agree
on how NUMS the generation method should be.  So I'd say there's interest, but
we'd need to sort out how to do the NUMS in a manner that everyone would find
comfortable.

Also, I'm not sure whether you're proposing publishing a HOWTO or the values
themselves, but what's needed isn't so much a discussion of how to do it, it's
for someone to actually do it in a NUMS manner and publish the results.

>Is it likely that something like this would be adopted by more than just SSH?

Uhh, that's kinda missing the point, you want values that *won't* be adopted
by everything else out there.  Unless you compartmentalised and said "these
values are for SSH, these are for SSL, these are for IKE, these are for
everything else".  I certainly don't want my SSH keyex to become collateral
damage in some government agency that really just set out to break IKE, or
VoIP, or SSL.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 29 Mar 2017 05:22:18 -0500

> On 29 Mar 2017, at 0:41, Peter Gutmann <[email-masked]> wrote:
> 

I think “just breaking all SSL”, “just breaking all VPN”, and “just breaking all SSH” are each an attractive enough goal all on its own.

We got so much riding on these numbers that by now there’s little point in not piling on some more.

Of course it should be noted that the SSL numbers are barely in use. The RFC is rather recent and everybody has moved on to ECC.  So breaking DKG’s numbers won’t “break all of SSL”. The IKE ones are very much in use.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 29 Mar 2017 18:44:57 +0300

> large targets than SSH, wouldn't be a bad idea.

Using different group than IKE will add one bit of security. If the
attacker can break DH group of size n, he can easily break two of such
groups.

The only proper protection there is to use keys long enough that they
cannot be broken. Security by obscurity does not work (i.e., claiming
that SSH with different DH groups is safer because no body bothers
attacking SSH is just security by obscurity).

So use proper 2048 bit group, do not try to get away using shorter
non-standard group.

>   that an attacker has to attack multiple sets of parameters rather than just

Random generated groups are much worse than using one well known group
with proper length.

It takes several minutes or hours to properly verify the group was is
actually prime (if you actually do the elliptic curve primality
proofs). If you just trust the probabilistic, then even that is too
slow to do when new connection comes in. And you should not just
assume the group generated by the other end is safe... Also those
tests still do not tell you whether this group is backdoored or not.
Only way to know that group is not backdoored, is to know how it is
was generated.

Of course if you are working in the closed environment and actually
know how to generate safe groups, and generate them properly and
distribute them using some out of band mechanism to all devices, then
you are fine, but that is not normal use of SSH (or IKE, or TLS). 

> else uses, and forcing an attacker to break all 16 parameter sets instead of

Using 16 different Diffie-Hellman groups adds 4 bits of security.
Moving from 1024-bit to 2048-bit DH groups adds 30 bits of security to
the pre-computation step (10^9 times harder [1]). And this is provided
that both of the groups are not trapdoored, but for group given to you
by the other end you cannot be sure about that...

So use properly generated groups with proper length, and do not accept
groups you do not know...

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf page 11,
section 5 2nd column, line 9. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 29 Mar 2017 19:08:43 +0300

> (someone may have, but if they did they didn't publish the fact).

I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when
I generated the RFC3526. I do not know if anybody else has verified
the RFC3526 primes.

I did verify the RFC 7919 groups in Honolulu IETF, and there was even
typo in the draft at that point:

https://www.ietf.org/mail-archive/web/tls/current/msg15716.html

I also have page having primality proofs for the IKE and TLS groups on
my web page: https://kivinen.iki.fi/primes/

> damage in some government agency that really just set out to break IKE, or

Actually breaking SSH is much more useful than breaking IKE or TLS.
The first time the adminstrator types sudo and his root password
inside his ssh connection, the stored SSH stream comes very valuable
for the attacker... Breaking IKE and TLS will most likely just give
some boring email text from the IETF mailing lists :-)
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Mar 2017 00:54:43 +0300

Anna Johnston writes:
> I disagree with the statement that fixed primes are better than
> random.  Randomly generated primes, with Pocklington prime
> certificates, are easily proven prime and can offer better security
> than fixed primes due to the amortization of the cost of the
> discrete logarithm problem – as long as they are treated for what
> they are: crypto parameters, generated with care and changed
> regularly.   Prime certificates for P are possible as long as at
> least half the factorization of (P-1) is known.  For example, given
> P,q,g  where q is at least half the bits of P, Pocklington’s theorem
> gives a quick (two exponentiations) test to not only prove P is
> prime, but also verify that g has order q.   

And that also proofs that those primes do not have backdoors? I did
not know there is tests that tell you that... 

How fast are those tests? How many thousand of those you can do per
second even when you do have crypto hardware to help with
Diffie-Hellman operations used by normal connections.

How large are those Pocklington prime certificates? The prime
certificats that for example Primo prints out are in order of tens of
kilobytes, which is way too large to transfer for every single
connection. 

Also adding that kind of test to be run online when someone connects
opens new path for denial of service attacks, and also opens more code
that is seldomly run and might not be tested as well as rest of code,
i.e., there might be new security issues there.
-- 
[email-masked]

---

From: Anna Johnston <[email-masked]>
Date: Wed, 29 Mar 2017 19:30:26 +0000

I disagree with the statement that fixed primes are better than random.  Randomly generated primes, with Pocklington prime certificates, are easily proven prime and can offer better security than fixed primes due to the amortization of the cost of the discrete logarithm problem – as long as they are treated for what they are: crypto parameters, generated with care and changed regularly.   Prime certificates for P are possible as long as at least half the factorization of (P-1) is known.  For example, given P,q,g  where q is at least half the bits of P, Pocklington’s theorem gives a quick (two exponentiations) test to not only prove P is prime, but also verify that g has order q.  

On 3/29/17, 8:44 AM, "Curdle on behalf of Tero Kivinen" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Anna Johnston <[email-masked]>
Date: Thu, 30 Mar 2017 00:28:58 +0000

There isn’t that much to Pocklington’s theorem.  A decent write up of it is in Wikipedia.  As for your comments:

1.  Proof of no backdoor:  Of course there is no proof that backdoors do not exist.  Show me such a proof for the fixed primes.  However, Pocklington’s theorem can prove the primality of ANY prime, as long as the factorization for at least ½ the bits of (P-1) is known, so it is not reliant on how the prime was generated.  If backdoors are your big concern, using a 2 or 3K bit prime, changing primes regularly, and using a well understood prime generation algorithm minimizes the risk.  The prime has to be fixed for the backdoor to remain in place.
2. The tests can cost as little as two exponentiations.  If (P-1)=hq+1, where q is prime and q>h (h can be any random value, preferably even or you’re guaranteed failure), then two exponentiations give you that P is prime and a known generator of the subgroup of order q.
3. A prime certificate consists of P, the prime q, and the generator for the subgroup, g -- you’d need all this information anyway, so it’s close to zero overhead.
4. When used to generate primes, the prime test boot straps up from a smaller known prime.  The tests are comparable in cost to probabilistic tests, except the result is provably prime, not probably.

A. Johnston

On 3/29/17, 2:54 PM, "Tero Kivinen" <[email-masked]> wrote:

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Mar 2017 02:31:59 +0000

>attacker can break DH group of size n, he can easily break two of such

What you really mean there is "if the attacker can *easily* break DH groups
of size n", not just "can break DH groups of size n".  Since this isn't
the case, they also can't easily break two such groups.

More to the point, if it takes, say, 5 years of computing on 5 acres of
supercomputers (or whatever it is the NSA is supposed to have, and whatever
it'll take for DH2048 in 2040), then you want them to apply it to someone 
else's DH, not yours.

>(i.e., claiming that SSH with different DH groups is safer because no body 
>bothers attacking SSH is just security by obscurity).

Given that they're values published in RFCs, and they're broadcast by 
most servers whenever you connect to them, that mus be going by a pretty 
peculiar definition of "obscurity".

>Using 16 different Diffie-Hellman groups adds 4 bits of security.

... for an attacker who has an O( 1 ) algorithm to solve the DLP.  Do
you know something about the NSA that we don't?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Mar 2017 03:22:31 +0000

Tero Kivinen <[email-masked]> writes:

>I did verify the RFC 2409 primes (768, 1024, and 1536 bit groups) when I 
>generated the RFC3526. I do not know if anybody else has verified the 
>RFC3526 primes.

Wow.  So the 2409 values took five years to be independently verified and
nineteen years before this became known, the 3526 values took twelve years
to be independently verified.  If we do publish new groups, we need to 
address this problem with some urgency.  I'm not saying I don't trust you :-)
but the point of publishing the details is to gain confidence in everything
being correct once multiple people have verified things.

In terms of what to publish, I don't know if there's much need to publish a 
HOWTO for generic DLP parameter generation since presumably every 
implementation already has code to do DH/DSA/whatever generation.  
Where something is needed is situations where widely-shared parameters need 
to be generated, and there all you'd need to do is document how it's done 
and publish the parameters, preferably as a C-style byte array or something.  
Few if any of the parameter-set documents acknowledge that implementers just 
want something they can incorporate into their code with minimal effort.  
Give them a cut&paste code block that takes under five minutes to integrate 
into existing code and it's far more likely to see quick uptake.

And while I'm at it, include a hash of the parameters as a byte string so
you can check that you've got an exact copy of the data.

(The above culled from off-list discussions, in case someone's wondering if
they've seen it before :-)

>Actually breaking SSH is much more useful than breaking IKE or TLS. The 
>first time the adminstrator types sudo and his root password inside his 
>ssh connection, the stored SSH stream comes very valuable for the 
>attacker... 

Only if they want to compromise someone's Linux box or something.  If you
target IKE you get to vaccuum up a ton of VPN traffic, and with SSL you
get not only all web browsing but a ton of other stuff that uses it as the
universal secure transport mechanism for network traffic.  For example if
you're targetting VoIP then you'd want it for the tiny fraction of SIP
that isn't just sent in the clear.  It'd also give you ToR traffic, and 
endless other material.  The pretty clear lesson here is, don't use the same 
DH parameters as SSL/TLS.

So in terms of target groups if I was a government-level attacker, I'd go
for SSL, then IKE, and then I'd think about what to do next, given that it
could take years to break each parameter set.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 30 Mar 2017 03:30:17 +0000

> nineteen years before this became known, the 3526 values took twelve
> years to be independently verified. 

It is a different word now.  Sadly.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Mar 2017 18:54:55 +0300

Anna Johnston writes:
> There isn’t that much to Pocklington’s theorem.  A decent write up
> of it is in Wikipedia.  As for your comments: 
> 
> 1.  Proof of no backdoor:  Of course there is no proof that
> backdoors do not exist.  Show me such a proof for the fixed primes.

I know there is no backdoors on the primes I generated, as I did not
put backdoor there... :-)

Fixed primes uses Nothing up my sleeve numbers [1] just to try to
convince people that they cannot be backdoored.

[1] https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

> However, Pocklington’s theorem can prove the primality of ANY prime,
> as long as the factorization for at least ½ the bits of (P-1) is
> known, so it is not reliant on how the prime was generated.  If
> backdoors are your big concern, using a 2 or 3K bit prime, changing
> primes regularly, and using a well understood prime generation
> algorithm minimizes the risk.  The prime has to be fixed for the
> backdoor to remain in place.

It is not enough for me to use well understood prime generation
algorithm, I also need to convice the peers I am talking to that I am
using well understood prime generation and primes I am offering to
them are generated using them, and that there has not been any virus
or trojan in my machine messing up with the generation process or
changing the primes after I generated them.

For well know primes this needs to be done once when those primes are
generated, and then you can just verify that other end is using one of
the known primes. With primes given to you by the attacker, I mean the
other peer, you need to do that every time you receive prime you have
not seen before.

Yes you could make the system so that when it sees unknown prime, it
will reject the connection, email information to adminstrator, and
adminstrator can then verify the prime, and talk with the person who
generated them to find out how they were generated, and after being
convinced that it is safe, they could install it as one of the known
primes. This just isn't usable solution in general. It is completely
valid solution for closed environment, like internal primes used by
the enterprise for internal communications.

> 2. The tests can cost as little as two exponentiations.  If
> (P-1)=hq+1, where q is prime and q>h (h can be any random value,
> preferably even or you’re guaranteed failure), then two
> exponentiations give you that P is prime and a known generator of
> the subgroup of order q.

And will that also give proof that q is prime, or do you need to
verify that separately? Any ways that is three times more
exponentations than you do normally (which is not that bad, compared
to the other options, and you only need to do this once after you se
new prime). The question is then how do I get to know what q and h
are, as none of the current protocols allow me to send those...

> 3. A prime certificate consists of P, the prime q, and the generator
> for the subgroup, g -- you’d need all this information anyway, so
> it’s close to zero overhead.

Currently we do not normally transfer any of that information inline.
We only send group number and the parameters comes from the built in
code. IKEv1 did have way of sending p and g inline, this was removed
and replaced with preconfigured private groups. In SSH RFC4419 allows
transfering also p and g only. There is no space for q or h.

Not sure about TLS.

> 4. When used to generate primes, the prime test boot straps up from
> a smaller known prime.  The tests are comparable in cost to
> probabilistic tests, except the result is provably prime, not
> probably.

Yes, but then you still need to provide the small prime, and I think
the tests are still quite expensive compared to the regular
Diffie-Hellman. I.e., if every single client would be using new
generated prime, verifying them would be very costly. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 30 Mar 2017 20:40:58 +0300

> Wow.  So the 2409 values took five years to be independently

Earlier than that. First version of the
draft-ietf-ipsec-ike-modp-groups-00.txt was published october 2000,
and that already include primality proofs for 1536, 2048, 3072 and
4096 bit groups. And I did had verified 1024 and 768 bit groups before
publishing that draft. 

It then took 3 years to publish that draft as RFC3526, and it took
several months of that was just to do the primality proofs for bigger
groups. The 16384 bit group (which we decided not to include in
RFC3526) took more than 36 days to generate the primality proof, and I
had to restart it 3-4 times, as machine doing it crashed or lost power
during the process several times. Getting windows machine to stay up
and stable for 36 days was bit challenging.

So yes, there was two year lag from the RFC2409 publication to after
the first draft providing independent proofs for them was published.
Or three years if we use the draft-ietf-ipsec-isakmp-oakley-04 as
baseline for RFC2409, as that was first one that included 1024-bit
group. 

> years to be independently verified. If we do publish new groups, we
> need to address this problem with some urgency. I'm not saying I
> don't trust you :-) but the point of publishing the details is to
> gain confidence in everything being correct once multiple people
> have verified things.

Sure, it would be good thing for other people to run the verifications
too. How about you verifying both IKE and TLS groups and make sure
they are actually generated as explained, and that they are first
primes matching the process...

Primality proofs are something that you do not need to rerun, you can
just take the proofs and verify that they verifiers the prime.

> universal secure transport mechanism for network traffic.

Note, that with IKE there is typically 8 hour rekey timer or similar,
so they need to do the second part of the DH breaking again for each 8
hour data capture and also again for each different client. Most of
the VPN traffic is not that high value than something like root
password of the mail server... 

> For example if you're targetting VoIP then you'd want it for the
> tiny fraction of SIP that isn't just sent in the clear. It'd also
> give you ToR traffic, and endless other material. The pretty clear
> lesson here is, don't use the same DH parameters as SSL/TLS.

No the lesson here is that you do not want to use too short
Diffie-Hellman groups. As the [1] says:

	Our analysis suggests that 1024-bit discrete log may be within
	reach for state-level actors. As such, 1024-bit DHE (and
	1024-bit RSA) must be phased out in the near term. NIST has
	recommended such a transition since 2010 [4]. We recommend
	that clients raise the minimum DHE group size to 2048 bits as
	soon as server configurations allow. Server operators should
	move to 2048-bit or larger groups to facilitate this
	transition. Precomputation for a 2048-bit non-trapdoored group
	is around 10^9 times harder than for a 1024-bit group, so
	2048-bit Diffie-Hellman will remain secure barring a major
	algorithmic improvement.

[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

> could take years to break each parameter set.

If you are scared about that then just go to the 4096 bit
Diffie-Hellman. If it will take years to break 1024-bit DH, and
billion years (10^9) more to break 2048-bit DH, then 4096-bit DH
should be safe... :-)

Even if we assume that they have much more cpu power than people think
they have, and that they can do pre-calculation for the 1024-bit DH in
one day (meaning it does not matter if people will create their own
1024-bit DH groups as they can easily break them quickly), then doing
pre-calculation on one 2048-bit DH group will take more than 2 million
years, so we should be quite safe even if we just use one group. And
if they go and attack TLS group first then IKE is still safe for 4
million years, so you can safely use IKE numbers for next few
decades... :-)
-- 
[email-masked]

---

From: Hubert Kario <[email-masked]>
Date: Fri, 31 Mar 2017 14:17:02 +0200

On Wednesday, 29 March 2017 09:11:24 CEST Peter Gutmann wrote:
> You do however need to get one or more people to actually verify them. 
> Until I asked about this a few years ago and Henrick Hellström (who
> probably doesn't work for the NSA or CIA :-) kindly obliged by running the
> tests, I don't know if anyone else had ever independently verified the
> values in RFC 2409 and 3526 (someone may have, but if they did they didn't
> publish the fact).

At Red Hat we're working on a fully open source implementation of Elliptic 
Curve Primality Proof cerificate verifier (as generated by Primo) so we we 
will have ability to prove that the safe primes are actually safe primes.

> on how NUMS the generation method should be.  So I'd say there's interest,
> but we'd need to sort out how to do the NUMS in a manner that everyone
> would find comfortable.
> 
> themselves, but what's needed isn't so much a discussion of how to do it,
> it's for someone to actually do it in a NUMS manner and publish the
> results.

OTOH, if you have ability and hardware to break one group, breaking two groups 
is not a big problem (and lowers your hardware TCO! ;)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Fri, 31 Mar 2017 14:32:47 +0200

> convince people that they cannot be backdoored.

safe primes can't be backdoored too

they have subgroups of size p-1, (p-1)/2, 2 and 1.
Subgroups of size p-1 and (p-1)/2 are safe, subgroups of size 2 and 1 are 
trivially detectable (just don't process values of p-1, 0 and 1).