[Ach] [cryptography] Diffie-Hellman Params Best Practice on Web Server?

[Aaron Zauner]

Hi *,

I’ve talked privately to a couple of people and to people on the #crypto channel on freenode. I still cannot find a solid reason to generate your own DH params. All people I talk with agree unequivocally. Now there are standardised parameters/groups in RFCs, specs as well as implementations. These have been worked on and analyzed by cryptologists. I for my part strongly oppose recommending generation of custom parameters since you can do a lot more harm in messing with DH than for example as with RSA (i.e. you can easily deploy something that is trivial to crack/circumvent). Until somebody provides solid information/research on why we should recommend custom generation of DH params we should stay away from the topic in our paper and leave it with RFC recommendations. I for my part chose only non-EC groups (>1500bits) in my ASA configuration, that - of course - can be discussed. 

Refer to: http://pic.dhe.ibm.com/infocenter/zosmf/vxrx/topic/com.ibm.tcp.ipsec.ipsec.help.doc/com/ibm/tcp/ipsec/ipsec/KeyExchangeOffer_Encrypt.CB_DiffieHellman.html

Just my 3 (oh! it’s prime :P) cents,
Aaron

On 10 Dec 2013, at 17:36, christian mock <cm at coretec.at> wrote:

> On Mon, Dec 09, 2013 at 06:08:19PM +0300, ianG wrote:
>> some questions that might test the text...
> 
> That question also came up on
> <http://crypto.stackexchange.com/questions/12223/how-should-i-manage-diffie-hellman-parameters-on-a-web-server>
> , and the (currently) only answer says
> 
>  When I am asked for recommendations for DH groups, I always send
>  people to the IKE groups; those are all safe primes (and work well
>  with g=2, not leaking even that one bit)
> 
> which may be solid advice to include in the paper, if anybody with
> actual crypto knowledge can confirm that statement.
> 
> Also, since we discussed (WRT dovecot, I think) how often to regenerate
> the DH parameters, the answer says:
> 
>  no, you shouldn't have to rotate the group parameters on a regular
>  basis. It turns out that solving the problem "given these N DH
>  exchanges over the same group, solve any one of them" is not
>  actually any easier than "given this 1 DH exchange, find the shared
>  secret". That is, if the group is weak when you reuse it for DH, you
>  shouldn't be using that group in the first place.
> 
> Again, if that can be verified, that'll answer that question once and
> for all.
> 
> The following paper may also be interesting:
> 
> http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf
> 
> cm.
> 
> -- 
> Christian Mock                          Wiedner Hauptstr. 15
> Senior Security Engineer                1040 Wien
> CoreTEC IT Security Solutions GmbH      +43-1-5037273
> FN 214709 z
> 
> .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> CoreTEC: Web Application Audit - Damit so etwas nicht passiert!
> 
> http://heise.de/-1260559
> 
> .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
> _______________________________________________
> Ach mailing list
> Ach at lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131211/38e14b82/attachment.sig>