[dm-crypt] LUKS and backdoors

Zaolin zaolin at das-labor.org
Mon Oct 21 22:16:24 CEST 2013


A nice paper: https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

> On Mon, Oct 21, 2013 at 03:12:25PM +0200, Christoph Anton Mitterer wrote:
> > On Mon, 2013-10-21 at 13:10 +0200, octane indice wrote:
> > > But at this point, what is the quality of the random[1]?
> > Well /dev/random (in Linux) should have either high quality entropy,...
> > or block... at least that was my understanding (there's currently a
> > discussion going on about /dev/[u]random at the well known cryptography
> > mailing list)...
> 
> That understanding is unfortunately incorrect. True, /dev/random
> will block if it thinks it is low on entropy, but it cannot 
> reliably know. The problem is that it needs to estimate entropy 
> for each event it adds, and that can go horribly wrong. In
> particular virtualized anvironments can have that effect.
>  
> > BUT,... cryptsetup uses by default unfortunately urandom to generate the
> > master key.
> > I never really understood why since all arguments pro it seem weak or
> > nonsense to me... anyway that's how things are.
> > But you can use --use-random to change that.
> 
> Look at the mailing-list archives. It boild down to the simple
> fact that if you do crypto in a low-entropy environment, you
> better know what you are doing and that the splution to dealing
> with such an environment is _not_ obvious and not as simple
> as selecting /dev/random.
> 
> > So in principle you should be on the safe side then.
> > 
> > 
> > Of course you can improve entropy by using stuff like haveged, or a
> > TRNG[0],... but I do not really know wheter these also have a positive
> > effect on the _quality_ of the entropy or just on the _quantity_.
> 
> There is no difference between quality and quantity when entropy
> is concerned.
> 
> Arno
> 
> > 
> > Cheers,
> > Chris.
> > 
> > 
> > [0] According to Ted Ts'o and others it's not possible to
> > spoil /dev/random by seeding it with malicious entropy sources (it just
> > wouldn't get better as it was already)... though I must admit that I've
> > never understood why this could be like that.
> 
> 
> 
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
> ----
> There are two ways of constructing a software design: One way is to make it
> so simple that there are obviously no deficiencies, and the other way is to
> make it so complicated that there are no obvious deficiencies. The first
> method is far more difficult.  --Tony Hoare
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20131021/a08af5b6/attachment.asc>


More information about the dm-crypt mailing list