Hey

does anyone know what a pretty secure encryption algorithm is..like in asm code? and is there a better place to store an encrypted pw than in the registry..because if a user finds the pw key i spose they could simply delete it?

thanx

does anyone know what a pretty secure encryption algorithm is..like in asm code? and is there a better place to store an encrypted pw than in the registry..because if a user finds the pw key i spose they could simply delete it?

thanx

Depends on what sort of encryption you want. For normal symmetric

encryption (the stuff you use to encrypt files and such), Rijndael (AES)

or Twofish would be pretty good choices. Asm implementations should

be available, otherwise just link with a C version.

As for storing the stuff... the registry should be fine. Don't start

hiding it all sorts of weird places (ie, windows folder, or places in

the registry where it "doesn't belong"). A determined user will always

be able to find the password, so there's no use polluting the install...

and giving yourself problems like "urm, why doesn't this work under NT/2k".

And also, you'd make it harder to backup the app if you hide configuration

stuff all over.

Anyway... if you store the decryption key inside your app (which

sounds likely for password en/decryption?), there's no use in strong

crypto, and you might as well revert to some XOR scheme.

encryption (the stuff you use to encrypt files and such), Rijndael (AES)

or Twofish would be pretty good choices. Asm implementations should

be available, otherwise just link with a C version.

As for storing the stuff... the registry should be fine. Don't start

hiding it all sorts of weird places (ie, windows folder, or places in

the registry where it "doesn't belong"). A determined user will always

be able to find the password, so there's no use polluting the install...

and giving yourself problems like "urm, why doesn't this work under NT/2k".

And also, you'd make it harder to backup the app if you hide configuration

stuff all over.

Anyway... if you store the decryption key inside your app (which

sounds likely for password en/decryption?), there's no use in strong

crypto, and you might as well revert to some XOR scheme.

What's the problem if someone deletes the password?

Do you need to Decrypt the password once stored or can you compare string hashes? (does such word even exist?)

If the latter is suitable, then you could just use RudeBoy's MD5 implementation which lies out there somewhere. Just google around for about 5 seconds to get it.

If you are serious on the subject, get 'Applied Cryptography' By Bruce Schneier.

Latigo

Do you need to Decrypt the password once stored or can you compare string hashes? (does such word even exist?)

If the latter is suitable, then you could just use RudeBoy's MD5 implementation which lies out there somewhere. Just google around for about 5 seconds to get it.

If you are serious on the subject, get 'Applied Cryptography' By Bruce Schneier.

Latigo

"revert to some XOR scheme"

What do you mean by this? So if I XOR two bits, I can reverse that? (I'm tired and lazy to think about it)

What do you mean by this? So if I XOR two bits, I can reverse that? (I'm tired and lazy to think about it)

kenny..

if you xor something and then you xor the result.. u get what u started with

if you xor something and then you xor the result.. u get what u started with

Oh duh lol... Sorry I wasn't thinking clearly. It didn't occur to me that I had to xor it by the same thing :)

the most secure encryption scheme:

1) data to encrypt is in buffer B1

2) fill other buffer B2, of same size of data to encrypt, with random values

3) XOR B1 with B2

B1 is the crypt text, B2 is the key...

if hacker dont have B2, B1 is impossible to recover :alright:

ancev

1) data to encrypt is in buffer B1

2) fill other buffer B2, of same size of data to encrypt, with random values

3) XOR B1 with B2

B1 is the crypt text, B2 is the key...

if hacker dont have B2, B1 is impossible to recover :alright:

ancev

If my memory does not betray me, that's called a 'One Time Pad' encryption :P

Ltg

Ltg

ancev,

That's only moderately secure you can, if properly motivated, crack it using an analysis of the frequency of bit patterns vs frequency of letters used in the written language provided you have enuf data. Bletchly (sp?) Park kinda stuff.

-- ---------

A slight improvement (really only slight) would be to choose a hash value that isn't going to align with the chars (relatively prime to char length in bits)... say 121 bits long. Another slight (again emphasis on slight) improvement is to pad your text with pseudo-random bits inside the chars at pseudo-random places that are gotten from a pseudo-random number generator with a known (but floating) seed before the xor.

This stuff isn't trivial if you're looking for really good security & it's one of the areas where I'd actually recommend some book learnin' if you're hardcore serious about the topic.

That's only moderately secure you can, if properly motivated, crack it using an analysis of the frequency of bit patterns vs frequency of letters used in the written language provided you have enuf data. Bletchly (sp?) Park kinda stuff.

-- ---------

A slight improvement (really only slight) would be to choose a hash value that isn't going to align with the chars (relatively prime to char length in bits)... say 121 bits long. Another slight (again emphasis on slight) improvement is to pad your text with pseudo-random bits inside the chars at pseudo-random places that are gotten from a pseudo-random number generator with a known (but floating) seed before the xor.

This stuff isn't trivial if you're looking for really good security & it's one of the areas where I'd actually recommend some book learnin' if you're hardcore serious about the topic.

A one-time pad is the most secure form of encryption, but there's

a few things to consider.

First of all, it is *ONE-TIME*. If you use the same encryption "key"

more than once, you're phuked. Second, the key length has to be

the same as the data length. And third, using a simple XOR to encrypt

isn't optimal (statistical analysis, etc). I am by no means more than

a neophyte in the area of encryption, so don't take my word for it...

get yourself a copy of "Handbook of Applied Cryptography", it

is *very* good.

a few things to consider.

First of all, it is *ONE-TIME*. If you use the same encryption "key"

more than once, you're phuked. Second, the key length has to be

the same as the data length. And third, using a simple XOR to encrypt

isn't optimal (statistical analysis, etc). I am by no means more than

a neophyte in the area of encryption, so don't take my word for it...

get yourself a copy of "Handbook of Applied Cryptography", it

is *very* good.