ценная мысль разработчикам криптопротоколов (выдрано из контекста)
In many contexts it is quite hard to provide a hard guarantee about not repeating counters, eg can be hard to retain state eg javascript in different browsers on different machines for a roaming user, or in VMs that get rolled back, or disks that get recovered from backup. Also time is unreliable on user machines often. And sources of randomness can also be questionable in some browsers, VMs after rollback, and freshly imaged servers or VMs, or servers with no keyboard/mouse etc.
To have a crypto protocol which does not catastrophically break in event of a one in 100 chance per year of hardware boundary condition happening to your the compute environment is therefore a good idea. Or occasional failure to avoid reuse. There are more protocol fragility levels than "safe" and "broken". A third option is graceful degradation.
ie if you end up falling back to ECB of two different plaintexts for first cipher block of CBC barely hurts. Sending plaintext xors hurts alot.
Bear in mind disks as a rule of thumb fail at a rate of 1%/year and the hardware also similar (motherboard, memory, powersupply etc added together).
And when that happens a VM rollback or a disk replacement and backup recovery are likely to be the method of recovering. If your crypto is not tolerant to that environment you maybe have a problem. And its not outside of the realm of feasible that the attacker can externally influence the hw failure rate.
Similarly reusing k values in DSA/ECDSA is even more catastrophic, leaking the private key. (For DSA a counter-measure can be to generate k from MAC(secret, message) so that if the same message is signed, the same k value is used (which is obviously harmless as its the same serialization).
Adam Back
This entry was originally posted at http://wizzard.dreamwidth.org/286213.html. It has
comments. Please comment there using OpenID.
To have a crypto protocol which does not catastrophically break in event of a one in 100 chance per year of hardware boundary condition happening to your the compute environment is therefore a good idea. Or occasional failure to avoid reuse. There are more protocol fragility levels than "safe" and "broken". A third option is graceful degradation.
ie if you end up falling back to ECB of two different plaintexts for first cipher block of CBC barely hurts. Sending plaintext xors hurts alot.
Bear in mind disks as a rule of thumb fail at a rate of 1%/year and the hardware also similar (motherboard, memory, powersupply etc added together).
And when that happens a VM rollback or a disk replacement and backup recovery are likely to be the method of recovering. If your crypto is not tolerant to that environment you maybe have a problem. And its not outside of the realm of feasible that the attacker can externally influence the hw failure rate.
Similarly reusing k values in DSA/ECDSA is even more catastrophic, leaking the private key. (For DSA a counter-measure can be to generate k from MAC(secret, message) so that if the same message is signed, the same k value is used (which is obviously harmless as its the same serialization).
Adam Back
This entry was originally posted at http://wizzard.dreamwidth.org/286213.html. It has
comments. Please comment there using OpenID.