WS_FTP crypto.

Anonymous (nobody@replay.com)
Sun, 3 Jan 1999 10:13:38 +0100

• Next message: Paulo Barreto: "Re: Crypto++ 3.0 released"
• Previous message: Peter Gutmann: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"

Hello folks,
I've just starting playing with cryptanalysis (that's why I feel quite
uncomfortable asking these questions), anyway here it goes:

I decided to play with WS_FTP new `crypto' algorithm as an exercise, which
it uses to store passwords in its ini file to figure out how it processes
the password to `cipher' it. I think reversing this would be one way to
go(just run debugger and see what it does), but I wanted to try to figure it
out another way:

so what we have here is:

a plain text, a ciphered text, and a black box which transforms the plain
text into ciphered text. So now I am trying to figure out the way it does
it using `Applied Cryptography' as a handbook guideline.

After some minutes playing with their crypto, I figured out that the length
of password is quite findable and is the length_of_`ciphered'_text-16.
Also trying to change bytes in ciphering text, i found out that it has
following form:
[16bits_key][encrypted_passwd_characters]

already few weaknesses pop in mind:

1. 16bits key depends only on username/password, which is supposed to match
this password, so generating the key twice for the same name and password
will give the same key. (bad)

2. the password is not padded in any sort of way (why?), which would make
not quite possible guessing the length of passwd right away.

However, this seem to be a better crypto since the last one they used was
pretty fancy : the ascii character was just xor'ed with a position number of
passwd character.

Anyway here's an example of a password 'a' encrypted with a key generated
based on username 'a'
UID=a
PWD=V9B293464D1FB5302905AE617460E90D29A

so here
V is some kind of their signature. (without V, it won't detect that sequence
is ciphered passwd)

9B293464D1FB5302905AE617460E90D2

is a key, which resembles some kind of MD5 hash. (but is not, anything
else?)

 and 9A is encrypted 'a' password.

 I am wondering what would be the common techniques to figure out the way
the 'blackbox' transfers 'a' into '9A' using the key above?

Another interesting thing is that their 'crypto' can not handle an empty
string properly, so when you encrypt an empty password:

UID=a
PWD=V68BC4B6721E5E1CD250BAF3F54D11BE7

decryption brings you that your password is 'V'. hmm.

I would appreciate any ideas, hints, pointers regarding this matter

best regards

C^HAnonymous :)

PS: the copy of ws_ftp could be found at www.ipswitch.com site, if anyone is
interested playing with it.

• Next message: Paulo Barreto: "Re: Crypto++ 3.0 released"
• Previous message: Peter Gutmann: "Re: Death of PGP Key 0xFBAF5E44 at 19:03 02 Jan 1999 UTC"