| |
 |
|
|
Science Forum Index » Cryptography Forum » Asymmetric key pairs storage format...
Page 1 of 1
|
| Author |
Message |
| ... |
 Posted: Wed May 14, 2008 9:27 am |
|
|
|
Guest
|
I would be interested to store RSA and DSA key pairs (that is,
both private and public keys) to persistent storage in a platform-
independent way. I am not aware of any officially anointed formats out
there for this purpose, but maybe somebody in this forum knows better.
Feedback, anyone? |
|
|
| Back to top |
|
| Le Chaud Lapin... |
| Posted: Wed May 14, 2008 12:36 pm |
|
|
|
Guest
|
On May 14, 4:18 pm, Thomas Pornin <por... at (no spam) bolet.org> wrote:
Quote: If you are new to ASN.1, you can find some free and detailed information
at:
http://www.oss.com/asn1/larmouth.html
(and you will curse me forever, for sending you unwarned into the
hellish realm of ASN.1.)
Well, you just answered a question I had for my RSA implementation,
which was whether I should bother with ASN.1 or devise my own format.
-Le Chaud Lapin- |
|
|
| Back to top |
|
| Legrandin... |
| Posted: Wed May 14, 2008 4:08 pm |
|
|
|
Guest
|
Quote: I would be interested to store RSA and DSA key pairs (that is, both
private and public keys) to persistent storage in a platform-
independent way. I am not aware of any officially anointed formats out
there for this purpose, but maybe somebody in this forum knows better.
ASN.1 definitions exist to store encoded keys in a standard way.
The chosen encoding is usually BER.
Check out for instance RFC3279, RFC3447, etc. |
|
|
| Back to top |
|
| Thomas Pornin... |
| Posted: Wed May 14, 2008 4:18 pm |
|
|
|
Guest
|
According to <1.41421 at (no spam) gmail.com>:
Quote: I would be interested to store RSA and DSA key pairs (that is,
both private and public keys) to persistent storage in a platform-
independent way. I am not aware of any officially anointed formats out
there for this purpose, but maybe somebody in this forum knows better.
For RSA, PKCS#1 includes an ASN.1 syntax for a serialization format
of a RSA private key. It so happens that the RSA private key includes
the modulus and public exponent, i.e. all the elements which constitute
the public key, hence that serialized private key can be viewed as
a serialized key pair.
For DSA, there is an ASN.1-based serialization hidden in PKCS#11 (when
talking about wrapping private keys, section 12.6 in version 2.20 of
PKCS#11). Basically, two objects are defined, one holding the DSA
"parameters" (p, q and g) and the other the private key itself as an
INTEGER (the value x). The public key (y) can be recomputed from the
private key through a simple modular exponentiation (y = g^x mod p).
A common "bag" for both formats is PKCS#8. PKCS#8 contains an identifier
for the key type, and then the private key itself serialized in a format
appropriate for that key type.
The PKCS can be downloaded for free from the RSA Labs web site, currently
there:
http://www.rsa.com/rsalabs/node.asp?id=2124
If you are new to ASN.1, you can find some free and detailed information
at:
http://www.oss.com/asn1/larmouth.html
(and you will curse me forever, for sending you unwarned into the
hellish realm of ASN.1.)
Alternatively, you may simply use some existing code which handles
PKCS#8 and knows how to read and write RSA and DSA keys. In the C world,
you may try OpenSSL (www.openssl.org), which is quite common (and free,
and opensource). The Java standard library already contains some support
for PKCS#8.
--Thomas Pornin |
|
|
| Back to top |
|
| Mark Wooding... |
| Posted: Thu May 15, 2008 12:51 am |
|
|
|
Guest
|
Legrandin <dawpeelsiq at (no spam) farifluset.mailexpire.com> wrote:
Quote: ASN.1 definitions exist to store encoded keys in a standard way.
The chosen encoding is usually BER.
Unfortunately, ASN.1 is horrifically complicated, and ASN.1 (well, BER)
decoders have been a significant source of security vulnerabilities.
Quite why anyone thought it would be a good idea for cryptographic
secrets is a complete mystery to me.
I really must recommend against the use of ASN.1 for anything security
critical.
-- [mdw] |
|
|
| Back to top |
|
| Le Chaud Lapin... |
| Posted: Thu May 15, 2008 5:46 am |
|
|
|
Guest
|
On May 15, 7:01 am, Phil Carmody <thefatphil_demun... at (no spam) yahoo.co.uk>
wrote:
Quote: Mark Wooding <m... at (no spam) distorted.org.uk> writes:
Legrandin <dawpeel... at (no spam) farifluset.mailexpire.com> wrote:
ASN.1 definitions exist to store encoded keys in a standard way.
The chosen encoding is usually BER.
Unfortunately, ASN.1 is horrifically complicated, and ASN.1 (well, BER)
decoders have been a significant source of security vulnerabilities.
Quite why anyone thought it would be a good idea for cryptographic
secrets is a complete mystery to me.
I really must recommend against the use of ASN.1 for anything security
critical.
Well, it's not called Absurd Syntax Notation (or even Absurdly
Silly Nonsense) for nothing! (Or at least is was amongst
engineers at ${LARGE_TELECOMS_INFRASTRUCTURE_CORP}, it appears
that's not caught on in the real world.)
Ahem...this is just my opinion but...
Imagine that you are a group of cryptographers who has devised an
inredibly simple ciphersystem.
One day, [primarily] profit-minded individuals agree to commercialize
the scheme, knowing that the 17-year USA patent clock is ticking and
will time-out in September of 2000, IIRC. They also know that
corporations will pay millions of dollars to use their scheme to
secure their internet transactions, at least until September 2000.
After that, customers might or might not continue to pay, depending
upon whether they still need help to implement the technology.
Because the scheme is so simple, the CEO of the commercial venture
goes to bed each night, dreading that date, September 2000, when even
high school kids will be able to incorporate their [somewhat premature
for commercial exploitation] technology your into their products.
How can the CEO guarantee life for RSA Laboratories after September
2000?
He create an artificial dependency. He can do something
counterintuitive to most engineers. He can make the technology appear
to be far more complicated than it is. He can introduce white noise
into the system.
Let's face it:
After a basic understanding of Fermat's Little Theorem, RSA can be
described on a single sheet of paper. Perhaps the business people
over at RSA purposely whitened their specifications to make it appear
to be formidable, knowing well that it was not, to intimidate, and
justify within the mind of, the occasional CEO who likes to peek under
the hood to gain some sense of why s/he should cut a check for
$50,000.
Evidence of this fear-of-patent-expiration can be seen in RSA's
business maneuvers:
RSA Laboratories got into the smart token business very early, perhaps
in anticipation of the dreaded date. There was a strong push for two-
factor authentication: http://en.wikipedia.org/wiki/Two-factor_authentication.
IIRC, both principal individuals of the OpenSSL project were grabbed
by RSA. I have not checked, but I would imagined that, as the patent
expiration date came near, there would have been an incredible urge to
subsume any effort by any individual or organization that is capable
of, and has the intention of, making RSA-based software free...but
alas...no one can boil the ocean, so they had to be selective, but
still, there was a pattern of acquiring potential threats.
In any case, based on the feedback in this thread, I am 100% certain I
will never use ASN.1.
[I _will_ have my implementation reviewed by someone experienced in
cryptography, however, when it is finished.]
-Le Chaud Lapin- |
|
|
| Back to top |
|
| Phil Carmody... |
| Posted: Thu May 15, 2008 7:01 am |
|
|
|
Guest
|
Mark Wooding <mdw at (no spam) distorted.org.uk> writes:
Quote: Legrandin <dawpeelsiq at (no spam) farifluset.mailexpire.com> wrote:
ASN.1 definitions exist to store encoded keys in a standard way.
The chosen encoding is usually BER.
Unfortunately, ASN.1 is horrifically complicated, and ASN.1 (well, BER)
decoders have been a significant source of security vulnerabilities.
Quite why anyone thought it would be a good idea for cryptographic
secrets is a complete mystery to me.
I really must recommend against the use of ASN.1 for anything security
critical.
Well, it's not called Absurd Syntax Notation (or even Absurdly
Silly Nonsense) for nothing! (Or at least is was amongst
engineers at ${LARGE_TELECOMS_INFRASTRUCTURE_CORP}, it appears
that's not caught on in the real world.)
What do you prefer instead of ASN.1?
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
|
| Back to top |
|
| Thomas Pornin... |
| Posted: Thu May 15, 2008 11:31 am |
|
|
|
Guest
|
According to Mark Wooding <mdw at (no spam) distorted.org.uk>:
Quote: I really must recommend against the use of ASN.1 for anything security
critical.
However, ASN.1 begins to look good when the alternative is XML.
--Thomas Pornin |
|
|
| Back to top |
|
| Legrandin... |
| Posted: Thu May 15, 2008 12:37 pm |
|
|
|
Guest
|
Quote: Unfortunately, ASN.1 is horrifically complicated, and ASN.1 (well, BER)
decoders have been a significant source of security vulnerabilities.
Quite why anyone thought it would be a good idea for cryptographic
secrets is a complete mystery to me.
I really must recommend against the use of ASN.1 for anything security
critical.
I know that most people share your opinion, but personally I am pretty
fond of it. For normal applications you use probably no more than 20% of
the ASN.1 standard. And as far as the encoding goes, BER is just a
standardized TLV you can code easily by hand, XER is fine, while packed
PER (as H.xxx tought us) is really hell on earth.
Lately I tried to move to XML, but it seems that the guys are still busy
re-inventing the wheel for their schemas. RELAX NG is a huge step forward,
but it is still not even remotely as expressive as ASN.1. And let's not
comment the awful way they have to sign elements (XML-Sig).
It is just a pity that not many open source tools are available for ASN.1. |
|
|
| Back to top |
|
| Phil Carmody... |
| Posted: Fri May 16, 2008 4:03 am |
|
|
|
Guest
|
Thomas Pornin <pornin at (no spam) bolet.org> writes:
Quote: According to Mark Wooding <mdw at (no spam) distorted.org.uk>:
I really must recommend against the use of ASN.1 for anything security
critical.
However, ASN.1 begins to look good when the alternative is XML.
You're confusing definition and encoding.
ASN.1 can happily have XML rendering as its back end (XER).
(front end? arse end? who knows!)
Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration |
|
|
| Back to top |
|
| Thomas Pornin... |
| Posted: Fri May 16, 2008 7:18 am |
|
|
|
Guest
|
According to Phil Carmody <thefatphil_demunged at (no spam) yahoo.co.uk>:
Quote: You're confusing definition and encoding.
No I am not. I am talking about the current trend of redifining with
an XML-based syntax what was previously done with ASN.1 and BER. E.g.
XML-DSig and XAdES vs CMS and CAdES. There is no XER here.
XER is just the chimeric spawn of the two evils. From the ASN.1 world
point of view, it is an alternative encoding which replaces BER. From
the XML world, XER is a kind of XML which uses the ASN.1 syntax as a
substitute for the DTD / XML-schema.
--Thomas |
|
|
| Back to top |
|
| |
|
Page 1 of 1
All times are GMT - 5 Hours
The time now is Sun Jul 06, 2008 8:39 pm
|
|
