Re: Byte order problems with CAPI

From: Andrew Fiddian-Green (ho)
Date: 09/16/05

  • Next message: chad: "Re: Get handle of current logged on user?" 
    Date: Fri, 16 Sep 2005 22:43:46 +0200

    > you don't convert symmetric keys and convert asymmetric keys...

    and you don't convert symmetric data and convert asymmetric data...

    AndrewFG

    "lelteto" <lelteto@discussions.microsoft.com> wrote in message
    news:AEC9F5EE-E1AA-4FC8-8E14-6EA90225C342@microsoft.com...
    > you don't convert symmetric keys and convert asymmetric keys...
    >
    > Laszlo Elteto
    > SafeNet, Inc.
    >
    > "Andrew Fiddian-Green" wrote:
    >
    >> Yes.
    >>
    >> But the problem with converting or interworking between MS Crypto and
    >> other
    >> libraries is that for some types of keys and you must reverse the
    >> strings,
    >> whereas for other types of keys and data you must not reverse them. (And
    >> it
    >> is not so obviously clear which case is which -- at least not to me...)
    >>
    >> AndrewFG
    >>
    >> "lelteto" <lelteto@discussions.microsoft.com> wrote in message
    >> news:820C38AC-4BAB-4DE3-8944-E64011CD8463@microsoft.com...
    >> > Well, the difference is that AES (and other, secret) keys are just a
    >> > SERIES
    >> > of BYTES. There is no meaning for 'endianness' - just as much as no
    >> > reason
    >> > to
    >> > call the character sting "abcdefgh...z" either endian.
    >> > On the other hand, RSA keys are actually big NUMERIC VALUES (well, the
    >> > key
    >> > components are).
    >> >
    >> > Laszlo Elteto
    >> > SafeNet, Inc.
    >> >
    >> > "Andrew Fiddian-Green" wrote:
    >> >
    >> >> Solved...
    >> >>
    >> >> All my assertions 1) thru 3) are indeed correct...
    >> >>
    >> >>
    >> >> "Andrew Fiddian-Green" <nn@dd> wrote in message
    >> >> news:OOhIRJEuFHA.1132@TK2MSFTNGP10.phx.gbl...
    >> >> >I have a client-server application that does security transactions
    >> >> >over
    >> >> >the
    >> >> > wire. The transactions include exchange of RSA and session keys, and
    >> >> > sending
    >> >> > encrypted data and digital signatures over the wire etc.
    >> >> >
    >> >> > All transactions must be done in network byte order (big endian).
    >> >> > And
    >> >> > currently I use a 3rd party crypto library which implements big
    >> >> > endian
    >> >> > code.
    >> >> >
    >> >> > But I am now trying to migrate the client and server applications to
    >> >> > use
    >> >> > the
    >> >> > Microsoft CAPI instead of the 3rd party library and I am
    >> >> > encountering
    >> >> > the
    >> >> > devil's own problems due to the switch from big to little endian
    >> >> > architecture.
    >> >> >
    >> >> > Specifically, it seems to me that in CAPI there are differences in
    >> >> > endian-ness depending on whether one is working with AES session
    >> >> > keys
    >> >> > or
    >> >> > with RSA PKI keys. Specifically I have the following questions /
    >> >> > problems:
    >> >> >
    >> >> > 1) CryptExportKey & CryptImportKey: it seems that with AES session
    >> >> > keys
    >> >> > the
    >> >> > key data in the blob is big endian, but with RSA keys the key data
    >> >> > is
    >> >> > little
    >> >> > endian; - is that correct?
    >> >> >
    >> >> > 2) CryptEncrypt & CryptDecrypt: for both AES and RSA keys, if we
    >> >> > call
    >> >> > the
    >> >> > left-to-right plaintext "big endian", then for AES session keys the
    >> >> > ciphertext is also big endian, but for RSA keys the ciphertext is
    >> >> > little
    >> >> > endian (i.e. reverse byte order); - is that correct?
    >> >> >
    >> >> > 3) CryptSignHash & CryptVerifySignature: for RSA keys the
    >> >> > left-to-right
    >> >> > plaintext is big endian, but the signature is little endian (i.e.
    >> >> > reverse
    >> >> > byte order); - is that correct?
    >> >> >
    >> >> > All help would be much appreciated. (Its a nightmare for me at the
    >> >> > moment).
    >> >> >
    >> >> > Regards,
    >> >> > AndrewFG
    >> >> >
    >> >> >
    >> >>
    >> >>
    >> >>
    >>
    >>
    >>

  • Next message: chad: "Re: Get handle of current logged on user?"

    Relevant Pages