On Fri, 22 Aug 2003 13:50:48 +0200, Richard Zidlicky wrote:

> On Fri, Aug 22, 2003 at 02:14:54AM +0200, Thierry Godefroy wrote:
>
> > 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

No, I didn't see it... Interesting... But you didn't quote the conclusion:

<<So, here's the current scorecard. Courtois and Pieprzyk claim a 2^100-ish
attack against AES. They claim a 2^200-ish attack against Serpent. This
is an enormously big deal. Assuming that it's real.>>

Well, Serpent is still safer than AES... Plus, all these attacks are based
on known clear text attack, which leads to this comment in the article:

<<In any case, there's no cause for alarm yet. These attacks can be no more
implemented in the field than they can be tested in a lab. No AES (or
Serpent) traffic can be decrypted using these techniques. No communications
are at risk. No products need to be recalled. There's so much security
margin in these ciphers that the attacks are irrelevant.>>

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).

> > 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.

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...

> > > 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? 

No, the device is permanently mounted and the driver reports an absent
medium when accessed without a proper medium in the drive...

> Could do that with autofs as well but don't like it because
> it apparently looses cached buffers on CD roms.

Never experimented such problems with SuperMount.

> > 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

???  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...

> gcc303 might work and is reasonably tested with 2.4 kernels.

Thanks to your indications, I managed to patch the v2.4 kernel sources
so to work around the gcc bug... I'll release the kernel packages as
soon as possible. ;-)

Note that the bug is trigered by all four ide-cd.c, ide-floppy.c,
ide-tape.c and ide-scsi.c...

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...

> > 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. 

That would be cool :-)  Also, try to think "Manndrake": they got really
cool packages and good patches to fix various problems encountered in
many pieces of software.

Thierry ([EMAIL PROTECTED]).

Reply via email to