network profile
|
Nov 21 |
accepted | Will varying plaintext compensate for a fixed initialisation vector? |
|
Nov 21 |
comment |
Will varying plaintext compensate for a fixed initialisation vector? Thanks for your interest. As I'm in the process of doing a 'responsible disclosure' to the manufacturer, I don't want to go into more detail yet, but will definitely come back once the process is concluded. |
|
Nov 20 |
comment |
Will varying plaintext compensate for a fixed initialisation vector? Hmm, I can't quite get my head round that. Obviously, assuming we can only use whole byte offsets, then 8-bits is the 'least bad'. But I still can't quite see how we get beyond the first character that doesn't match the single known plaintext. ? |
|
Nov 20 |
comment |
Will varying plaintext compensate for a fixed initialisation vector? On further reflection, although I'm not defending the option, how do you get more than the first character of the PAN, if the offset is 8 bits? |
|
Nov 20 |
comment |
Will varying plaintext compensate for a fixed initialisation vector? A small detail: if one uses a CFB offset of 8 bits, am I right in thinking it's a little bit more complex that just C=EK(0)⊕P? |
|
Nov 20 |
comment |
Will varying plaintext compensate for a fixed initialisation vector? Thank you. In the light of your excellent answer I've (a) Moved my accept tick (again), and (b) added further detail to the question. |
|
Nov 20 |
revised |
Will varying plaintext compensate for a fixed initialisation vector? Added commentary following answers |
|
Nov 19 |
comment |
Relative merits of AES ECB and CBC modes for securing data at rest Thank you. The lesson 'Crypto is hard' is well taught, and, I hope, well learned. |
|
Nov 19 |
accepted | Relative merits of AES ECB and CBC modes for securing data at rest |
|
Nov 19 |
awarded | Student |
|
Nov 19 |
asked | Will varying plaintext compensate for a fixed initialisation vector? |
|
Nov 19 |
comment |
Relative merits of AES ECB and CBC modes for securing data at rest @StephenTouset : Thank you. Would two copies of an eight-byte timer, appended together, provide an adequate IV? The timer changes, as a minimum, every microsecond, and only repeats after 130 years. |
|
Nov 18 |
awarded | Scholar |
|
Nov 18 |
awarded | Supporter |
|
Nov 18 |
comment |
Relative merits of AES ECB and CBC modes for securing data at rest Thank you for an really good answer. "Don't roll your own" is, of course, extremely good advice, worth a forbidden extra point. |
|
Nov 18 |
awarded | Editor |
|
Nov 18 |
revised |
Relative merits of AES ECB and CBC modes for securing data at rest Added clarification on use of ECB mode and of CBC mode with fixed IV |
|
Nov 18 |
comment |
Relative merits of AES ECB and CBC modes for securing data at rest Thank you. Yes, I understand the problem of a body of different messages with some matching plaintext blocks, but (just) in this case, the messages are all only one block long, and the only matches will be between completely identical messages. Does this affect your comment? Please add to your answer, if you believe this significant. Of course, a general rule of "don't use ECB mode" is sensible. |
|
Nov 18 |
asked | Relative merits of AES ECB and CBC modes for securing data at rest |
|
Nov 17 |
awarded | Autobiographer |
