RE: p1619 (disk): Security concerns of LRW and an alternative mode
Thanks Matt for this excellent analysis - it's more than just hand-waving. I was wondering at the
start about the probablility of collisions but then the penny dropped and it does all make sense.
> Concerning LRW mode:
> There is a possible security problem if Key2 is poorly chosen.
> The problem is especially bad if Key2 is a relatively short ASCII password.
Agreed entirely. Crypto keys should never normally be chosen like this. Ideally they are derived
using a True-RNG or a strong Psuedo-RNG seeded with a hashed password. This should be made VERY
clear in the LRW spec.
> Recovering Key2 in LRW:
> Frequently, (I1 + I2) will result in the same value, so it should be possible
> to precompute all the most common values, making a software-based attack feasible.
In fact, for consecutive I1+I2 there are only 128 distinct values (1,3,7,15,...all-ones) and
provided that these can be inverted in the specified GF field (sometimes there is no inverse) this
can be done completely up-front, today, and the only "hacking" work is doing the multiplies in:
Compute (C1 + C2) * some_possible_constants = K2
and waiting for the collisions. You can even extend this to use blocks spaced 2,4,8 etc apart which
half the time will have only a single bit of difference in I1+I2 (more likely to be invertible?) and
get even more block pairs to work with.
> Covert Channel with LRW:
More worrying is the possibility that an attacker could write plaintext blocks which are
differentially encoded in a particular manner to deliberately reveal K2 more quickly?
> It might even be possible to encode K1 in this manner, causing a total loss of security.
Yes, if they knew K1...
> Notes on alternative mode:
> I've attached a picture for a slightly different tweak mode that replaces the Galois
> multiplier with a second AES engine. Has anyone seen a mode like this? In particular,
> is there any known IP claims to this mode? (I do not make any claims myself)
> - It is possible to implement this using less hardware by reusing the AES engine. The
> throughput would be half as much, but this may not matter with laptop hard disks.
I've not seen anything like this proposed before. It is well worth considering.
Implementation-wise it is rather nice because of re-use possibilities and parallelizability,
although it will be higher logic area for equivalent throughput.
Colin.