Timeline for How can I mitigate against chosen plaintext attacks for AES ECB?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 19, 2016 at 9:52 | vote | accept | Tony | ||
| Jan 19, 2016 at 9:52 | comment | added | Tony | Thanks, I'm accepting this answer. It's not the answer I asked for but it's the one I needed. | |
| Jan 18, 2016 at 15:58 | history | edited | Stephane | CC BY-SA 3.0 |
Added warning against writing custom crypto code
|
| Jan 18, 2016 at 14:11 | comment | added | sethmlarson | Make sure you test your home-rolled crypto against an established implementation to make sure the outputs are exactly the same. | |
| Jan 18, 2016 at 13:53 | comment | added | Stephane | Yes, using CBC using an ECB routine internally is as easy as I described (if it's really ECB: if there is any diffuser, even a broken one, you're toast). But in the end, if there is a compatibility issue, the fact is that you can't have your cake and eat it too: if your crypto library is broken in a way that will make the result incompatible "standard" CBC, you will need to chose whether you want compatibility or stick to your broken code. | |
| Jan 18, 2016 at 10:51 | comment | added | Tony | Thanks. Ideally I'd like it to be compatible with a proper AES-CBC instance running on the server (I'm currently using Python's Crypto library, which handles the ECB stuff easily). Is it as easy as you describe to produce genuine AES-CBC? I like the idea, just want some certainty before I commit to developing it | |
| Jan 18, 2016 at 7:34 | history | answered | Stephane | CC BY-SA 3.0 |