On Fri, Aug 22, 2003 at 03:47:05PM +0200, Thierry Godefroy wrote: > > have you seen this? > > Bruce Schneier CRYPTO-GRAM, September 15, 2002 > > http://www.counterpane.com/crypto-gram.html > > No, I didn't see it... Interesting... But you didn't quote the conclusion:
I think it is not wise to quote any conclusion unless it is the mathematical proof of the possibility to crack (or not) the algorithm. Otherwise new attack techniques could be found any day. > Still, it's a good thing to stay tuned... Also, for really sensitive data, > it's better to use a double encryption scheme, using two different > algorythms (and keys, of course). this is a difficult subject, as far as I am aware opinions are fairly varied whether this will increase safety - in theory it might also hurt safety unless proven otherwise. > Yes, but even if a 060 can perform twice as fast as a Pentium at the same > frequency, the modern Pentiums/Athlons run at 20 times the 060 (core) > frequency... I have a datapoint with serpent256 here: # ll -rw-r--r-- 1 rz rz 98693120 Oct 5 2002 x.tar # time cat /tst-loop/x.tar >/dev/null real 2m14.115s user 0m0.190s sys 0m19.090s Loop dev used about 100s for the decryption. Depending on application this may be fast enough. Compared to raw read it appears to slow down things by factor 3 in the worst case. This is loop-AES with additional ciphers btw and I would recommend to stick with that as it will be maintained for the foreseeable future. The other intl patches are bound to suffer incompatible changes every week now that intl stuff was included into 2.6 I will send you the sources of patched util-linux, can be a real pain to sort out these patches. > > so it becomes immediately unmounted as soon as you close last > > reference? > > No, the device is permanently mounted and the driver reports an absent > medium when accessed without a proper medium in the drive... that looks very strange. Perhaps I can make some sense out of it when I see the patch. > ??? Never had a single problem compiling v2.4 kernels with gcc 2.95.3 > on Mandrake 7.2... _But_ I always used -fno-omit-frame-pointer to avoid > the -O2 optimization bug in gcc 2.95... it did strange things on m68k. Overwritten live registers as well as forgotten stack pointer and such. > Also, did you check this patch: > http://gcc.gnu.org/ml/gcc-regression/2000-11/msg00002.html > It was for egcs but it looks like the cure to the same problem we got > in gcc... Looking at the various patches, perhaps I have some idea. So far I have simply disabled the check in the compiler because it appears to be internal consistency checking only and should not trigger any new errors. Richard
