Re: Digital Signature Standards

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 03/22/04

  • Next message: The Ghost In The Machine: "Re: Generate 2 Prime Numbers form a serial" 
    Date: Mon, 22 Mar 2004 09:35:12 -0700

    gorilla_nerfball@hotmail.com (Gorilla Nerfball) writes:
    > The last info I found on the subject is from 1996 talks about the
    > debate between RSA and its derivatives (ISO 9796), and NIST DSA/DSS.
    > But I have not found any concrete info to point me to one, or the
    > other, or something else altogether. Any references would be useful.
    > What's happened in the last 8 years?

    In the financial industry, there were a couple issues related to
    digital signatures.

    In the early 90s, there was big push for RSA signatures in conjunction
    with x.509 identity certificates. The issue by the mid-90s was that
    identity information carried in an x.509 identity certificate
    represented complex and serious privacy and liability issues. As a
    result you saw retrenching to relying-party-only certificates
    http://www.garlic.com/~lynn/subputkey.html#rpo
    that just contained an account number, a public key, and bunch of
    administrative gorp.

    In the early & mid-90s ... there is also the issue of using hardware
    tokens for digital signatures. The problem then was that the chips
    seldom had reasonable and reliable random number generation. DSA (&
    ECDSA) requires high quality random numbers for both key generation as
    well as every digital signature operation. A typical RSA hardware
    token from the era had key generation done by a reliable external
    hardware box and the keys injected into the token during some
    personalization phase. But basically, early to mid-90s hardware tokens
    with questionable random number generation put DSA signature
    operations at risk. By the late-90s, there were starting to be chips
    generally available that had reasonably trusted random number
    facilities, providing some comfort for DSA (& ECDSA) signature
    operations.

    Supposedly a desirable application for signatures in the mid-90s was
    financial transactions: take a standard financial transaction, ASN.1
    encode it and digitally sign it; then package up the transaction, the
    signature, and the certificate and send it on its way to the financial
    institution. An issue became that a typical financial transaction of
    the period (and still is) totals 60-80 bytes, a 1024-bit RSA key
    signature is 128 bytes, and typical relying-party-only certificate ran
    4k bytes to 12k bytes; aka the standard, accepted digital signature
    process (for the supposedly, main, driving market force for digital
    signatures) results in a two-order of magnitude size bloat (aka
    increase of one hundred times) in typical financial transaction size.

    Now there was a little bit of business process analysis that went on.
    If you look at a relying-party-only certificate ... you go to your
    financial institution and present your public key ... they record that
    in your account and give you back a relying-party-only certificate.
    You then use that certificate to repeatedly send your financial
    institutions, digitally signed transactions that have been bloated by
    a factor of one hundred times because you are constantly sending them
    back a copy of a certifiate that they already have the original of.
    So my assertion has been that such certificates are redundant and
    superfluous (for supposedly the primary certificate market purpose), in
    addtion to representing a serious operational 100-times size bloat.
    http://www.garlic.com/~lynn/index.html#aads

    Somewhat in parallel with this, X9 had been working on X9.62, ECDSA
    (which is referenced by FIPS182-2 document and can be found on the
    nist.gov web site). So a 163-bit ECDSA key results in a 42byte digital
    signature and gives at least the security of a 1024-bit RSA key with a
    128byte digital signature ... reference to ietf internet draft on key
    strengths:
    http://www.garlic.com/~lynn/2004.html#38 When rsa vs dsa

    Also, X9 has been working on compressed ECDSA digital certificates,
    X9.69 for high transaction operations ... certificates which might be
    as small as 300-600 bytes. Then a 60-80 byte transaction would have a
    42-byte signature and a 500-byte certificate ... which would reduce
    the size bloat from 100-times to something less than 10-times.

    Note, however, one possible x9.69 certificate compression technique is
    to eliminate fields from the certificate that the recipient is known
    to already have. Since the relying-party-only certificate were
    generated by the recipient, it can be shown that the recipient has all
    fields, and the appended certificate can be reduced to zero bytes. So
    the alternative assertion is that rather than not having to append
    redundant and superfluous certificates to transaction, it is possible
    to append zero-byte certificates. This then can result in ECDSA
    digitally signed transactions that possibly only double the size of a
    financial transaction (instead of 10-times or 100-times size bloat):
    http://www.garlic.com/~lynn/index.html#x959

    Now, going back to the thing that can be claimed that really launced
    the certificate industry ... and digital signatures ... was this thing
    called SSL and e-commerce. Some specific references to the
    SSL/e-commerce innovation:
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3
    and a lot more general postings about SSL certificates and digial
    certificates:
    http://www.garlic.com/~lynn/subpubkey.html#sslcerts 

    -- 
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/
  • Next message: The Ghost In The Machine: "Re: Generate 2 Prime Numbers form a serial"

    Relevant Pages

    • Re: renew certificate
      ... When using digital signatures, the important thing to do is to use a digital time stamp as part of the signing to have the signature last longer than the certificate that signed it. ... The digital signatures on your macros may or may not support that feature, but that is the only supported way to handle this. ...
      (microsoft.public.dotnet.security)
    • Re: Soft signatures
      ... now, digital signature, typically just represents that you (in ... For some time there were arguments that if a certificate contained the ... certificate with your public key and the non-repudiation flag in it. ... for a number of different business purposes. ...
      (sci.crypt)
    • Re: X.509 and ssh
      ... by the 60s you were starting to see business countermeasure to this scenario in the offline market, where business checks had a maximum value limit printed on the check. ... The consumer would do a transaction with the merchant ... ... and the merchant would forward the transaction to the responsible (certifying authority) institution for authentication and authorization. ... instead of actually issuing a certificate ... ...
      (comp.security.ssh)
    • Re: electronic signature in Microsoft Word
      ... you need a digital certificate. ... status bar with a tooltip that says "This document has been digitally ... Double-clicking the icon opens the Digital Signature dialog again. ... but be asked for a password before inserting ...
      (microsoft.public.word.docmanagement)
    • Re: Verifying a Signed Executable before running it on a remote machine.
      ... At the very top of the Digital Signature Details property dialog I see ... If I had hacked a certificate generator and entered your name ... Is there a way to verify the actual root ... > Therefore, technically, the signature and cert (according to default Microsoft Authenticode ...
      (microsoft.public.platformsdk.security)
    • Quantcast