Crypt decrypts data with different password

[Leo1906]

Hello there

Difficult to choose a title for this. I have a question regarding the Crypt functionallity build into Autoit.
Here is the example script:

#include <Crypt.au3>

Local Const $key1 = "CryptPassword"
Local Const $key2 = StringToBinary("CryptPassword")

ConsoleWrite("Key 1: " & $key1 & @CRLF & "Key 2: " & $key2 & @CRLF)

Local $sData = "..upon a time there was a language without any standardized cryptographic functions. That language is no more."

Local $encryptedData = encrypt($sData, $key1)
MsgBox(0, "Encrypted", $encryptedData)

$encryptedData = decrypt($encryptedData, $key2)
MsgBox(0, "Decrypted", $encryptedData)



Func encrypt($data, $key)
    Local $bEncrypted = _Crypt_EncryptData($data, $key, $CALG_RC4)
    Return $bEncrypted
EndFunc

Func decrypt($data, $key)
    $bEncrypted = _Crypt_DecryptData($data, $key, $CALG_RC4)
    Return BinaryToString($bEncrypted)
EndFunc

Modified from the helpfile. So now the question is .. why is the crypt function accepting the password in binary form and not the same form I used it the first time? Why is there no difference?
So I'm using the same password for crypting and decrypting (I know the title says bit different ..  ) but in different form. My question is: Why does the crypt function don't care about this? In "clear text" (for humans to read) the passwords are different (look @ console output).

Isn't this a bad thing? Imagine I want to use a password for crypting which has accidently the syntax of a binary value. Than there you could be able to decrypt the password with the String (I don't know how it's called) value of the password I intended to use ..?

 

Maybe somebody can explain this to me

 

Thanks

[spudw2k]

Best I can tell, the string gets converted into binary in the _Crypt_DeriveKey internal func when it set in the dllstruct.  If it's already binary there is no conversion.  

No security issue that I can see.  The UDF is doing the conversion for you.  If you used $CALG_USERKEY instead of RC4, it wouldn't call the derivekey func and would most likely not work.

 

edit: side-note.  Don't use RC4 if possible, it is not considered a secure encryption algorithm anymore.
Use 3DES at the minimum, but AES is better/stronger,

https://rdist.root.org/2009/08/06/google-tech-talk-on-common-crypto-flaws/

Edited February 3, 2017 by spudw2k