Re: mlock(1)

[Pavel Machek]

Hi!

> > > > There must be some way of being able to check the password is correct
> > > > without compromising security by encrypting static text and storing it
> > > > at a known location! Darned if I know what it is though.
> > > 
> > > good point! Maybe we can pick random signed chars in a 4k block and
> > > guarantee their sum is always -123456. Would that be secure against
> > > plaintext attack right? It's more like a checksum than a magic number,
> > > but it should be a lot more secure than the "double" typo probability
> > > (and this way the password will be asked only once during resume).
> > > Generating those random numbers will not be the easiest thing though.
> > 
> > Actually, better solution probably is to encrypt 32-bit zero.
> > 
> > Then, you have 1:2^32 probability of accepting wrong password, still
> > if you try to brute-force it, you'll find many possible passwords.
> 
> this is just the first step an attacker needs to rule out all the
> impossible passwords and extend the crack to the other known bits. I
> don't think it's secure. My suggestion OTOH sounds completely secure
> (though much harder to implement).

Actually if your cipher is not resistant to known plaintext attack,
you have other problems anyway. There's a lot of nearly-lnown data 
(like name of process with pid 1) that single 32bit zero is no problem.

So I'm not compromising anything...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/