Encryption/Decryption on both Java and Delphi

Thread view:

Aidan Diffey - 20 Oct 2005 11:01 GMT

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

Reply to this Message

Igor Planinc - 20 Oct 2005 11:31 GMT

> Hi,
>
[quoted text clipped - 13 lines]
>
> 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

Reply to this Message

Roedy Green - 20 Oct 2005 11:56 GMT

>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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Kenneth P. Turvey - 20 Oct 2005 19:15 GMT

>>Our essential requirement is for something that produces the same
>>results from both Delphi and Java code - the cipher strength is not that
[quoted text clipped - 3 lines]
> 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 <kt-usenet@squeakydolphin.com>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: kpturvey@jabber.org
Phone: (314) 255-2199

Reply to this Message

Roedy Green - 21 Oct 2005 02:48 GMT

>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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

Reply to this Message

Kenneth P. Turvey - 21 Oct 2005 05:43 GMT

> 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 <kt-usenet@squeakydolphin.com>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: kpturvey@jabber.org
Phone: (314) 255-2199

Reply to this Message

Igor Planinc - 21 Oct 2005 19:10 GMT

> 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.

Reply to this Message

Stefan Schulz - 21 Oct 2005 13:10 GMT

> 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. ;)

Signature

You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Reply to this Message

Igor Planinc - 22 Oct 2005 15:45 GMT

>>Hi,
>>
[quoted text clipped - 10 lines]
> 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. ;-)

Reply to this Message

Chris Uppal - 22 Oct 2005 15:56 GMT

> 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

Reply to this Message

Igor Planinc - 22 Oct 2005 16:02 GMT

>>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
[quoted text clipped - 6 lines]
>
> -- 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).

Reply to this Message

Chris Uppal - 24 Oct 2005 09:12 GMT

> > 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

Reply to this Message

Encryption/Decryption on both Java and Delphi

Free Magazines