Java CryptoAPI 3DES Key Compatibility

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Michael Bebenita

    Java CryptoAPI 3DES Key Compatibility

    Hi,

    A Java application is encrypting a block of text using 3DES ECB mode
    and PKCS5 padding. I need to decrypt this text using C#. I've
    extracted the 192 bit key using the getEncoded() method of the
    SecretKey Java class. However when I use this key in .NET i cannot
    decrypt the cipher text.

    I am pretty sure that all my settings are correct, as far as setting
    the ECB mode, PKCS5 padding and converting the cipher text to byte
    arrays. I think it's the key that is giving me problems. Is there
    anything that I must do to the exported java key before I use it in
    ..NET ?

    Thanks
    Michael Bebenita
  • Gerard Krupa

    #2
    Re: Java CryptoAPI 3DES Key Compatibility

    "Michael Bebenita" <thepuppet@sbcg lobal.net> wrote in message
    news:826f20ab.0 309032241.4c7d1 d7b@posting.goo gle.com...[color=blue]
    >
    > A Java application is encrypting a block of text using 3DES ECB mode
    > and PKCS5 padding. I need to decrypt this text using C#. I've
    > extracted the 192 bit key using the getEncoded() method of the
    > SecretKey Java class. However when I use this key in .NET i cannot
    > decrypt the cipher text.
    >
    > I am pretty sure that all my settings are correct, as far as setting
    > the ECB mode, PKCS5 padding and converting the cipher text to byte
    > arrays. I think it's the key that is giving me problems. Is there
    > anything that I must do to the exported java key before I use it in
    > .NET ?[/color]

    AFAIK, Java provides you with a 192-bit parity-adjusted key and .NET
    requires a 168-bit non-parity-adjusted key. I don't think there is any
    function in Java or .NET to remove the parity but it's simple enough to
    implement (just a case of removing the LSB of each byte in the key).

    You also need to ensure that your IV is shared between the two applications.

    HTH

    --
    Gerard John Krupa BSc AMBCS
    Purveyor of network management software



    Comment

    • Michael Bebenita

      #3
      Re: Java CryptoAPI 3DES Key Compatibility

      "Gerard Krupa" <gerard@spamfre ebogbrush-zone.co.uk> wrote in message news:<dhG6b.91$ ca7.31@newsfep1-gui.server.ntli .net>...[color=blue]
      > "Michael Bebenita" <thepuppet@sbcg lobal.net> wrote in message
      > news:826f20ab.0 309032241.4c7d1 d7b@posting.goo gle.com...[color=green]
      > >
      > > A Java application is encrypting a block of text using 3DES ECB mode
      > > and PKCS5 padding. I need to decrypt this text using C#. I've
      > > extracted the 192 bit key using the getEncoded() method of the
      > > SecretKey Java class. However when I use this key in .NET i cannot
      > > decrypt the cipher text.
      > >
      > > I am pretty sure that all my settings are correct, as far as setting
      > > the ECB mode, PKCS5 padding and converting the cipher text to byte
      > > arrays. I think it's the key that is giving me problems. Is there
      > > anything that I must do to the exported java key before I use it in
      > > .NET ?[/color]
      >
      > AFAIK, Java provides you with a 192-bit parity-adjusted key and .NET
      > requires a 168-bit non-parity-adjusted key. I don't think there is any
      > function in Java or .NET to remove the parity but it's simple enough to
      > implement (just a case of removing the LSB of each byte in the key).
      >
      > You also need to ensure that your IV is shared between the two applications.
      >
      > HTH[/color]

      Thanks for the reply,

      I tired extracting the 168 bit key by removing the parity bit. However
      now I get a "Specified key is not a valid size for this algorithm."
      exception when i try to use the key. I remember reading somewhere that
      ..NET / Crypto API igonore the parity bit anyways.

      Michael

      Comment

      • Michael Bebenita

        #4
        Re: Java CryptoAPI 3DES Key Compatibility

        thepuppet@sbcgl obal.net (Michael Bebenita) wrote in message news:<826f20ab. 0309071711.5e44 b2a4@posting.go ogle.com>...[color=blue]
        > "Gerard Krupa" <gerard@spamfre ebogbrush-zone.co.uk> wrote in message news:<dhG6b.91$ ca7.31@newsfep1-gui.server.ntli .net>...[color=green]
        > > "Michael Bebenita" <thepuppet@sbcg lobal.net> wrote in message
        > > news:826f20ab.0 309032241.4c7d1 d7b@posting.goo gle.com...[color=darkred]
        > > >
        > > > A Java application is encrypting a block of text using 3DES ECB mode
        > > > and PKCS5 padding. I need to decrypt this text using C#. I've
        > > > extracted the 192 bit key using the getEncoded() method of the
        > > > SecretKey Java class. However when I use this key in .NET i cannot
        > > > decrypt the cipher text.
        > > >
        > > > I am pretty sure that all my settings are correct, as far as setting
        > > > the ECB mode, PKCS5 padding and converting the cipher text to byte
        > > > arrays. I think it's the key that is giving me problems. Is there
        > > > anything that I must do to the exported java key before I use it in
        > > > .NET ?[/color]
        > >
        > > AFAIK, Java provides you with a 192-bit parity-adjusted key and .NET
        > > requires a 168-bit non-parity-adjusted key. I don't think there is any
        > > function in Java or .NET to remove the parity but it's simple enough to
        > > implement (just a case of removing the LSB of each byte in the key).
        > >
        > > You also need to ensure that your IV is shared between the two applications.
        > >
        > > HTH[/color]
        >
        > Thanks for the reply,
        >
        > I tired extracting the 168 bit key by removing the parity bit. However
        > now I get a "Specified key is not a valid size for this algorithm."
        > exception when i try to use the key. I remember reading somewhere that
        > .NET / Crypto API igonore the parity bit anyways.
        >
        > Michael[/color]

        Forget all that, there was no compatibility problem. The error had to
        do with something unrelated.

        Comment

        Working...