AES/Rijndael expert needed
#1
I need an AES/Rijndael expert to take a look at an algorithm derived from AES. It uses the password as part of the symmetric encryption/decryption key.
Original encryption key: ABCDEFGHIJKLMONOPQRSTUVXYZ
E.g. password = 12345
New encryption key: 12345ABCDEFGHIJKLMONOPQRST
#2
i have looked at it.
#3
(06-04-2012, 01:09 PM)undeath Wrote: i have looked at it.

I have said this before undeath, you don't say much but you are quite funny when you do ! Big Grin
#4
Much better idea would be to use a key derivation function like PBKDF2 with ïnitial symmetric key as salt with some good iterations count. Applying the password directly is a bad idea, you are weakening the cryptosystem. Assuming your symmetric key was generated using a good RNG, concatenating it to the password reduces the key entropy.

If the initial symmetric key is unknown to the attacker and is not reused with other passwords, you would be much beter off mixing (XOR-ing) the key with the password rather than concatenating them.
#5
(06-04-2012, 03:06 PM)gat3way Wrote: Much better idea would be to use a key derivation function like PBKDF2 with ïnitial symmetric key as salt with some good iterations count. Applying the password directly is a bad idea, you are weakening the cryptosystem. Assuming your symmetric key was generated using a good RNG, concatenating it to the password reduces the key entropy.

If the initial symmetric key is unknown to the attacker and is not reused with other passwords, you would be much beter off mixing (XOR-ing) the key with the password rather than concatenating them.

+1

Based on how fast Hashcat is, I'd suggest try to use a known (BouncyCastle, perhaps, in Java or .NET) PBKDF2 function, with SHA-512 (or SHA-256) as the hash, a long (12 byte plus) cryptographically random salt, and run a few hundred thousand iterations each time. Bounce any suggested passwords against a dictionary check that also looks for hashcat/jtr/etc. rules based checks, to see if they're bad.

Non-dictionary based checks such as "At least one of upper, lower, number, symbol, minimum 8 characters" leads to people choosing:
P@$$w0rd
#6
Thanks! I would like to know whether someone would be able to crack this modified algorithm in a reasonable time with average CPU+GPU hardware, because of the strength of AES itself. Will it be faster or slower than the MD5 for example? Which can be cracked with 500 milion passwords a second with GPU.


Attached Files
.txt   visual basic aes.txt (Size: 17.13 KB / Downloads: 8)