 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / May 2004Algorithm portability
Hello, I have a Delphi application that is supposed to produce enrcypted files that will be decrypted with JCE code on a server. I have tried a couple of cryptology-components for Delphi but I can't seem to successfully decrypt them. No problems encrypting/decrypting within Delphi or Java but interoperability seems to be the problem even if I seem to have all hash/algorithm/mode/padding stuff matched. Is it usually problematic to en/decrypt between different implementations of the same algorithms? Anyone have any working combination figured out for the Delphi/Java combination? Thanks in advance, Nik > Hello, > [quoted text clipped - 8 lines] > implementations of the same algorithms? Anyone have any working > combination figured out for the Delphi/Java combination? I don't know anything about Delphi. Are the Delphi and Java running on the same machine? On machines that are both little-endian or both big-endian? Are the ciphertexts the same length? Is one of them encoded in Base 64 and the other in hex? Does each produce the same ciphertext repeatedly when given the same plaintext and key? Are they choosing IVs at random? Do they produce the same ciphertext for a plaintext block of all binary zeros using a key of all binary zeros in ECB mode? Continue with other plaintexts and keys in ECB mode. If ECB mode works, try your chosen mode with known plaintext, key and IV. --Mike Amling >Is it usually problematic to en/decrypt between different >implementations of the same algorithms? Anyone have any working >combination figured out for the Delphi/Java combination? Is there something equivalent to bigInteger in Delphi? Perhaps you could roll you own encryption, then you know the libraries are identical. The code to use two primes as the private key and their product as the public one is pretty simple. It will do for encrypting small amounts of data. Another way is to decompile the delphi or Java library to figure out just how they differ. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >>Is it usually problematic to en/decrypt between different >>implementations of the same algorithms? Anyone have any working [quoted text clipped - 7 lines] > public one is pretty simple. It will do for encrypting small amounts > of data. I had assumed this was a symmetric cipher. It didn't occur to me that the OP could be trying to use public key crypto. > Another way is to decompile the delphi or Java library to figure out > just how they differ. --Mike Amling > I had assumed this was a symmetric cipher. It didn't occur to me that >the OP could be trying to use public key crypto. He did not say. I have written a public key encryption using just BigInteger so it could be used in Applets for old JVMs. It it pretty simple. Mr. Tines posted the core of it a few years ago. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >> I had assumed this was a symmetric cipher. It didn't occur to me that >>the OP could be trying to use public key crypto. > > He did not say. I have written a public key encryption using just > BigInteger so it could be used in Applets for old JVMs. If it's RSA, don't forget the padding. OAEP, PSS SAEP+ are hard to implement with just BigInteger. > > It it pretty simple. Mr. Tines posted the core of it a few years ago. --Mike Amling The most common padding PKCS #1.5 is pretty easy to implement (for either signature blocks, where padding is nulls, or encyrption blocks where padding is random). Then the exponentiation mod(Modulus) is trivial with Java 1.1. classes. - Mitch > >> I had assumed this was a symmetric cipher. It didn't occur to me that > >>the OP could be trying to use public key crypto. [quoted text clipped - 8 lines] > > --Mike Amling > The most common padding PKCS #1.5 is pretty easy to implement (for either > signature blocks, where padding is nulls, or encyrption blocks where padding is random). > Then the exponentiation mod(Modulus) is trivial with Java 1.1. classes. > - Mitch Those padding schemes have not been proved secure. To quote from the original OAEP paper, available at http://www.cs.ucdavis.edu/~rogaway/papers/oaep-abstract.html, whether or not [PKCS#1 and an IBM scheme] "work" depends on aspects of f beyond its being one-way, << where f is the RSA transform c=m**e. By comparison, OAEP has been proven to be secure if RSA is secure. See http://eprint.iacr.org/2000/061/, for the latest on it. Note: I'm using the term "secure" rather loosely. The papers have precise definitions. --Mike Amling >> The most common padding PKCS #1.5 is pretty easy to implement (for either >> signature blocks, where padding is nulls, or encyrption blocks where [quoted text clipped - 10 lines] > << > where f is the RSA transform c=m**e. Should be c=m**e mod n > By comparison, OAEP has been proven to be secure if RSA is secure. See > http://eprint.iacr.org/2000/061/, for the latest on it. [quoted text clipped - 3 lines] > > --Mike Amling  Signature--Mike Amling > If it's RSA, don't forget the padding. OAEP, PSS SAEP+ are hard to >implement with just BigInteger. Here's the trick I used. /* first byte ensures lead 0s are not lost when the message considered as a number. It must be a positive random number between 1 and 127 */ byte lead = (byte)(wheel.nextInt(127) + 1); message[0] = lead; I discard this byte on decrypt. -- Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.