DSA GnuPG signatures

DSA GnuPG signatures

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Hello, all. I've just committed import of libgcrypt and implementation
of related code to check signatures. Short usage:
verify_detached FILE FILE.sig [pubkey.gpg]
trust KEY.gpg
distruct KEYID
check_signatures=[enforce|no]

grub-mkimage -k KEY gcry_dsa verify [...]

When check_signatures=enforce every time anthing tries to open a file
its signature (file.sig) is looked for and the open fails if signature
is absent or invalid.
Some limitations:
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).
2) Not efficient. Checking every file is slow. Some hashlists should be
implemented.
3) Not efficient. File is read twice though it's avoidable in many cases.
-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: DSA GnuPG signatures

[Colin Watson]

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.

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.

Please reconsider.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: DSA GnuPG signatures

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: DSA GnuPG signatures

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

В Fri, 11 Jan 2013 21:54:22 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

> Hello, all. I've just committed import of libgcrypt and implementation
> of related code to check signatures. Short usage:
> verify_detached FILE FILE.sig [pubkey.gpg]

Just to be sure. Signature is created using

gpg --detach-sign FILE

correct?

> trust KEY.gpg
> distruct KEYID

distrust?

> check_signatures=[enforce|no]
>

There is no command to list currently trusted keys. Would it be
useful? key_list or "trust --list"?
 
> grub-mkimage -k KEY gcry_dsa verify [...]
> 
> When check_signatures=enforce every time anthing tries to open a file
> its signature (file.sig) is looked for and the open fails if signature
> is absent or invalid.

This means - *any* file, including grub.cfg, themes etc? Or does it
apply to modules only?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: DSA GnuPG signatures

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On 13.01.2013 09:33, Andrey Borzenkov wrote:

> В Fri, 11 Jan 2013 21:54:22 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> 
>> Hello, all. I've just committed import of libgcrypt and implementation
>> of related code to check signatures. Short usage:
>> verify_detached FILE FILE.sig [pubkey.gpg]
> 
> Just to be sure. Signature is created using
> 
> gpg --detach-sign FILE
> 
> correct?
> 



Yes

>> trust KEY.gpg
>> distruct KEYID
> 
> distrust?
> 



The opposite of trust

>> check_signatures=[enforce|no]
>>
> 
> There is no command to list currently trusted keys. Would it be
> useful? key_list or "trust --list"?
>  

Added.


>> grub-mkimage -k KEY gcry_dsa verify [...]
>>
>> When check_signatures=enforce every time anthing tries to open a file
>> its signature (file.sig) is looked for and the open fails if signature
>> is absent or invalid.
> 
> This means - *any* file, including grub.cfg, themes etc? Or does it
> apply to modules only?
> 

All files.

> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel





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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: DSA GnuPG signatures

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

В Fri, 11 Jan 2013 21:54:22 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

> Hello, all. I've just committed import of libgcrypt and implementation
> of related code to check signatures. Short usage:
> verify_detached FILE FILE.sig [pubkey.gpg]
> trust KEY.gpg
> distruct KEYID
> check_signatures=[enforce|no]
> 
> grub-mkimage -k KEY gcry_dsa verify [...]
> 
> When check_signatures=enforce every time anthing tries to open a file
> its signature (file.sig) is looked for and the open fails if signature
> is absent or invalid.

There is no protection against file modification after signature was
verified. Is it intentional (i.e. it is not considered as viable
threat)? One possibility is to cache file in memory on first open,
which ensures it cannot be modified externally.

> Some limitations:
> 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).
> 2) Not efficient. Checking every file is slow. Some hashlists should be
> implemented.
> 3) Not efficient. File is read twice though it's avoidable in many cases.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: DSA GnuPG signatures

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On 31.01.2013 13:49, Andrey Borzenkov wrote:

> В Fri, 11 Jan 2013 21:54:22 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> 
>> Hello, all. I've just committed import of libgcrypt and implementation
>> of related code to check signatures. Short usage:
>> verify_detached FILE FILE.sig [pubkey.gpg]
>> trust KEY.gpg
>> distruct KEYID
>> check_signatures=[enforce|no]
>>
>> grub-mkimage -k KEY gcry_dsa verify [...]
>>
>> When check_signatures=enforce every time anthing tries to open a file
>> its signature (file.sig) is looked for and the open fails if signature
>> is absent or invalid.
> 
> There is no protection against file modification after signature was
> verified. Is it intentional (i.e. it is not considered as viable
> threat)?

That is indeed a problem.

> One possibility is to cache file in memory on first open,
> which ensures it cannot be modified externally.

Possible but works only on relatively small files. For bigger files we
need to make a chunk hash list. I'll add the easy part now and if ever
needed we can add more difficult part as well.

> 
>> Some limitations:
>> 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).
>> 2) Not efficient. Checking every file is slow. Some hashlists should be
>> implemented.
>> 3) Not efficient. File is read twice though it's avoidable in many cases.
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]