[Tails-dev] Support EntropyKey?
Hi, we're asked to install ekeyd to support EntropyKey: https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ The total installed size of the needed packages is a few hundred kilobytes. I think it's worth adding to improve cryptography -related hardware support. What do you think? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Build systems and microcode weirdness
Hi, 0.14 and 0.15 I've built have amd64-microcode, intel-microcode and microcode.ctl installed at the P: Begin installing tasks... stage. 0.15~rc1 does not ship these packages. Perhaps there's something missing or different or older or whatever in the Vagrant build setup, compared to what I'm using? Can a Vagrant user please send me a build log so that I try to understand? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Promoting Persistence features
Hi, Marco Calamari wrote (26 Nov 2012 13:03:41 GMT) : I bother again this list after considering the value of such a post. Sorry if my evaluation was bad ... This is totally welcome. Looked to me that in 0.14 the persistence mode worth more advocacy, so I dug a little more the new version and wrote an article for non technical user, that can be summarized as persistece is good, try it If curious, you can find it here http://punto-informatico.it/3654699/PI/Commenti/cassandra-crossing-tails-tutti.aspx I don't read Italian, but I'm very happy to see such an initiative. Thank you! 2) adding a change persistence password in Utility menu would be a probably cheap but really useful feature. Doesn't the GNOME Disk Utility allow to change the LUKS volume passphrase already? Perhaps what's needed is some documentation only? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Promoting Persistence features
On Mon, 2012-11-26 at 15:20 +0200, Maxim Kammerer wrote: On Mon, Nov 26, 2012 at 3:03 PM, Marco Calamari mar...@marcoc.it wrote: 2) adding a change persistence password in Utility menu would be a probably cheap but really useful feature. It would be a misleading feature, since due to wear leveling on solid state media, parts of old LUKS header may be recoverable. On the other hand, it's always possible to add a warning. Agreed, but this is not the only situation adversely affected to solid-state memories. LUKS header fits in a cluster and is normaly unchanged, so his remapping due to the wearing-leveller actions seems at least rare, if ever. And Carol will need to password-crack against all free blocks ... looks really an unreasonable scenario. OTOH having an unchangeable password from a security perspective is IMO simply unacceptable. A lot of user scenarios make this needed, forbid this oblige the user to copy the user area, wipe the media, reformat, reinstall the whole stuff if password is to be changed, and this can be needed for a lot of well-known reasons. We know how to do this from command line, but mr. AverageTailsUser IMO will not ... JM2C. Marco signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Promoting Persistence features
On Mon, 2012-11-26 at 14:41 +0100, intrigeri wrote: 2) adding a change persistence password in Utility menu would be a probably cheap but really useful feature. Doesn't the GNOME Disk Utility allow to change the LUKS volume passphrase already? Perhaps what's needed is some documentation only? Err... the mandatory answer is yes but making this firsthands looks an useful interface characteristic, also to possibly give a warning about theoretical LUKS header persistence as Maxim pointed out in the previous message. A two liner script can do that OTOH this is the neverending issue about how much who write software need and want to protect the user form himself . Marco signature.asc Description: This is a digitally signed message part ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
intrigeri: Hi, we're asked to install ekeyd to support EntropyKey: https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ The total installed size of the needed packages is a few hundred kilobytes. I think it's worth adding to improve cryptography -related hardware support. What do you think? Cheers, I think it is a good idea. I regularly install it with Tails anyway. It might also make sense to include rng-tools, randomsound, and haveged for around of 1,098 kB on disk. Tails should really do everything possible to collect entropy as often as possible; if the rng runs dry, all the crypto fails badly... It might even be worth seeding the rng from an unlocked persistence partition - it should be possible to drain /dev/random of ~200 bits of entropy at any given point in time to ensure that the rng never goes unseeded... On a slightly related note... I've been thinking quite a lot lately about low entropy systems that create persistent encrypted storage. It seems like low entropy systems that fail horribly for asymmetric keys are also likely to fail horribly for symmetric keys. On a modern system install a user may set up an encrypted disk. On a recently installed laptop, I found that it had essentially zero sources of entropy beyond the keyboard, the clock and the hostname. Of the three, I think one could make an educated guess about the time the disk was formatted and the hostname. The network driver wasn't working, so I had no network traffic at all. I used the text installer, so until I arrived at the disk encryption, my keyboard entry was essentially setting the hostname and hitting return a half dozen times. Basically, I think the installer calls cryptsetup like this: cryptsetup --verbose --verify-passphrase luksFormat /dev/sda1 Internally, I think that cryptsetup calls _action_luksFormat_useMK() or _action_luksFormat_generateMK(), which in turn calls crypt_format() or crypt_luksFormat(). Eventually, LUKS_generate_masterkey() or LUKS_alloc_masterkey() will be called. Internally this just opens /dev/urandom. As we know from Nadia's latest work[0], disaster strikes often with /dev/urandom and especially with embedded systems or similarly entropy starved modern laptops with no moving parts... This may or may not be an actual bug. It seems like it is debatable if using /dev/urandom is a bug but using it with zero entropy is clearly a bad idea... Debian apparently considered it to be a no problem in 2010, so they use /dev/urandom (a change *from* /dev/random) according to the cryptsetup debian/changelog file: * change default for random key from /dev/random to /dev/urandom in README.Debian, extend explanation. (closes: #579932) ... o_0 ... I guess it would be interesting to collect actual LUKS masterkey disk keys and look at the distribution of bits. My guess is that if the LUKS password is collected *after* LUKS_generate_masterkey(), the entropy of the system is basically close to zero. I think this happens only when get_key() isn't called before crypt_format(). Though depending on how the entropy pool is seeded, I guess the entropy of the key may still be less than the actual bytes of the passphrase. It may be that cryptsetup is called with /dev/random as a key file, though I think that would mean that get_key() wouldn't be called. So it might have less entropy than expected as there simply isn't really anything that is actually well, entropic, for the attacker with the computer/disk in hand. The answer is probably in the partman-crypto package. It seems to create a key file by calling `cat $randfifo $keyfile` - strangely, create_random_keyfile() appears to call call_entropy_plugin only after it starts reading from the randfifo. Does anyone know offhand how cryptsetup is called from debian-installer? All the best, Jake [0] https://factorable.net/paper.html ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
On Mon, Nov 26, 2012 at 5:40 PM, Jacob Appelbaum ja...@appelbaum.net wrote: On a recently installed laptop, I found that it had essentially zero sources of entropy beyond the keyboard, the clock and the hostname. You forgot the CPU. Haveged makes all other approaches to gathering entropy pretty much irrelevant — for instance, try exhausting /proc/sys/kernel/random/entropy_avail on a system with running haveged. It is used in Tails since Apr 2010, and in Liberté since Apr 2011 (I think I added haveged after reading the PELD spec). HAVEGE is one of those really underappreciated academic projects. “HAVEGE can reach an unprecedented throughput for a software unpredictable random number generator: several hundreds of megabits per second on current workstations and PCs.” http://www.irisa.fr/caps/projects/hipsor/ http://www.irisa.fr/caps/projects/hipsor/misc.php http://www.irisa.fr/caps/projects/hipsor/publi.php -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
26/11/12 16:40, Jacob Appelbaum wrote: intrigeri: Hi, we're asked to install ekeyd to support EntropyKey: https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ The total installed size of the needed packages is a few hundred kilobytes. I think it's worth adding to improve cryptography -related hardware support. What do you think? Given what I've read about HAVEGE (or rather, mostly the lack of good criticism) it seems like we already have solved the problem of generating good random numbers at will in Tails by installing haveged. I'm not against the inclusion of ekeyd, however. Cheers, I think it is a good idea. I regularly install it with Tails anyway. It might also make sense to include rng-tools, randomsound, and haveged for around of 1,098 kB on disk. Tails do install haveged by default. Tails should really do everything possible to collect entropy as often as possible; if the rng runs dry, all the crypto fails badly... It might even be worth seeding the rng from an unlocked persistence partition - it should be possible to drain /dev/random of ~200 bits of entropy at any given point in time to ensure that the rng never goes unseeded... Running (in Tails): cat /dev/random | pv /dev/null reports a pretty stable rate of 2MB/s on my system, which should be sufficient for all *realistic* use cases. Given that the rate is good I don't see any reason for mixing in additional entropy sources, like you propose, except if haveged doesn't have good enough entropy quality on its own. Here's two pretty interesting blog posts about haveged and its entropy quality: http://jakob.engbloms.se/archives/1370 http://jakob.engbloms.se/archives/1374 Most points raised in them seem highly academic, though, so my conclusion is that haveged is good enough on its own. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support EntropyKey?
anonym: 26/11/12 16:40, Jacob Appelbaum wrote: intrigeri: Hi, we're asked to install ekeyd to support EntropyKey: https://tails.boum.org/todo/Install_ekeyd_for___40__potentially__41___better_entropy/ The total installed size of the needed packages is a few hundred kilobytes. I think it's worth adding to improve cryptography -related hardware support. What do you think? Given what I've read about HAVEGE (or rather, mostly the lack of good criticism) it seems like we already have solved the problem of generating good random numbers at will in Tails by installing haveged. I'm not against the inclusion of ekeyd, however. Seems reasonable. I don't know that I'd call it solved because it is extremely hard to know if the random numbers are, well, actually entropic. :-/ Cheers, I think it is a good idea. I regularly install it with Tails anyway. It might also make sense to include rng-tools, randomsound, and haveged for around of 1,098 kB on disk. Tails do install haveged by default. I missed that haveged is installed. Glad to hear it. Tails should really do everything possible to collect entropy as often as possible; if the rng runs dry, all the crypto fails badly... It might even be worth seeding the rng from an unlocked persistence partition - it should be possible to drain /dev/random of ~200 bits of entropy at any given point in time to ensure that the rng never goes unseeded... Running (in Tails): cat /dev/random | pv /dev/null reports a pretty stable rate of 2MB/s on my system, which should be sufficient for all *realistic* use cases. Given that the rate is good I don't see any reason for mixing in additional entropy sources, like you propose, except if haveged doesn't have good enough entropy quality on its own. I admit, I find a high performance RNG to be... less than compelling. Here's two pretty interesting blog posts about haveged and its entropy quality: http://jakob.engbloms.se/archives/1370 http://jakob.engbloms.se/archives/1374 I generally agree with the author - our tests about the entropic nature of a bitstream are pretty weak. It seems to me that (at debian-install time) the system will likely have very little variation. At boottime on a given piece of hardware, I imagine this is also true for repeated runs if one could reset the hardware to the original state. The goal for me isn't perfect predictability but rather, predictability within a certain set of bounds. I think that is related to the point of the Proartis[0] project. Most points raised in them seem highly academic, though, so my conclusion is that haveged is good enough on its own. I think that almost no single entropy source is good alone. The kernel should take a few and mix them together, hopefully the kernel's mixing works well enough. I remember hearing that the entropy pooling system was going to get an overhaul after Nadia's paper, I wonder if that happened? I think it would be interesting to know how the rdrand CPU flag is utilized in Tails? If a machine has it, will the kernel automatically use this entropy source? It would also be interesting to see if randomsound would at least make the attack surface of the microphone worthwhile... All the best, Jake [0] http://www.proartis-project.eu/ ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] bridge mode vs. clock way off
22/11/12 14:11, intrigeri wrote: Hi, anonym wrote (21 Nov 2012 14:21:43 GMT) : Log severity info is really verbose. I ran a test for 20 minutes with some rather heavy Tor usage, and the log grew something like 100KB/minute. That's too much, IMHO. Agreed. However, we can save this approach like this: 1. We patch torrc at build time to have Log info ..., as proposed. 2. But once tordate finishes we edit torrc and downgrade to notice level debugging, and send a SIGHUP to Tor. Ugly, ugly, ugly workarounds, all the time! :) What do you think? Wow... I could live with that, but if there's a trivial bugfix in Tor itself that can allow us to avoid yet another ugly kludge, then I'd rather use the possibility thereof. I tried implementing this in a branch yesterday, hoping to get it in 0.15. I encountered some issues, and then I saw that you had already pushed the 0.15 tag etc. so I didn't look on it again until today. It turns step 2 isn't as easy as I initially thought: Since we're in bridge mode, Vidalia will start before tordate so bridges can be added. When Vidalia connects to Tor, it unsets the (hidden) Tor option __ReloadTorrcOnSIGHUP, so we either have to: a. restart Tor (and Vidalia) yet again to have Tor re-read the new torrc (now without info level logging), or b. manually re-set __ReloadTorrcOnSIGHUP, send a HUP so Tor re-reads torrc and then possibly unset __ReloadTorrcOnSIGHUP again (or restart Vidalia) I don't like either, mostly because this was meant to be a simple, unobtrusive fix. I guess option a is best so Vidalia doesn't get out-of-sync with Tor's state, if that's possible. But it's yet another Tor restart... Note: You can't change anything about Log lines in torrc via the control port. Otherwise that'd be the easy way out. I updated the ticket. I'm not 3. What about patching Tor to eliminate the log severity inconsistency? But perhaps they have good reasons for this being the way it is so it wouldn't get upstreamed? I think it's worth asking them if there's a good reason for the apparent inconsistency. On second thought, if we're gonna look towards upstream, I'd rather we spend our energy on a proper fix, not a fix that make our current workaround work... urgh. I don't see these two approaches as incompatible. I wasn't talking about that. I was talking about saving time and energy. If there are no good reasons for the log severity inconsistency, then that's a (minor) bug you have discovered in Tor, and I think we should report it as such, regardless of the solution we choose for the problem at hand, and regardless of whether we implement a nice new feature in Tor 0.2.4.x or later. I'll take care of reporting the bug if needed, just tell me: it'll take me less time to actually do it, than to argue any longer about whether we should report it or not ;) If you feel like it shoot. If that works, and Tor 0.2.3.x has this bug fixed $soon, then problem solved, no kludge to add to our pile and maintain. Would $soon = end of the year seem reasonable to you? Yes. Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] bridge mode vs. clock way off
On 11/26/12, anonym ano...@lavabit.com wrote: Note: You can't change anything about Log lines in torrc via the control port. Otherwise that'd be the easy way out. SETCONF Log=info file /var/log/tor/info Log=notice file /var/log/tor/log Robert Ransom ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
