On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote: Hi, > Actually, this is not quite exact. It is true that more cryptoanalyis > was done on Serpent (which algorythm is easier to analyse). But so far > more rounds have been broken in AES (Rinjdael) than in Serpent (unless > I missed one of the lastest articles about thos algorythms, which is > possible).
have you seen this? Bruce Schneier CRYPTO-GRAM, September 15, 2002 http://www.counterpane.com/crypto-gram.html << Let's start from the beginning. A few months ago, Courtois and Pieprzyk posted a paper outlining a new attack against Rijndael (AES) and Serpent. The authors used words like "optimistic evaluation" and "might be able to break" to soften their claims, but the paper described a better-than-brute-force attack against Serpent, and possibly one against Rijndael as well. Basically, the attack works by trying to express the entire algorithm as multivariate quadratic polynomials, and then using an innovative technique to treat the terms of those polynomials as individual variables. This gives you a system of linear equations in a quadratically large number of variables, which you have to solve. There are a bunch of minimization techniques, and several other clever tricks you can use to make the solution easier. (This is a gross oversimplification of the paper; read it for more detail.) The attack depends much more critically on the complexity of the nonlinear components than on the number of rounds. Ciphers with small S-boxes and simple structures are particularly vulnerable. Serpent has small S-boxes and a simple structure. AES has larger S-boxes, but a very simple algebraic description. (Twofish has small S-boxes, too, but a more complex nonlinear structure. No one has implemented the attack against Twofish, but I'm not willing to stand up and declare the cipher immune.) These are amazing results. Previously, the best attacks worked by breaking simplified variants of AES using very impractical attack models (e.g., requiring immense amounts of chosen plaintext). This paper claimed to break the entire algorithm, and with only one or two known plaintexts. Moreover, the first cipher broken was Serpent: the cipher universally considered to be the safest, most conservative choice. >> > The reason why Rinjdael was choosen as the AES instead of Serpent is > unclear and even highly suspicious to me... It is admitedly a little > faster than Serpent, but was pointed out as less secure than Serpent > too (and as it was not as much crypto-analyzed as Serpent, one may find > a shortcut attack on day or another...). My thought is that the NSA is > probably quite interested in having an AES algorythm which is not too > difficult to break... quite possible. There are other reasons, iirc AES was designed for easy use in smartcards and such, not necessarilly to protect gigabytes of sensitive information. > I personally use Serpent with 256 bits keys for > the encrypted partitions on my PCs. It's of course probably too slow > for the Q60 though (128 bits keys seem more reasonable for a poor > 68060 @ 66MHz to deal with...). might not be so bad on the Q60, remember that bitshuffling is traditionally the strongest domain of 680x0 CPU's. > > appart of the extra demon this sound really very much like what autofs > > does for me. How does it work to release a medium, eg CD or floppy? With > > autofs I have to wait until it timeouts. > > No wait with SuperMount. It's just like if you were using the medium under > DOS/Windoze (Yuck !), or SMSQ/E... It's 100% kernel based and done at the > driver level... The problem is that its author doesn't maintain it anymore > and all the maintnance is now done by the Mandrake developers, and scattered > in numerous patches to each kernel... I know, the details were a bit too fishy last time I looked. > It's like a filesystem driver. You configure it in fstab, example: > > /mnt/dos/a /mnt/dos/a supermount fs=vfat,dev=/dev/fd0 0 0 > /mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom 0 0 so it becomes immediately unmounted as soon as you close last reference? Could do that with autofs as well but don't like it because it apparently looses cached buffers on CD roms. > > probably not, the problem is m68k specific afaics and Mandrake gets > > much less non-x86 testing than RedHat or Debian does. > > Mandrake doesn't develope at all for the m68k architecture, alas... certainly not, neither does RedHat. Otoh you will find patches for the stangest architectures in RH so there is apparently a lot of inofficial development or cross-distibution fertilisation going on. > Do you know if the same problem would arise with older gcc version > (I was thinking to compile it with gcc-2.95.3...) ? not this problem but more serious ones. gcc303 might work and is reasonably tested with 2.4 kernels. > > > If you got a file server (ftp, sftp, web) where to get them, I'd prefer > > > that way (faster now that I got an ADSL link ;-)... > > > > well I didn't get ADSL, the sourceforge site is still available of > > course. > > There are no SRPMS in it though... Or do I look in the wrong place ? they are still on my HD and quite uninteresting because I have newer ones that ought to be uploaded. I think I will try to rebuild glibc/binutils/rpm from RH 9 or rwhide with gcc-3.3.1 and see what happens, if that works I would try to base a new distribution on top of this. Richard
