RE; 192-bit signatures

[Bob Mearns]

I'm looking to generate a short digital signature, perhaps 192
bits or so, using an asymmetrical algorithm. DSA seems to
have 320 bit signatures regardless of the key size used. Is
this really the case, or am I missing something? Ignoring for
the moment the wisdom of using signatures this short, is there
a way I can accomplish my goal of ~192 bit signatures?

If you're concerned about detecting corruption but not concerned about
security, just use the SHA1 hash.
If you're concerned about security but don't need public-key features, you
can use the SHA1 hash of the data preceded by a shared secret.
If you're concerned about security and need 192-bit signatures with PK
features, AFAIK, you're out of luck. No known PK algorithm can be secure
with bit lengths that small.
DS

I appreciate that the security of such a short signature is paltry.
In my application, the signature length (keeping it short) is as
important as the security (odd as that may seem). I've not found
a way to generate signatures as short as I'd like using OpenSSL -
is there just no way to do it using PK?

Thanks

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dr. Stephen Henson]

Post by Bob Mearns
I appreciate that the security of such a short signature is paltry.
In my application, the signature length (keeping it short) is as
important as the security (odd as that may seem). I've not found
a way to generate signatures as short as I'd like using OpenSSL -
is there just no way to do it using PK?

HMAC might be usable. It isn't a public key algorithm but it might do
depending on your application.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Victor Duchovni]

Post by Bob Mearns
I appreciate that the security of such a short signature is paltry.
In my application, the signature length (keeping it short) is as
important as the security (odd as that may seem). I've not found
a way to generate signatures as short as I'd like using OpenSSL -
is there just no way to do it using PK?

ECC is believed secure at well under 200 bits, so you could sign a SHA1
checksum with suitable ECC algorithm in ~192 bits with a "reasonable"
security guarantee.

Note, however that best practice in this space (sparse as it may be)
recommends somewhat larger hashes and key sizes:

http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

Specifically, SHA-256 with 256 bit ECC or SHA-384 with 384 bit ECC:

http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

these correspond (usual birthday paradox) to 128 bit and 192 bit
encryption strength respectively.

Some uses of ECC are protected by patents...

[Jason Resch]

I'm looking to generate a short digital signature, perhaps 192
bits or so, using an asymmetrical algorithm. DSA seems to
have 320 bit signatures regardless of the key size used. Is
this really the case, or am I missing something? Ignoring for
the moment the wisdom of using signatures this short, is there
a way I can accomplish my goal of ~192 bit signatures?

I just thought that it should be noted, the reason the DSA signatures
are locked at 320 bits regardless of the key used is because the DSA
standard uses the SHA-1 hash function to first compute the hash of the
message. SHA-1 produces a fixed size hash of 160 bits. Because the
hash size is fixed, the DSA specifies that a 160 bit prime be chosen at
random during the key generation. During the signing process, two
values are computed, r and s, each of these is calculated in an equation
that is mod q. Therefore r and s can never exceed more than 160 bits,
regardless of the size of key used. Since r and s comprise the
signature, these two 160-bit values combine to form a signature that is
320 bits in length. For more information on the algorithm and how it
works, please see: http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

A new standard is currently under development (Do a search on: FIPS
186-3) which specifies the use of longer length hashes, including
SHA-224, SHA-256, SHA-384, and SHA-512 as a hash function, therefore q
would be of size 224, 256, 384, and 512 bits respectively. The
signature sizes would be double the size of q for each case.

To have a signature length of 192 bits would require q be 192/2 or 96
bits long. This is considerably smaller than the length of even MD5
hashes, and therefore would not provide a great deal of security.

Jason
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Alain Damiral]

Out of pure curiosity -

I have recently been told that all existing/used protocols had been
designed without taking into account the eventual need to adapt to new
hash lengths. How true is that ? It seems to be a topic of concern for
some people since all commonly used hashes have been broken last year.
I'm wondering if TLS really falls into that category of "all
existing/used protocols"...

Post by Jason Resch
A new standard is currently under development (Do a search on: FIPS
186-3) which specifies the use of longer length hashes, including
SHA-224, SHA-256, SHA-384, and SHA-512 as a hash function, therefore q
would be of size 224, 256, 384, and 512 bits respectively. The
signature sizes would be double the size of q for each case.
To have a signature length of 192 bits would require q be 192/2 or 96
bits long. This is considerably smaller than the length of even MD5
hashes, and therefore would not provide a great deal of security.
Jason
______________________________________________________________________
OpenSSL Project http://www.openssl.org

--
Alain Damiral,

I hope this message makes me look like a very intelligent person

Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Kyle Hamilton]

TLS uses an XOR of an MD5 over the first 128 bits, and then an
unmodified remaining 32 bits for SHA-1.

However, please note that a successful attack against TLS would
require the ability to generate a plaintext that would make both the
MD5 and the SHA1 come out to the same value.

-Kyle H

Post by Alain Damiral
Out of pure curiosity -
I have recently been told that all existing/used protocols had been
designed without taking into account the eventual need to adapt to new
hash lengths. How true is that ? It seems to be a topic of concern for
some people since all commonly used hashes have been broken last year.
I'm wondering if TLS really falls into that category of "all
existing/used protocols"...

Post by Jason Resch
A new standard is currently under development (Do a search on: FIPS
186-3) which specifies the use of longer length hashes, including
SHA-224, SHA-256, SHA-384, and SHA-512 as a hash function, therefore q
would be of size 224, 256, 384, and 512 bits respectively. The
signature sizes would be double the size of q for each case.
To have a signature length of 192 bits would require q be 192/2 or 96
bits long. This is considerably smaller than the length of even MD5
hashes, and therefore would not provide a great deal of security.
Jason
______________________________________________________________________
OpenSSL Project http://www.openssl.org

--
Alain Damiral,
I hope this message makes me look like a very intelligent person
Université Catholique de Louvain - student
alain.damiral'at'student.info.ucl.ac.be
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org