Encryption/Decryption on both Java and Delphi

[Aidan Diffey]

Hi,

We are looking for a component or code to allow us to encrypt and
decrypt user passwords in both Java and Delphi
e.g. passwords stored in a single database accessible by both platforms.

We have looked at Triple DES in LockBox (Delphi) but it uses a 16 byte
array in Delphi and a 24 byte array in Java, so is not cross-platform
compatible.

Our essential requirement is for something that produces the same
results from both Delphi and Java code - the cipher strength is not that
important...

Can anyone point us in the right direction?

Any assistance would be much appreciated!

Regards

Aidan

 

[Igor Planinc]

Hi,

We are looking for a component or code to allow us to encrypt and
decrypt user passwords in both Java and Delphi
e.g. passwords stored in a single database accessible by both platforms.

We have looked at Triple DES in LockBox (Delphi) but it uses a 16 byte
array in Delphi and a 24 byte array in Java, so is not cross-platform
compatible.

Our essential requirement is for something that produces the same
results from both Delphi and Java code - the cipher strength is not that
important...

Can anyone point us in the right direction?

Any assistance would be much appreciated!

Markus Hahn wrote a lot of encryption tools. Among them implementations of
Blowfish for Delphi, C++, .NET, Java, ...

http://www.hotpixel.net/software.html

 

[Roedy Green]

Our essential requirement is for something that produces the same
results from both Delphi and Java code - the cipher strength is not that
important...

That requirement makes the job at least 10 times harder. Everything
has to match to the bit in every implementation detail. Consider using
the same code with a bridge to the other world.

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That requirement makes the job at least 10 times harder. Everything
has to match to the bit in every implementation detail. Consider using
the same code with a bridge to the other world.

These are well defined algorithms. I'm sure if the original poster
looked a bit closer at 3DES they could figure out the problem. There
are only a handful of reasons why they wouldn't be identical. If they
just want a password hash any algorithm will work fairly well. Why not
use a secure hash like MD5 or SHA1 or SHA2? They are all used to hash
passwords.

Or do you need to be able to read the passwords again with a key? This
usually isn't what you want.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDV96hi2ZgbrTULjoRAsZ9AKDKqHRK8K45r0a+yemylrqDF5IU8ACdHc7v
Vgd9Y/pE7WBj1qrFv7sv0aU=
=FenN
-----END PGP SIGNATURE-----

 

[Roedy Green]

These are well defined algorithms. I'm sure if the original poster
looked a bit closer at 3DES they could figure out the problem. There
are only a handful of reasons why they wouldn't be identical. If they
just want a password hash any algorithm will work fairly well. Why not
use a secure hash like MD5 or SHA1 or SHA2? They are all used to hash
passwords.

Look at JCE. You will see there are more ways to do each algorithm
than there are ways to order chow mein

The core algorithm may be standard, but you have all manner of
optional ways of salting and packing.
..
When you do Java-Java all that really matters is getting the options
set the same way. With different languages you need to have an
intimate understanding of what all that stuff means. Your best bet
would be to find a package that is reputed to be interoperable under
your two languages on the given platforms. Trying to mesh together
packages from different authors could end up being more work that
writing your own implementations.

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The core algorithm may be standard, but you have all manner of
optional ways of salting and packing.

This should all be specified by the implementation of the algorithm
though, no matter what language you are using. There really aren't that
many ways to do this (the salting, I'll give you, but it should be obvious
if you are using the same way).

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDWHHPi2ZgbrTULjoRAgrUAKCR6wXZCUjiHy1jUkJk3e7wxwb5igCgmbrn
/J7s7AMLpSMHN8MP7iyj0yc=
=Un0c
-----END PGP SIGNATURE-----

 

[Stefan Schulz]

Hi,

We are looking for a component or code to allow us to encrypt and
decrypt user passwords in both Java and Delphi
e.g. passwords stored in a single database access

Why do you have to decrypt the passwords again? Usually, you will want to
merely hash the passwords with some secure hash (both java and delphi have
implementations of the most common algorithms, which should produce the
exact same output), and then merely compare the input password hash with
the stored hash. This has the advantage that noone (not even you) can
guess what the password leading to a hash is. Taken to the extreme, you
could print the hashes out and plaster them all over town, and noone would
be the wiser.

 

[Igor Planinc]

Your best bet
would be to find a package that is reputed to be interoperable under
your two languages on the given platforms.

Hahn's implementations are not only reputed to be interoperable. They, in fact, are.

 

[Igor Planinc]

Why do you have to decrypt the passwords again? Usually, you will want to
merely hash the passwords with some secure hash (both java and delphi have
implementations of the most common algorithms, which should produce the
exact same output), and then merely compare the input password hash with
the stored hash. This has the advantage that noone (not even you) can
guess what the password leading to a hash is. Taken to the extreme, you
could print the hashes out and plaster them all over town, and noone would
be the wiser.

I'll take a wild guess, but that's a common practice with various web-based
services. They usually have the "Forgot your password? No problem! We'll send it
to you." option with everything requiring registration. No use having just
hashes. One must have access to cleartext passwords. Clearly one should only
decrypt them when needed, but otherwise store them safely encrypted in some
shady spot. ;-)

 

[Chris Uppal]

I'll take a wild guess, but that's a common practice with various
web-based services. They usually have the "Forgot your password? No
problem! We'll send it to you." option

Sounds likely, but it's not good practise. Better is to generate a new
password and send that. Better still is to generate a new /one-shot/ password
which the user has to change immediately. I'm sure there are better ideas
still, but I haven't seen them myself.

-- chris

 

[Igor Planinc]

Igor Planinc wrote:




Sounds likely, but it's not good practise. Better is to generate a new
password and send that. Better still is to generate a new /one-shot/ password
which the user has to change immediately. I'm sure there are better ideas
still, but I haven't seen them myself.

-- chris

Sure. But the primary concern of those companies is not security. It's profit.
That more than anything else means keeping customers happy. And they're not
happy if security (sic!) procedures are too complex (including having to
remember dozens and dozens of different passwords).

 

[Chris Uppal]

Sounds likely, but it's not good practise. Better is to generate a new
password and send that. Better still is to generate a new /one-shot/
password which the user has to change immediately. [...]

Sure. But the primary concern of those companies is not security. It's
profit. That more than anything else means keeping customers happy. And
they're not happy if security (sic!) procedures are too complex
(including having to remember dozens and dozens of different passwords).

Agreed.

But generating a new password is actually /more/ convenient for the user. That
user is presumably at least /slightly/ security minded or s/he would not have
used a password that they could conceivably have forgotten -- even if it's just
a matter of forgetting /which/ of their children's names s/he used. Sending a
new password will allow the user to set their password to something they can
remember (which might happen to be the same as the one they'd forgotten, and
might well be the same as the password they use for their online banking,
etc...) but at least they are setting it to what /they/ choose, and without
some idiot organisation sending their choosen password around world in clear.

Put it this way -- if "you" keep my password in clear[*] in your database, then
you are forcing me to use a different password for your site. And that's
inconvenient for /me/ without providing any extra profit for /you/. (Unless
you count the reduced cost of not having to hire competent programmers as a
significant saving of course... ;-)

([*] which includes any reversible form of encryption)

-- chris