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.
