Re: Debian encouraging use of 4096 bit RSA keys
On Tue, 14 Sep 2010, Perry E. Metzger wrote: The decision that 1024 bit keys are inadequate for code signing is likely reasonable. The idea that 2048 bits and not something between 1024 bits and 2048 bits is a reasonable minimum is perhaps arguable. One wonders what security model indicated 4096 bits is the ideal length Key lifetime in Debian can be very long, 10 to 15 years. I'd appreciate some input from this list about the Debian bias towards 4096 RSA main keys, instead of DSA2 (3072-bit) keys. Is it justified? These keys are used as KSK, as gpg will happily attach subkeys to them for the grunt work... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: /dev/random and virtual systems
On Mon, 02 Aug 2010, Yaron Sheffer wrote: the interesting thread on seeding and reseeding /dev/random did not mention that many of the most problematic systems in this respect are virtual machines. Such machines (when used for cloud Any decent hypervisor can supply entropy to the VMs. For about US$100/hypervisor you add a slow speed (less than 1Mbit/s) TRNG, or you can get a high-speed one for around US$ 1000/hypervisor, and distribute the entropy for all VMs. It is very cost-effective. Datacenters are easy, you can just buy a few low power VIA PadLock boxes and have them distribute several Mbit/s of entropy over the network. You can have at least 2 of them per 1U, or a lot more for custom designs or piled up in 2U using a shelf. You don't need entropy to use assymetric crypto to authenticate, receive an encripted session key, and proceed to receive an encripted stream, so the network and a cluster of entropy boxes is usable for initial seeding as well. Desktops with live-CDs and half-assed embedded boxes that lack a TRNG are the real problem. In addition to the mitigations that were discussed on the list, such machines could benefit from seeding /dev/random (or periodically reseeding it) from the *host machine's* RNG. This is one thing that's guaranteed to be different between VM instances. So my question to the list: is this useful? Is this doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is this actually being done? It is done, yes. I am not sure how out-of-the-box that is, but there are Linux kernel drivers to get entropy from the hypervisor. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: /dev/random and virtual systems
On Mon, 02 Aug 2010, Paul Wouters wrote: On Mon, 2 Aug 2010, Yaron Sheffer wrote: In addition to the mitigations that were discussed on the list, such machines could benefit from seeding /dev/random (or periodically reseeding it) from the *host machine's* RNG. This is one thing that's guaranteed to be different between VM instances. So my question to the list: is this useful? Is this doable with popular systems (e.g. Linux running on VMWare or VirtualBox)? Is this actually being done? Both xen and kvm do not do this currently. It is problematic for servers. The virtio-rng driver does it almost out-of-the-box, but it is sort of new. Both Xen and KVM let you create communication channels between the Hypervisor and a specific VM, which you can use to distribute entropy from the hypervisor to rng-tools inside the VM. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [Pkg-sysvinit-devel] init.d/urandom : saving random-seed
On Mon, 02 Aug 2010, Christoph Anton Mitterer wrote: On Sat, 2010-07-31 at 13:36 -0700, John Denker wrote: And we should move the seed file to somewhere inside /etc or /lib. It is as simple as that. /var cannot be used for any data you need at early userspace. There are strong arguments for _not_ putting the random-seed in /etc or /lib. There are lots of systems out there which for security reasons and/or performance reasons have /etc and /lib on permanently readonly partitions. In this case, the requirement is that the seed MUST be available to early userspace. There are *absolute* requirements for early userspace, which trump anything else, including the FHS. When you cannot meet those requirements, you have to abandon the idea of doing it in early userspace. It is THAT simple. Early userspace means you have a read-only / and some virtual filesystems mounted, a partial /dev (probably on tmpfs), and that's about it. So anything used by early userspace *must* go in /. The only hierarchies that are always in / (for *Debian*) are: /etc /bin /sbin /lib* (/lib32, /lib64...) We can certainly create some other toplevel hierarchy which is required to be in /. But that is genearally considered an worse option than adding the hierarchy inside /lib or /etc. Also, if you want read-only /lib or /etc, you want read-only /. This is completely incompatible with file-based random seed persistence done right. You will have to do away with the file-based approach, and use a hardware TRNG that can work in early boot, just like a Live-DVD/Live-CD would. Or you can edit the scripts to have / remounted read-write for the window required to refresh the seed files at late boot and shutdown. read-only / is also not a supported configuration, so it is your problem to make sure your system behaves sanely with read-only /. We *do* support Live-CD-style schemes, though (where writes are lost upon reboot), so we can certainly get rng-tools migrated to / to help those. I'm not sure whether it's really strictly the case that /var is completely local. It might be in Debian, but AFAIU the FHS That doesn't matter. It is not in /, so it is not available for early userspace. Therefore, it doesn't meet the requirements. /lib/ doesn't fit either IMO,... /boot sounds perhaps ok?! No. /boot can (and often is) a separate partition. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
