Re: DSA GnuPG signatures

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.01.2013 23:14, Colin Watson wrote:

> On Fri, Jan 11, 2013 at 09:54:22PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> 1) DSA keys only. RSA is more tricky since it needs padding and RSA
>> should be progressively phased out, not put into new places due to some
>> vulnerabilities (large classes of semiprimes are factorisable up to the
>> point when a lot of care has to be taken to avoid them).
> 
> This is highly questionable.  DSA is particularly sensitive to
> low-entropy situations and has various other systemic vulnerabilities
> that RSA doesn't have, mainly to do with the extreme sensitivity of k.
> For example, when Debian had its notorious OpenSSL vulnerability
> involving poor random number generation, RSA keys that were generated on
> a system with the vulnerability were indeed compromised; but DSA keys
> were compromised even if they were only ever used to generate a single
> signature on a system with the vulnerability!  Knowledge of even a few
> bits of k is sufficient to recover a DSA private key if you collect a
> relatively small number of signatures made by that key (say, rather less
> than the number of modules shipped by GRUB).  This is the sort of thing
> that makes me want to avoid a cipher, particularly for something like
> GRUB where it's quite possible that you might find yourself needing to
> sign things in situations where only limited entropy is available, even
> though the key might well have been generated in better conditions.
> 

Most schemes that need random, need a very good random numbers. That's
why GRUB doesn't use anything needing random. And that's why sign
functions are removed altogether.

> RSA with a decent key length is perfectly fine and there is no call that
> I'm aware of to phase it out.  Rather to the contrary, DSA is the one
> that I would normally prefer to avoid except where dictated by
> compatibility considerations.
> 
> Assuming that the semiprimes you're referring to are those in
> https://en.wikipedia.org/wiki/RSA_numbers, nobody appears to have got
> any further than 768 bits.  That would be a tiny key by modern
> standards; I've been using 4096 bits everywhere for a few years now, and
> of course the difficulty of factoring scales up much faster than
> linearly in the key length.  I am not aware (and
> https://en.wikipedia.org/wiki/RSA_%28algorithm%29#Integer_factorization_and_RSA_problem
> would appear to agree) of any suggestions that >=4096-bit keys might be
> considered weak any time soon.
> 

(AFAIR) Would need to recheck to be exact
From the p and q you can compute 2 numbers: 0 < alpha, beta < 1. And if
they are small, you can factorise pq even for long keys. There is a
supposition that you could extend these algorithms up to when
0<alpha<0.5 or 0<beta<0.5 or about 75% of possible keys. This was
discovered in 90's and required some adjustments to key generation and
big key regenerations. Keys generated today should be safe. Other
undesirable properties are mitigated by padding.

> Please reconsider.
> 

Ok. Let's move the "opinion" from "not accepted" to "patches are
welcome". The missing part is mainly the padding which is detailed in
RFC4880.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature