March 17th, 2013, 08:14 PM
Quick question about Rijndael/AES decrypt rounds
Is decrypting something that's been encrypted using Rijndael/AES and a known passphrase independent of the number of rounds that was used during the encryption process?
March 17th, 2013, 08:35 PM
No, successful decryption is not independent.
However, nobody need worry about this, because the standard specifies the number of rounds for each key size.
So, if the system conforms to AES, decryption will be successful if the same key is used.
Note: A key is not the same thing as a passphrase.
March 17th, 2013, 08:41 PM
Don't you need the passphrase to generate the key for the decryption process?
Originally Posted by mah$us
But if I'm working with the Rijndael where the number of rounds is NOT (necessarily) standardized; the number of rounds used for the encryption process should be the same as the number of rounds that's used for the decryption process, right?
(I'm not seeing that right now. I've spent the better part of today playing with that and either I'm doing something wrong (which is HIGHLY probable since I am SOOO NOT a programmer) or that it's not updating the libraries correctly when I go to recompile with a different number of rounds and trying to decrypt it with THAT rather than with what it was originally encrypted with (trying to figure out what would happen if the number of encryption rounds is different than the number of decryption rounds). All evidence so far - as long as the key/passphrase is known, it doesn't seem to matter how many decryption round there is.)
Unless this is more of a CBC thing rather than a Rijndael/AES thing. *shrug* (which is what I'm trying to determine now - or trying to figure out why the result is not matching up to my expected result).
March 17th, 2013, 09:58 PM
You don't need the passphrase if you already know the key; however, if the key was originally generated from a passphrase and you don't know the key, then knowing the passphrase would be one way to acquire the key.
In that case, presumably some algorithm like pkbdf2 was applied to the passphrase to generate the key, and in that case you do need to know the number of rounds to get the key. Keeping the number of rounds secret is not necessary or even particularly useful from a security perspective. Also the number of rounds used to stretch the passphrase has no relationship to the number of rounds used during encryption.
March 17th, 2013, 10:01 PM
Then, something is very broken in the implementation. Any change in the number of rounds will change the results of encryption, or decryption, drastically! In each round, a good block cipher transforms the data so intensively, it's own mother would not recognize it
As for the number of rounds, why not follow AES? Whatever number of rounds you decide on, stick to that number, and do the same number of rounds on encryption and decryption.
You should be able to find "test vectors" online, blocks of data in both plain and encrypted forms (along with test keys). When you encrypt the test plaintext with the test key, your encrypted output should match the output given with the vector. This is the easiest way to test the software. Running the test vectors successfully doesn't prove there isn't a bug, but it does offer some confidence. But if your output fails to match when you run a test vector, you know for sure something is wrong.
No, a passphrase is not necessary for key generation. Passphrases are usually used in one of two different ways:
1. A key is generated using techniques to make it as random as possible, and stored in a file in encrypted form (yes, the key itself is usually encrypted). The passphrase is then used to unlock the file.
2. A key is generated using the passphrase as a seed for pseudo-random number generation. This is usually less secure, because people rarely use a passphrase with less entropy than the keysize.
Either way, security is reduced, when the passphrase is too simple. But with the first method, an attacker has to get the secret key file; without it, guessing the passphrase is of no help to him.
March 17th, 2013, 10:12 PM
Well, I've been playing around with it.
I downloaded the OpenSSL source and then edited the aes_core.c and aes_x86core.c (don't quote me on that second filename though; I might have it wrong, but there were two files that I edited. Actually I started with one and found out that by changing the number of rounds the ENCRYPTED file was different than the one that came with OpenSSL by default (which for AES would be 10, 12, and 14 rounds respectively).
But when I tried to decrypt the ENCRYPTED file (that has a different number of rounds) and then used the version that default version (which - again comes with the default number of rounds), I end up with my original file back (the same as if I were to decrypt it with the appropriate number of rounds executable).
So the part that's been baffling me is if the two encrypted files are different after encryption, and then I'm purposely trying to decrypt one with a different number of rounds - it doesn't seem to do it (or matter). I get the original file back. But the fact (to me so far at least) that the two encrypted files ARE different after using a different number of rounds; would tend to suggest that the changes I made to the aes_core and aes_x86core is working.
And to make my life simple, both are using the same keys, but I don't necessarily know if they're using the same IVs.
Would it then be better to transmit the key or the passphrase that's used to generate the key? Which would be more secure? Or would both be a dumb idea/equally insecure?
March 17th, 2013, 10:14 PM
I'm under the impression that more rounds = more secure. Unless that's an incorrect assumption/way of thinking, hence why I am trying to up the number of rounds from the AES standard.
March 17th, 2013, 10:54 PM
Meaning no disrespect, I see a sort of paradox in the approach you have described. If I understood correctly, you want to increase the number of rounds, to get more security, yes?
By far, the best thing you can do for security, is to leave the OpenSSL code as it is -- touch nothing! It has been carefully put together, and tested.
You have described yourself as "not a programmer" and obviously are new to cryptography. The best way for non-experts to maximize security, is to use the trusted tools that are available.
Now, as a purely ACADEMIC question, it is possible that increasing the number of rounds would increase the degree of security. However, the rounds for AES were VERY CAREFULLY CHOSEN to obtain a secure cipher. It's possible that tomorrow, somebody will find a break on against the numbers of rounds in AES -- but so far, the cipher has held up very well indeed.
Having taken a quick glance at the code, the OpenSSL encrypt and decrypt functions take a 'key' argument that is actually a C-struct. The encrypt function computes the number of rounds based on the key size (as required by AES), and stores this in the struct. If in your test, the same struct is being passed to the decrypt function -- well, that function will carry out the non-standard number of rounds you are testing, because the key struct tells it to.
This is perhaps the explanation for your test results.
But seriously, you are 1000 times more likely to compromise security by messing with this stuff, than to improve it.
March 17th, 2013, 11:07 PM
It can't hurt for me to try. It certainly won't kill me.
Originally Posted by mah$us
Yea, so the part where it says the number of rounds based on key size is in the code. So what would really prevent me or you or someone else from going in there and changing those values from 10, 12, 14 to something else, something else, and something else?
And as long as you can update both the encrypt and decrypt functions and then copy and paste the number of rounds that you need
(in the code, they write:
/* round 1: */
Copy that as you need it to match the new number of rounds that you've edited above; it should work right?
And that's what I did. But I go to decrypt it using the original openssl (rather than the new one that I've updated and compiled and installed to /usr/local/ssl/bin); it's still able to decrypt it with the one from /usr/bin (which is the original version with the 10, 12, and 14 rounds respectively).
And I'm just trying to learn about why it seems like that the decrypt is number-of-round independent (given two versions of the compiled executable with different number of rounds hardcoded into it).
March 17th, 2013, 11:32 PM
If the key is stored in a file, then the file probably has the entire AES_KEY struct, including the non-standard number of rounds. This would explain why decryption works.
No, it won't kill you to try these experiments.
However, I presume that you want to use a secure cipher in order to protect the confidentiality of some data. If confidentiality is lost, some undesirable consequence is feared -- otherwise, why bother encrypting? Depending on the application, loss of confidentiality could mean economic losses; embarrassment; loss of reputation or position; civil penalties; imprisonment; sometimes, violence, torture, or death. I'm guessing that, because you don't think AES -- the gold standard at this time -- is secure enough, the consequences of lost confidentiality are of some importance.
Whatever the consequences may be, a tinkerer who starts messing around with cryptography should be ready to pay those consequences in full, because the risk of breaking something that worked well is very high indeed.
Years ago, I drove over a mountain range. In the ever-steepening approaches to the pass, I saw, over a number of miles, dozens of signs warning about the difficulties and dangers of the pass, the extreme steep gradients, the treacherous conditions that could occur in rain or snow, etc.
The last sign actually announced that there would be no further signs -- at the bottom it read, "You Have Been Warned."
Well, you have been warned, my friend. Knock yourself out!
March 17th, 2013, 11:49 PM
AFAIK, the key isn't stored in a file. The way that I'm testing it out now is that a passphrase is required (so for the simple test, I'm just using 'passphrase' as the passphrase) and so when I go to decrypt it, I am using:
$ openssl enc -d -aes-256-cbc -pass passphrase -in file.enc -out file.dec
and then in the case where I've modified the number of rounds, it's:
$ /usr/local/ssl/bin/openssl enc -d -aes-256-cbc -pass passphrase -in file.enc.15rounds -out file.dec.15rounds
And then I run a diff against the original file to make sure that it's the same.
And then I try it again where I use the original openssl executable (14 rounds for 256-bit)
$ openssl enc -d -aes-256-cbc -pass passphrase -in file.enc.15rounds -out file.dec.1415rounds
and then run a diff against the original and the last file (and they manage to be the same).
So unless the AES_KEY struct is being written into the encrypted file along with the encrypted file; then I'm at SUCH a loss as to why it isn't working. Or why decrypting a 15 round file with 14 rounds will be able to give me the original file back (as indicated when I run the diff against the original). That's why I'm so confused.