RE: PGP scripting...

From: Kenneth Buchanan (K.Buchananat_private)
Date: Mon Mar 24 2003 - 13:54:16 PST

  • Next message: Bear Giles: "Re: PGP scripting..."

    It looks like you're describing the so-called "multi-prime RSA", which is
    defined in PKCS #1.  There is no symmetry in this case, as the private key
    contains a lot more information here than in the original 2-prime RSA.
    
    Decryption is more efficient using this system.
    
    Some time ago I was in fact looking at implementing a system where private
    keys were distributed as part of some software, but public keys were kept
    secret (the intention was to encrypt some information into a product license
    key that could be pulled out later).  The proposal ended up being a bit
    unpractical, but it is one conceivable instance where you might want a
    published private key.
    
    In any case, the algorithm below is (yet another) example of why you have to
    be *extremely* careful about this sort of thing.  If using RSA provided in a
    crypto library, you would need to know the actual implementation of the
    algorithm in order to be sure you can safely 'reverse' the keys without
    compromising the entire system.
    
    Cheers,
    Ken
    
    
    -----Original Message-----
    From: Jason Coombs [mailto:jasoncat_private]
    Sent: Friday, January 10, 2003 6:00 PM
    To: Kenneth Buchanan; 'Tom Arseneault'; Chris Matthews; 'Frank Knobbe'
    Cc: secprogat_private
    Subject: RE: PGP scripting...
    
    
    Aloha,
    
    In addition to being confused about arbitrary asymmetry in RSA cryptography
    and whether or not e and n were reversibly derived from d such that
    possession of d was the same as possession of e and n, I was making a
    practical assertion that many RSA implementations aren't coded in such a way
    as to facilitate arbitrary designation of which key is public and which
    private.
    
    Microsoft .NET, for example, defines a private key as inclusive of its
    corresponding public key. A valid XML representation of a private key in the
    .NET Framework includes the public key. As in:
    
    rsaDecrypt.FromXmlString(
    "<RSAKeyValue><Modulus>vuQkEFfmNf/XTIRL/ga4WYBsA2GMq" +
    "IpUpwPmCEBWIQGwXfRioppWTdIWz01u6o4h8R38alnfbh7erO/O+anmgb" +
    "fHdCf+8oc5G0WcCU1AYp7hV5rBHQ4gb0oaIHi+RCKkcrvzQ2PZjchLcDf" +
    "N15SOgsXDf88fdxFzUoZA23RXrbs=</Modulus><Exponent>AQAB</Exp" +
    "onent><P>4LWIuM82AHAryV3ojQ6Uzef3L5VBpn3y1wRvffg3j27w/KyB" +
    "ou0Zo/LnqqBc885dfLqqaBEBewxLlEpoFfaIhw==</P><Q>2XkPOpd" +
    "Af6sbymL41pwNvZg2CXcc49DBYbamEW+I+xAFAvBSeMP6O09fqO0jN" +
    "mdFeTAbACrQl7gfMteeP9JiLQ==</Q><DP>XV/yBWHNfdceytlkBiF2" +
    "Ai4PEE3EbwvNOj4UmlLnu4mNSGHiqLI/wlnwnH1wwrsRLABhSUcvx1L" +
    "voRpeMCo2xw==</DP><DQ>rhbSERYphMoGGjK2fp44BbFGeLdIgjqHw" +
    "+AB+u0tW8XMLTkS3CgONdJpgoIq8Q8kt0nCI5UinIHBP+MJhI+3FQ==" +
    "</DQ><InverseQ>e9Bf8RurDeKstBP5Awmnc78WgBiaqVTVOpxx3YF" +
    "fsG+Q3YHK1PgRkQKp8uMIHafAIQ0cEq7BxotXd5PYoTN2VQ==" +
    "</InverseQ><D>iaZFgyt/K80y2VBE5AbAhHmgace8AATQCi" +
    "c7hxOth9uJ7BY/0fTs6uzl2dKCeszHGPGAhMgN34CPHbFHVKz5M64" +
    "QvimHE1imX3LPD7bWb00KMd+G0CKJ6BUcreeYpQffcFT3FwO3fEFY" +
    "g44j/2UGdU2RgMiUuvOT+DTO7Os+EtE=</D></RSAKeyValue>");
    
    The <Modulus> and <Exponent> represent the public key while the private key
    consists of <P>, <Q>, <DP>, <DQ>, <InverseQ>, and <D>.
    
    Based on the tests that I've done, Microsoft .NET doesn't allow you to load
    a private key into an instance of the RSA class and use it for encryption,
    you can only use it for decryption.
    
    As for encryption speed, encryption transformations with a public key
    (<Modulus> and <Exponent>) take far less time (approximately 1/15th as long)
    to complete as do decryption transformations with a private key (<P>, <Q>,
    <DP>, <DQ>, <InverseQ>, and <D>)  under Microsoft .NET.
    
    Anyone know why? Is this a known performance differential with RSA or is
    Microsoft doing something strange?
    
    Sincerely,
    
    Jason Coombs
    jasoncat_private
    



    This archive was generated by hypermail 2b30 : Mon Mar 24 2003 - 14:50:43 PST