Re: RSA Key Format Compatibility Problem

[Jim Starkey]

Last week I posted a problem about RSA private key format compatibility
problems between version 4.2 and version 5.2.1. The resulting silence
has been deafening. I since have resolved the problem, and thought
posting it here would save the next guy a great deal of research.

The RSA private keys generated by Crypt++ version 4.2 are in the format
specified by PKCS #1: RSA Cryptographic Standard, June 14, 2002. This
format is an ASN.1 / BER Sequence containing a few small integers and
seven large integers. The RSA private keys generated by Crypt++ version
5.2.1 are in the format specified by PKCS #8: Private-key Information
Syntax Standard, RSA Laboratories Technical Note, November 1, 1993.
This format is also an ASN.1 / BER Sequence containing a version number,
an algorithm identifier, and private key encoded as octet-string. This
private key is the key defined by PKCS #1.

Crypt++ 4.2 contains code to check select element of the BER sequence
for type INTEGER, and if so, load the PKCS #1 key. Otherwise it
validates the PKCS #8 envelope, then loads embedded key. This code is
not seem to appear anywhere in Crypt 5.2.1.

I have written a few C++ classes to parse an ANS.1 / BER encoding into a
tree of objects and to encode such as tree back to ASN.1 / BER,
including a method to wrap an PKCS #1 with the correct gook to transform
it into a proper PKCS #8 key.

If anyone comes back into this ghost town looking for a similar
solution, I'd be happy to make the classes available under the standard
no-warranty disclaimers. The classes do using a new modules that I'm
not in a position to give away, so a little tweaking would be required
before they could be used directly. They are, however, blessedly free
of C++ template abuse.

I feel a little like a lost explorer scatching his story in the remains
of a lost civilization.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376

[Russell Robinson]

Hi Jim,

Thursday, March 24, 2005, 10:24:40 AM, you wrote:
Jim> Last week I posted a problem about RSA private key format compatibility
Jim> problems between version 4.2 and version 5.2.1. The resulting silence
Jim> has been deafening. I since have resolved the problem, and thought
Jim> posting it here would save the next guy a great deal of research.

Many thanks. Yes, this mailing list is quite quiet. Sometimes
there's a flurry of activity and then nothing for weeks.

If nobody responded, it's probably because they didn't know the
answer.

Jim> I feel a little like a lost explorer scatching his story in the remains
Jim> of a lost civilization.

Be assured there are people listening (at least one anyway) but they
will only speak if they have something to say.

Posting your solution *is* valuable.

PS: I'm surprised Wei hasn't commented on the missing stuff you identified
in 5.2.1.

--
Russell Robinson (mailto:russc...@tectite.com)
Author of PHP FormMail & Tectite
Download your free CRM from: http://www.tectite.com/

[Jim Starkey]

I have an RSA decrypt key generated with crypto++ 4.2 that throws an BERDecodeError in 5.2.1.  The stack trace is:

CryptoPP::BERDecodeError() line 49 + 28 bytes
CryptoPP::BERGeneralDecoder::Init(unsigned char 48) line 389
CryptoPP::BERGeneralDecoder::BERGeneralDecoder(CryptoPP::BERGeneralDecoder & {...}, unsigned char 48) line 381
CryptoPP::BERSequenceDecoder::BERSequenceDecoder(CryptoPP::BERSequenceDecoder & {...}, unsigned char 48) line 182 + 23 bytes
CryptoPP::PKCS8PrivateKey::BERDecode(CryptoPP::BufferedTransformation & {...}) line 546 + 14 bytes
CryptoPP::InvertibleRSAFunction::BERDecode(CryptoPP::BufferedTransformation & {...}) line 65 + 22 bytes
CryptoPP::PK_FinalTemplate<CryptoPP::TF_DecryptorImpl<CryptoPP::TF_CryptoSchemeOptions<CryptoPP::TF_ES<CryptoPP::OAEP<CryptoPP::SHA,CryptoPP::P1363_MGF1>,CryptoPP::RSA,int>,CryptoPP::RSA,CryptoPP::OAEP<CryptoPP::SHA,CryptoPP::P1363_MGF1> > > >::PKc90a7c68(CryptoPP::BufferedTransformation & {...}, unsigned int 1) line 1530 + 150 bytes
License::decrypt(const char * 0x00900804, const char * 0x102956a4) line 100 + 20 bytes

The key works just fine in 4.2.  Walking 5.2.1 and 4.2 in parallel, the difference to be code in 4.2 absent from 5.2.1:

InvertibleRSAFunction::InvertibleRSAFunction(BufferedTransformation &bt)
{
    BERSequenceDecoder privateKeyInfo(bt);
    word32 version;
    BERDecodeUnsigned<word32>(privateKeyInfo, version, INTEGER, 0, 0);    // check version

    if (privateKeyInfo.PeekByte() == INTEGER)
    {
        // for backwards compatibility
        n.BERDecode(privateKeyInfo);

In 4.2, the expression "privateKeyInfo.PeekByte() == INTEGER" is true.

This is obviously a compatibility problem.  Is there a) a way to get 5.2.1 to accept my key, or b) a way to reconstruct my keys from 4.2 to 5.2.1.

I was quite content with 4.2, which strikes me has smaller and more suitable for embedded use, but I have been unable to get it work on AMD64.  I really need only RSA, SHA, DES, and probably AES for the future, so almost any cross platform solution is acceptable, whether 4.2 or 5.2.1.