Timeline for Lessons learned and misconceptions regarding encryption and cryptology
Current License: CC BY-SA 2.5
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2013 at 15:43 | comment | added | makerofthings7 | This also opens the door for a Two time pad attack, that bit Microsoft PPTP. The first version of PPTP used the same key in the client and the server | |
| Apr 17, 2012 at 7:28 | history | wiki removed | AviD♦ | ||
| Mar 3, 2012 at 0:42 | comment | added | Maarten Bodewes | Interesting, I know of some memory cards that use that scheme with the last part of the cipher block as the IV for the next. I'll look into it. Thanks D.W, guess my hunch was right about that. | |
| Mar 3, 2012 at 0:17 | comment | added | D.W. | @owlstead, Yes, using the last block of ciphertext as the IV for the next block, together with CBC mode, led to the BEAST attack on SSL. P.S. A SSC could work to separate the two channels but you'd have to be careful with it. You'd have to increment it for both sending and receiving (using two SSCs, one for each direction, would defeat the purpose). Also the SSC will require both sides to be synchronized and will not tolerate packet drops, which may be problematic in some settings. It may be easier to just use two independent keys. | |
| Mar 2, 2012 at 20:57 | comment | added | Maarten Bodewes | Or you could have a SSC, a secure session counter, increased for each encryption (within half duplex commmunication). I've even seen an example where the last block of ciphertext of the other party was used as the IV for the next block, but that might lead to some peculiar attacks. | |
| Feb 20, 2011 at 3:48 | history | answered | D.W. | CC BY-SA 2.5 |