Timeline for Why can the last block contain a full block of padding in CBC Encryption?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 27, 2015 at 21:14 | vote | accept | Eugene K | ||
| Feb 26, 2015 at 20:05 | comment | added | Maarten Bodewes♦ | @dave_thompson_085 Amended answer. SSL is a strange protocol, too many choices that are not best practice. Fortunately the spec seems to be heading in the right direction. | |
| Feb 26, 2015 at 20:03 | history | edited | Maarten Bodewes♦ | CC BY-SA 3.0 |
added 79 characters in body
|
| Feb 26, 2015 at 3:50 | comment | added | dave_thompson_085 | Note that SSL/TLS is not quite the same as PKCS. SSL allowed 1-256 octets padding (not just 1-blocksize) in two notionally separate fields, a padding field of length 0-255 with unspecified and unchecked contents and a length field of 1 octet containing the length 0-255. That unchecked plus MtE gave the oracle. TLS changed to a padding field of length 0-255 with each octet containing the length, plus 1 octet also containing the length. In practice all implementations I've looked at only go up to the next block multiple, but the specs allow any block multiple up to 255+1=256. | |
| Feb 25, 2015 at 18:09 | history | answered | Maarten Bodewes♦ | CC BY-SA 3.0 |