Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 Jan 2016 04:05:07 +0300
From: gremlin@...mlin.ru
To: oss-security@...ts.openwall.com
Subject: Re: Prime example of a can of worms

On 2016-01-20 08:45:07 -0700, Kurt Seifried wrote:

 > I finally got the article written and published, it's at:
 > https://securityblog.redhat.com/2016/01/20/primes-parameters-and-moduli/

In that article you wrote:

 > I think the best plan for dealing with this in the short term
 > is deploying larger primes (2048 bits minimum, ideally 4096
 > bits) right now wherever possible.

4096 bit keys seem to be the absolute minimum, and personally I've
already moved to 8192 bit keys.

Here are some numbers:

`openssl dhparam -2 4096` took 1:53:29 to generate (HH:MM:SS);
`openssl dhparam -5 4096` took 1:43:44;
`openssl dhparam -2 8192` took 25:51:34;
`openssl dhparam -5 8192` took 16:51:47.

 > Why not huge primes?
 > Why not simply use really large primes? Because computation
 > is expensive, battery life matters more than ever and latency
 > will become problems that users will not tolerate.

Any and all cryptographic transforms must be expensive - that means
at least time and electric power. As every single bit requires at
least two transistors (physical areas on the chip) just to store it
and much more to process, and each of those transistors consume at
least hundreds of pA, the cryptoprocessors (which are already used
for brute-force attacks) would be much more power-consuming.

Said that, the attackers would need building yet another power
station to get more gigawatts for their key-breaking datacenters
and, as all this power would finally become heat, such facility
should be built at least at Taimyr or Melville peninsula - both
are continental (for laying cables) and cold just enough :-)

Also, there are elliptic curves-based algorithms, but they have
one strong disadvantage: although the computations are more
complex, that must not be the reason to reduce the key size.

 > Additionally the computation time and effort needed to find huge
 > primes (say 16k) is difficult at best for many users and not
 > possible for many (anyone using a system on a chip for example).

That would require a really good hardware RNG. For now, I have an
experimental USB device (based on ATtiny85 and LM393) for such
purposes, but most SoC systems lack them (despite of adding them
would be simple and inexpensive: dual op-amp and one GPIO pin).


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ