Timeline for AES 256 Encryption - Is it really easy to decrypt if you have the key?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
|
|
| Feb 6, 2017 at 22:41 | history | edited | yyyyyyy | CC BY-SA 3.0 |
fix spelling (Auguste Kerckhoffs)
|
| Jul 18, 2013 at 9:03 | comment | added | SteveB | Thank you. The requirements are that only the encrypted value is stored in the database with a corresponding token. Each load of the value requires a scan to see if the value is already stored, if it is the same token must be returned. So each encrypted value must render the same encrypted value in order for a comparison to me made. I can't think of any other feasible way of doing it. Thanks again for your help and your patience. | |
| Jul 18, 2013 at 8:58 | vote | accept | SteveB | ||
| Jul 17, 2013 at 16:02 | history | edited | rath | CC BY-SA 3.0 |
added 135 characters in body
|
| Jul 17, 2013 at 15:55 | history | edited | rath | CC BY-SA 3.0 |
added 568 characters in body
|
| Jul 17, 2013 at 15:46 | comment | added | SteveB | In practical terms it would be very difficult for an attacker to get both the data and the key. But not impossible. I was curious to see how an attacker could derive the scheme, salt and iv just from an encrypted value if he had the key. | |
| Jul 17, 2013 at 15:39 | comment | added | SteveB | Yep - take your second point. If I change the IV I cannot meet one of the requirements in that encrypting the same value twice must create the same encrypted cypher text each time. That's a business requirement that I can't get around. | |
| Jul 17, 2013 at 15:36 | comment | added | SteveB | I'm really not saying it's not the point. My original question, which still hasn't been answered, is 'How easy is it to decrypt data if all you have is the encrypted data and the key and nothing else'. If it is very easy can someone explain the steps it would take to do so. | |
| Jul 17, 2013 at 15:32 | comment | added | rath | You can keep the scheme private if you want (and pray no one actually wastes enough time trying to figure it out) but at least change the IV mechanism. Moreover, if you plan on selling it or even branding it "secure", you can't just way it works because of PFM. People will ask how exactly it is so, and you'll have to tell them. Except if you're the only user. | |
| Jul 17, 2013 at 15:26 | comment | added | rath | Of course it is. That's the whole point of keeping a key secret. Also, I know you mean it in a different way but if you say "crypto is not the point" then the question is not for Crypto.SE. See this for more on why we assume the scheme is always public (although that's not the best reference you can find). @bhs | |
| Jul 17, 2013 at 15:08 | comment | added | SteveB | Ok, so that would be the case. However, my question still remains. If I had asked a different question and Kerckhoffs principle applied then I'd be happy to accept your suggestion. To elaborate, the crypto isn't the question here, I'm working on the assumption that an AES256 encrypted value without the key is safe. | |
| Jul 17, 2013 at 14:52 | comment | added | CodesInChaos | @bhs Then get out a time machine and travel back a few centuries. It is a core principle of modern crypto that it must be secure if the attacker knows everything about the scheme, except the key. | |
| Jul 17, 2013 at 13:43 | comment | added | SteveB | I'm not following Kerckhoffs principle. The attacker has the encrypted data and the key and nothing else. | |
| Jul 17, 2013 at 11:59 | history | edited | rath | CC BY-SA 3.0 |
added 17 characters in body
|
| Jul 17, 2013 at 11:58 | comment | added | rath | I see your point. I spoke before thinking on this one. Cheers @hunter | |
| Jul 17, 2013 at 11:54 | comment | added | hunter | Can you give an example of a non-deterministic KDF? Your concern about IV-generation is valid - if the OP is using a static salt (ie, doesn't change with each encryption) and the KDF used to generate the key/iv is deterministic (I'm assuming it must be if it's being used to generate the key) then logically the IV would be static as well (big no-no). To avoid this, the salt should be refreshed with each encryption. ThomasPornin addresses this strategy in some detail here. | |
| Jul 17, 2013 at 11:08 | history | answered | rath | CC BY-SA 3.0 |