8 ms·

Generating a private key I can trust

38 points by tcoppi 13y ago

gioele 13y ago
Beware of the key size limitations of OpenPGP smartcards: most of them can only handle 2048-bit RSA keys, a size that is now considered not safe for new RSA keys.
- mpyne 13y ago
  Well, 2048 is certainly safe unless your includes direct attention from the NSA itself, where I'd ordinarily tell you that you've already lost. However it looks like Martin is trying to be successful in exactly that scenario so I suppose that's a good tip indeed for this case.
- deleted 13y ago
  [deleted]
- taway2012 13y ago
  They handle 3072-bit keys now. http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42 http://shop.kernelconcepts.de/product_info.php?cPath=1_26&pr...
  - agwa 13y ago
    This is correct. I have a 1.5-year-old OpenPGP card and can attest that all 3 of my keys are 3072-bit.
- fhoxh 13y ago
  With version 2.0 of the card and GnuPG 2.0.18, 4096-bit RSA keys are supported: https://wiki.debian.org/Smartcards/OpenPGP#Features https://wiki.debian.org/Smartcards/OpenPGP#Features
JonFish85 13y ago
So really, what you want, is a convenient & easy but totally secure method. Because if you want security, a one-time pad is pretty much your best option. But at the same time, since you pretty obviously are willing to go great lengths for security, let's not beat around the bush. Granted this has some of the same problems (need randomness), and can probably be more work than it's worth...
deweerdt 13y ago
> So whom do I actually trust? This list is short: the Linux kernel (Linus tree) and FSF/GNU. Why would you leave out the BSDs?
- DanBC 13y ago
  I'd love to see a version of this post or the "Securing a Linux server" (https://news.ycombinator.com/item?id=6384603 https://news.ycombinator.com/item?id=6384603) post but for OpenBSD or FreeBSD. I'm surprised more people haven't been mentioning the BSDs after the NSA / GCHQ revelations and in the drive for more security.
  - tls 13y ago
    block in all pass out all last rule wins, and obviously if it is remote allow ssh port etc. You can read more here: http://home.nuug.no/~peter/pf/en/long-firewall.html http://home.nuug.no/~peter/pf/en/long-firewall.html
  - txutxu 13y ago
    man afterboot: http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot&sektion=8 http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot&sekti...
- mpyne 13y ago
  Good question, but I believe the answer is part of the increasingly powerful movement afoot in OSS to focus attention on Linux exclusively, even down to the level of merging onto single implementations of many libraries and reduce fragmentation within the space. AFAIK Martin is supportive of that concept in general, although perhaps he'd re-think that to consider e.g. OpenBSD in light of his recent refocusing of effort.
- oscargrouch 13y ago
  FreeBSD 10 is sweet as it can be.. also not only focusing on security, but linux is all well now.. and are widelly adopted by the big players.. i think its time for us techies to focus our energies in this great OS that needs our help, code, support, whatever..
mileswu 13y ago
> First of all I do not trust any hardware. It’s impossible to verify that the hardware doesn’t have a backdoor and randomness looks random even if tampered with. Well if you can't trust any hardware, how can the author trust any off-the-shelf computer and CPU to generate the private key even if he is using Linux+GPG? For all he could know the CPU could contain a backdoor that performs the necessary arithmetic and operations incorrectly (in the process making the key weaker). He is also trusting his CPU to do the session encryption correctly (even with his external smartcard). Perhaps the CPU could leak information about the session key to another processes, allowing people to decrypt your communications? Now I trust my CPU and hardware, especially because we have little alternatives. Perhaps it would be better to use an external smartcard to generate the private key too, because the physical hardware is orders of magnitude less complicated than a CPU/computer, so you could verify the hardware contains no backdoors by examining the physical circuits using a microscope (I presume this would still be very hard to do but millions of times simpler than that for a modern CPU).
- acqq 13y ago
  Smartcard is the whole computer, minus power supply and the clock. You are right that it's smaller than one x86 and the rest of your notebook or desktop though. Still you'd have to investigate all the hardware and software on your desktop that you use with the smartcard too -- how would you know that the desktop isn't just pretending to use your smartcard? And if you trust the desktop, why do you waste the time with the smartcard, as long as you make the whole setup only for you?
res0nat0r 13y ago
I think most of these types of posts are not seeing the forest for the trees. If you for some reason have become a direct target the NSA has been tasked to investigate then you've already lost. They have much more manpower, money, and clever ways to get their hands on your data than you have to keep it from them. Most probably don't even involve some techno conspiracy supercomputer type RSA cracking fantasy, but simple social engineering. Keep using what you are using and it will protect you from the 99.999999% of the world who has no idea who you are, doesn't care, and can't be bothered to spend any amount of time backdooring your system because you aren't interesting enough.
zokier 13y ago
Any recommendations for USB HSM/token? Trustable, foss-friendly, good software/standards support, buyable in singles? Smartcards are kinda nice, but the lack of integrated reader HW makes them mostly just bulky USB tokens (card+reader).
- anologwintermut 13y ago
  If you are practicing NSA is out to get me security: USB tokens are probably the worst idea possible. They are practically unauditable (sure, maybe the design is open source, but is that actually what got put on the chip?) and specifically intended for cryptographic function by paranoid people who think they have something to hide. I.e. they are likely one of the first thing the NSA would target. And they are easy to target since everyone knows exactly how they will be used and what code will execute on them. You'd be better off going with an x86 chip and avoiding the obvious hardware backdoor channel of a bad RNG(though for key generation it's unlikely NSA would ever see enough bits from the RNG to crack it). Because it's a generic computer, you can't just break the chip by backdooring everything(e.g. make xor a nop). You'd need to screw with instruction only if it is part of a cryptographic operations and that would be very very tricky and use up a hell of a lot of the transistor budget.
  - zokier 13y ago
    But what are the potential threats a backdoor in a USB token could have? Assuming it's used with (audited) open source drivers and keys are generated externally (ie by the host computer and not by the token) I don't really see a possibility for NSA to weaken the crypto. Of course there might be backdoors for physical attacks (or malicious driver attacks), but I'm willing to accept that.
- csears 13y ago
  Yubico makes a couple products that might fit your requirements. The YubiHSM [1] ($500) is a USB HSM designed to be connected to server. Yubikey Neo [2] ($50) is does end-user authentication (OTP, CCID, SE, JavaCard) over NFC or USB. They can both be ordered in quantities of one and have open source SDKs [3]. [1]: http://www.yubico.com/products/yubihsm/ http://www.yubico.com/products/yubihsm/ [2]: http://www.yubico.com/products/yubikey-hardware/yubikey-neo/ http://www.yubico.com/products/yubikey-hardware/yubikey-neo/ [3]: http://www.yubico.com/develop/open-source-software/ http://www.yubico.com/develop/open-source-software/
tptacek 13y ago
This is extremely silly. Construct a scenario in which a compromised hardware random number generator enables NSA to somehow recover the bits from a GPG key you generate at some unknown point in the past. Try to be as specific as possible. I think the concerns about backdoored hardware RNGs are really overblown, but if we're going to stipulate they're to be taken seriously, they relevant on online attacks against systems that make repeated requests for entropy. Along a similar vein, every attack you've heard of on AES or even RC4 requires many repeated calls to the cipher, often with other parameters fixed. Just generate the damn GPG key and be done with it.
- jacquesm 13y ago
  It's hard to be a tinfoil hatter when everybody else is now just as paranoid as you were 6 months ago. So tinfoil hatters have to up the ante or go mainstream :)
  - ppierald 13y ago
    I nominate you for HN Comment of the Year!
  - einhverfr 13y ago
    Given that I keep hearing security professionals say they weren't paranoid enough, I suspect the truth is everyone else now is more paranoid than you were six months ago, which must be really disconcerting.
- einhverfr 13y ago
  I could imagine hardware built to grab public keys, and I could imagine such in a general purpose computer. However in the end there are a large number of problems so this is not a scenario to worry about. Yea, just generate the key and be done with it. But the problems include: 1. So suppose you build into a computer an effort to recognize some public key generation routines and intercept the key from memory. This could be done, but updating the firmware code (since it is hidden from the user of the computer) is pretty hard so it only works on versions current at the time of manufacture. If you have had the computer for a few years, such recognition would seem iffy. Additionally this gets more complex when supporting more implementations.... 2. Ok, so the computer malhardware has got the key, so what can it do with it? If you send the key over the internet, someone at some point may detect it. Likely the best scenario would be to store it and wait for some attempted handshake on, say, a firewire port, and then send it out then. Or one could wait for an SSH connection to an NSA-used cert for something like Google, but certs expire so that attack won't be worth it. Tinfoil mode is interesting but part of the benefits are thinking through the possible exposure of something like a compromised piece of hardware. Again, suppose the RNG is compromised. usually this means one can guess future values based on past values. An attack without past values is worthless, so it is unlikely to be helpful with regard to public key encryption as you point out.
wtn 13y ago
Most S/MIME certificate authorities require the generation of private keys using the "keygen" tag. Most browsers that support this tag require the generated key length to be 1024 or 2048 bits, whereas forcing either 2048 or 4096 bit keys would be more sensible. https://bugzilla.mozilla.org/show_bug.cgi?id=495836 https://bugzilla.mozilla.org/show_bug.cgi?id=495836
enupten 13y ago
I guess this is why RMS dislikes binary blobs. Something like the Lisp machine, where you can access/modify OS source while it's running, would be dream come true in today's world.
- oscargrouch 13y ago
  your post give me one idea: what about using am Rodeh Btree[1], to create concurrent snapshots of the running kernel, in this btree, so we could switch them in runtime.. you compile a new version (CRC does not match) them it will create a new branch/snapshot on memory and will start from there.. kernels of course should be designed in a transactional way manage states, etc.. rsrs.. anyway just a wild idea, dont know if its even useful doe.. [1] - B-trees, Shadowing, and Clones -http://www.usenix.org/event/lsf07/tech/rodeh.pdf http://www.usenix.org/event/lsf07/tech/rodeh.pdf
  - oscargrouch 13y ago
    other design note to make this feasible, its to design it in a way, where each cpu core, could have its own kernel copy.. so you can try to boot up, the other version in another core, while you are using the old version in an active/context core?
Sanddancer 13y ago
I was hoping that this would have been something interesting, like a discussion on using avalanche noise ( http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ ) in a portable way, or other bits of proper hardware hacking. Not trusting any hardware RNG is silly, especially if you can learn from first principles how they work, and build one yourself.
privasectech 13y ago
I'm curious why there was no consideration for OpenBSD?
privasectech 13y ago
Interesting that you can only buy an OpenPGP smart card from a supplier with a broken SSL implementation. https://shop.kernelconcepts.de/login.php https://shop.kernelconcepts.de/login.php
- agwa 13y ago
  They're not broken; they're simply using cacert.org instead of a mainstream CA. From a business standpoint, that's a terrible idea for selling to the general public, but from a security perspective it's fine. Incidentally, they sign their order confirmation emails with PGP. :-)
olympus 13y ago
I applaud the author's idea, but let me share some of my experiences (both good and bad) since the DoD uses smart cards every day for a myriad of things including: document signing, document encryption, computer logins, website logins, biometric information storage, medical information storage, and probably a few more that I am forgetting. 1. You should choose a long PIN. In the DoD there is a feature on the smartcard that locks the card after three consecutive incorrect PIN entries (no time limit). Obviously this is a good security measure. When DoD personnel have locked out their smartcard they go to the computer help desk where there is a trusted agent like a (properly trained) young enlisted troop who has a high privilege key that can unlock your smartcard. You do not have a worldwide network of locations where you can get your card unlocked, so you cannot implement the "three tries and you're dead" feature. Therefore, make your PIN as long as practically possible to prevent someone who stole your card from being able to brute-force the PIN and get your keys. 2. You might want to make a duplicate card and store it in a safe location. You WILL eventually lose the card you are carrying around with you, and when you do, it essentially means the loss of all your encrypted data. While the second set of keys lying around is a vulnerability, it might be an acceptable one to hedge against the loss of your data. Having a duplicate card might also allow you to implement the feature where the smartcard locks after a number of unsuccessful PIN entries. 3. Do NOT use USB drives as an alternative token because you don't want to shell out for a smartcard. USB drives introduce known vulnerabilities and they are prohibited DoD-wide on ALL of their networks (including all our classified nets). If the lowly USB drive has the power to make the DoD shake in its boots, you shouldn't be using one when you need security. 4. Smartcards are cool in an enterprise setup for signing documents and stuff, but make sure you aren't triple locking your door and then leaving your window open. If you decrypt an email and view the cleartext with a text editor, make sure you are not beaming that back to your attacker because they compromised your machine in another way. 5. Related to #4 above, the most secure systems are standalone systems that NEVER connect to a network. Instead of shelling out for some smartcards and readers, buy a Raspberry Pi, and generate your keys on it- and your private key will never leave this machine. Use write-once media to get your public key on a networked computer (this should be the ONLY time you transfer data off of your standalone system). Whenever you need to decrypt something, use more write-once media to get the encrypted data onto your standalone RasPi, and decrypt it and view it. If you want to be super paranoid, maintain an 18" air gap between your standalone RasPi and any networked computer. This is the proper way to wear your tinfoil hat. Plus, the RasPi is cheaper than a smartcard setup, and invulnerable to keyloggers and pretty much any other attack because data exfiltration is impossible when you never connect it to the network and you never send data off of it.
aidenn0 13y ago
How about rolling an octahedron? You can generate 3 bits per roll, it takes about 3 seconds to roll and record the result, for a total of 1 bit per second. How much entropy is needed to generate a 4096 bit key? Of course this is likely less secure than using /dev/random, as you will be typing in the bits, someone could log the bits you type in, someone could have a telephoto lens and take pictures of your dice rolls. It's always possible to be paranoid to the point that whatever you do isn't secure.
- olympus 13y ago
  >someone could have a telephoto lens and take pictures of your dice rolls< Roll a braille octahedron in your bathroom with the door locked and the lights out. Type the bits on an offline computer so the keylogger can't report back to its owner.
  - derefr 13y ago
    They can use an infrared lens to look at indentations created on your fingertips as you read the braille. ;)
- zokier 13y ago
  > How much entropy is needed to generate a 4096 bit key? 4096 bits?
  - aidenn0 13y ago
    I doubt it is 4096 exactly, since a RSA key involves generating random large primes, right?
derefr 13y ago
> Obviously there is still the risk of a tampered compiler but I consider this risk as rather academic. Some part of me wants news to come out that there has for years been an NSA code-injection backdoor in, say, Debian's binary "lineage" of GCC. Imagine the reaction.
- lifeisstillgood 13y ago
  to be honest not that much. most people have never heard of Linux let alone Debian compiler toolchains. and almost everyone who has heard of it, already is reacting about as hard as they can.
derefr 13y ago
How hard would it be to print a smart card with currently-shipping consumer 3D printers? If not-that-hard, then would collaborating to create a verifiable Open Smartcard Board + Firmware be a useful idea? It'd neatly short-circuit having to trust the entire consumer hardware+software stack.
- InTheSwiss 13y ago
  The card itself is just a piece of plastic, it is the microchip that is the important part and I am not aware of any 3D printing system that could print something that complex just yet.
  - derefr 13y ago
    How many gates does a chip need if it's basically a single-purpose crypto ASIC? Presuming you can expand the traces out to cover the entire back of the card (no die, just raw PCB), what process size would you need? I guess, if that doesn't work, we could always just work on an Open Smartcard Microcontroller For FPGA-based Cards. Then the one thing you need to trust is that FPGAs don't have a special backdoor mode for when they somehow detect that the chip they're running is doing crypto ;)
bdamm 13y ago
I thought this was a great idea, a GnuPGP ready card! This means there's firmware on the card that is known to be compatible with GnuPGP protocols, and pscsd as well. Very nice. So I went to buy, and the seller has a market place with a self-signed certificate. They won't get my dime.

38 points by tcoppi 13y ago

Beware of the key size limitations of OpenPGP smartcards: most of them can only handle 2048-bit RSA keys, a size that is now considered not safe for new RSA keys.

mpyne 13y ago
Well, 2048 is certainly safe unless your includes direct attention from the NSA itself, where I'd ordinarily tell you that you've already lost. However it looks like Martin is trying to be successful in exactly that scenario so I suppose that's a good tip indeed for this case.
deleted 13y ago
[deleted]
taway2012 13y ago
They handle 3072-bit keys now. http://shop.kernelconcepts.de/product_info.php?cPath=1_26&products_id=42 http://shop.kernelconcepts.de/product_info.php?cPath=1_26&pr...
- agwa 13y ago
  This is correct. I have a 1.5-year-old OpenPGP card and can attest that all 3 of my keys are 3072-bit.
fhoxh 13y ago
With version 2.0 of the card and GnuPG 2.0.18, 4096-bit RSA keys are supported: https://wiki.debian.org/Smartcards/OpenPGP#Features https://wiki.debian.org/Smartcards/OpenPGP#Features

JonFish85 13y ago

So really, what you want, is a convenient & easy but totally secure method. Because if you want security, a one-time pad is pretty much your best option. But at the same time, since you pretty obviously are willing to go great lengths for security, let's not beat around the bush. Granted this has some of the same problems (need randomness), and can probably be more work than it's worth...

deweerdt 13y ago

> So whom do I actually trust? This list is short: the Linux kernel (Linus tree) and FSF/GNU. Why would you leave out the BSDs?

DanBC 13y ago
I'd love to see a version of this post or the "Securing a Linux server" (https://news.ycombinator.com/item?id=6384603 https://news.ycombinator.com/item?id=6384603) post but for OpenBSD or FreeBSD. I'm surprised more people haven't been mentioning the BSDs after the NSA / GCHQ revelations and in the drive for more security.
- tls 13y ago
  block in all pass out all last rule wins, and obviously if it is remote allow ssh port etc. You can read more here: http://home.nuug.no/~peter/pf/en/long-firewall.html http://home.nuug.no/~peter/pf/en/long-firewall.html
- txutxu 13y ago
  man afterboot: http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot&sektion=8 http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot&sekti...
mpyne 13y ago
Good question, but I believe the answer is part of the increasingly powerful movement afoot in OSS to focus attention on Linux exclusively, even down to the level of merging onto single implementations of many libraries and reduce fragmentation within the space. AFAIK Martin is supportive of that concept in general, although perhaps he'd re-think that to consider e.g. OpenBSD in light of his recent refocusing of effort.
oscargrouch 13y ago
FreeBSD 10 is sweet as it can be.. also not only focusing on security, but linux is all well now.. and are widelly adopted by the big players.. i think its time for us techies to focus our energies in this great OS that needs our help, code, support, whatever..

mileswu 13y ago

> First of all I do not trust any hardware. It’s impossible to verify that the hardware doesn’t have a backdoor and randomness looks random even if tampered with. Well if you can't trust any hardware, how can the author trust any off-the-shelf computer and CPU to generate the private key even if he is using Linux+GPG? For all he could know the CPU could contain a backdoor that performs the necessary arithmetic and operations incorrectly (in the process making the key weaker). He is also trusting his CPU to do the session encryption correctly (even with his external smartcard). Perhaps the CPU could leak information about the session key to another processes, allowing people to decrypt your communications? Now I trust my CPU and hardware, especially because we have little alternatives. Perhaps it would be better to use an external smartcard to generate the private key too, because the physical hardware is orders of magnitude less complicated than a CPU/computer, so you could verify the hardware contains no backdoors by examining the physical circuits using a microscope (I presume this would still be very hard to do but millions of times simpler than that for a modern CPU).

acqq 13y ago
Smartcard is the whole computer, minus power supply and the clock. You are right that it's smaller than one x86 and the rest of your notebook or desktop though. Still you'd have to investigate all the hardware and software on your desktop that you use with the smartcard too -- how would you know that the desktop isn't just pretending to use your smartcard? And if you trust the desktop, why do you waste the time with the smartcard, as long as you make the whole setup only for you?

res0nat0r 13y ago

I think most of these types of posts are not seeing the forest for the trees. If you for some reason have become a direct target the NSA has been tasked to investigate then you've already lost. They have much more manpower, money, and clever ways to get their hands on your data than you have to keep it from them. Most probably don't even involve some techno conspiracy supercomputer type RSA cracking fantasy, but simple social engineering. Keep using what you are using and it will protect you from the 99.999999% of the world who has no idea who you are, doesn't care, and can't be bothered to spend any amount of time backdooring your system because you aren't interesting enough.

zokier 13y ago

Any recommendations for USB HSM/token? Trustable, foss-friendly, good software/standards support, buyable in singles? Smartcards are kinda nice, but the lack of integrated reader HW makes them mostly just bulky USB tokens (card+reader).

anologwintermut 13y ago
If you are practicing NSA is out to get me security: USB tokens are probably the worst idea possible. They are practically unauditable (sure, maybe the design is open source, but is that actually what got put on the chip?) and specifically intended for cryptographic function by paranoid people who think they have something to hide. I.e. they are likely one of the first thing the NSA would target. And they are easy to target since everyone knows exactly how they will be used and what code will execute on them. You'd be better off going with an x86 chip and avoiding the obvious hardware backdoor channel of a bad RNG(though for key generation it's unlikely NSA would ever see enough bits from the RNG to crack it). Because it's a generic computer, you can't just break the chip by backdooring everything(e.g. make xor a nop). You'd need to screw with instruction only if it is part of a cryptographic operations and that would be very very tricky and use up a hell of a lot of the transistor budget.
- zokier 13y ago
  But what are the potential threats a backdoor in a USB token could have? Assuming it's used with (audited) open source drivers and keys are generated externally (ie by the host computer and not by the token) I don't really see a possibility for NSA to weaken the crypto. Of course there might be backdoors for physical attacks (or malicious driver attacks), but I'm willing to accept that.
csears 13y ago
Yubico makes a couple products that might fit your requirements. The YubiHSM [1] ($500) is a USB HSM designed to be connected to server. Yubikey Neo [2] ($50) is does end-user authentication (OTP, CCID, SE, JavaCard) over NFC or USB. They can both be ordered in quantities of one and have open source SDKs [3]. [1]: http://www.yubico.com/products/yubihsm/ http://www.yubico.com/products/yubihsm/ [2]: http://www.yubico.com/products/yubikey-hardware/yubikey-neo/ http://www.yubico.com/products/yubikey-hardware/yubikey-neo/ [3]: http://www.yubico.com/develop/open-source-software/ http://www.yubico.com/develop/open-source-software/

tptacek 13y ago

This is extremely silly. Construct a scenario in which a compromised hardware random number generator enables NSA to somehow recover the bits from a GPG key you generate at some unknown point in the past. Try to be as specific as possible. I think the concerns about backdoored hardware RNGs are really overblown, but if we're going to stipulate they're to be taken seriously, they relevant on online attacks against systems that make repeated requests for entropy. Along a similar vein, every attack you've heard of on AES or even RC4 requires many repeated calls to the cipher, often with other parameters fixed. Just generate the damn GPG key and be done with it.

jacquesm 13y ago
It's hard to be a tinfoil hatter when everybody else is now just as paranoid as you were 6 months ago. So tinfoil hatters have to up the ante or go mainstream :)
- ppierald 13y ago
  I nominate you for HN Comment of the Year!
- einhverfr 13y ago
  Given that I keep hearing security professionals say they weren't paranoid enough, I suspect the truth is everyone else now is more paranoid than you were six months ago, which must be really disconcerting.
einhverfr 13y ago
I could imagine hardware built to grab public keys, and I could imagine such in a general purpose computer. However in the end there are a large number of problems so this is not a scenario to worry about. Yea, just generate the key and be done with it. But the problems include: 1. So suppose you build into a computer an effort to recognize some public key generation routines and intercept the key from memory. This could be done, but updating the firmware code (since it is hidden from the user of the computer) is pretty hard so it only works on versions current at the time of manufacture. If you have had the computer for a few years, such recognition would seem iffy. Additionally this gets more complex when supporting more implementations.... 2. Ok, so the computer malhardware has got the key, so what can it do with it? If you send the key over the internet, someone at some point may detect it. Likely the best scenario would be to store it and wait for some attempted handshake on, say, a firewire port, and then send it out then. Or one could wait for an SSH connection to an NSA-used cert for something like Google, but certs expire so that attack won't be worth it. Tinfoil mode is interesting but part of the benefits are thinking through the possible exposure of something like a compromised piece of hardware. Again, suppose the RNG is compromised. usually this means one can guess future values based on past values. An attack without past values is worthless, so it is unlikely to be helpful with regard to public key encryption as you point out.

wtn 13y ago

Most S/MIME certificate authorities require the generation of private keys using the "keygen" tag. Most browsers that support this tag require the generated key length to be 1024 or 2048 bits, whereas forcing either 2048 or 4096 bit keys would be more sensible. https://bugzilla.mozilla.org/show_bug.cgi?id=495836 https://bugzilla.mozilla.org/show_bug.cgi?id=495836

enupten 13y ago

I guess this is why RMS dislikes binary blobs. Something like the Lisp machine, where you can access/modify OS source while it's running, would be dream come true in today's world.

oscargrouch 13y ago
your post give me one idea: what about using am Rodeh Btree[1], to create concurrent snapshots of the running kernel, in this btree, so we could switch them in runtime.. you compile a new version (CRC does not match) them it will create a new branch/snapshot on memory and will start from there.. kernels of course should be designed in a transactional way manage states, etc.. rsrs.. anyway just a wild idea, dont know if its even useful doe.. [1] - B-trees, Shadowing, and Clones -http://www.usenix.org/event/lsf07/tech/rodeh.pdf http://www.usenix.org/event/lsf07/tech/rodeh.pdf
- oscargrouch 13y ago
  other design note to make this feasible, its to design it in a way, where each cpu core, could have its own kernel copy.. so you can try to boot up, the other version in another core, while you are using the old version in an active/context core?

Sanddancer 13y ago

I was hoping that this would have been something interesting, like a discussion on using avalanche noise ( http://holdenc.altervista.org/avalanche/ http://holdenc.altervista.org/avalanche/ ) in a portable way, or other bits of proper hardware hacking. Not trusting any hardware RNG is silly, especially if you can learn from first principles how they work, and build one yourself.

privasectech 13y ago

I'm curious why there was no consideration for OpenBSD?

privasectech 13y ago

Interesting that you can only buy an OpenPGP smart card from a supplier with a broken SSL implementation. https://shop.kernelconcepts.de/login.php https://shop.kernelconcepts.de/login.php

agwa 13y ago
They're not broken; they're simply using cacert.org instead of a mainstream CA. From a business standpoint, that's a terrible idea for selling to the general public, but from a security perspective it's fine. Incidentally, they sign their order confirmation emails with PGP. :-)

olympus 13y ago

I applaud the author's idea, but let me share some of my experiences (both good and bad) since the DoD uses smart cards every day for a myriad of things including: document signing, document encryption, computer logins, website logins, biometric information storage, medical information storage, and probably a few more that I am forgetting. 1. You should choose a long PIN. In the DoD there is a feature on the smartcard that locks the card after three consecutive incorrect PIN entries (no time limit). Obviously this is a good security measure. When DoD personnel have locked out their smartcard they go to the computer help desk where there is a trusted agent like a (properly trained) young enlisted troop who has a high privilege key that can unlock your smartcard. You do not have a worldwide network of locations where you can get your card unlocked, so you cannot implement the "three tries and you're dead" feature. Therefore, make your PIN as long as practically possible to prevent someone who stole your card from being able to brute-force the PIN and get your keys. 2. You might want to make a duplicate card and store it in a safe location. You WILL eventually lose the card you are carrying around with you, and when you do, it essentially means the loss of all your encrypted data. While the second set of keys lying around is a vulnerability, it might be an acceptable one to hedge against the loss of your data. Having a duplicate card might also allow you to implement the feature where the smartcard locks after a number of unsuccessful PIN entries. 3. Do NOT use USB drives as an alternative token because you don't want to shell out for a smartcard. USB drives introduce known vulnerabilities and they are prohibited DoD-wide on ALL of their networks (including all our classified nets). If the lowly USB drive has the power to make the DoD shake in its boots, you shouldn't be using one when you need security. 4. Smartcards are cool in an enterprise setup for signing documents and stuff, but make sure you aren't triple locking your door and then leaving your window open. If you decrypt an email and view the cleartext with a text editor, make sure you are not beaming that back to your attacker because they compromised your machine in another way. 5. Related to #4 above, the most secure systems are standalone systems that NEVER connect to a network. Instead of shelling out for some smartcards and readers, buy a Raspberry Pi, and generate your keys on it- and your private key will never leave this machine. Use write-once media to get your public key on a networked computer (this should be the ONLY time you transfer data off of your standalone system). Whenever you need to decrypt something, use more write-once media to get the encrypted data onto your standalone RasPi, and decrypt it and view it. If you want to be super paranoid, maintain an 18" air gap between your standalone RasPi and any networked computer. This is the proper way to wear your tinfoil hat. Plus, the RasPi is cheaper than a smartcard setup, and invulnerable to keyloggers and pretty much any other attack because data exfiltration is impossible when you never connect it to the network and you never send data off of it.

aidenn0 13y ago

How about rolling an octahedron? You can generate 3 bits per roll, it takes about 3 seconds to roll and record the result, for a total of 1 bit per second. How much entropy is needed to generate a 4096 bit key? Of course this is likely less secure than using /dev/random, as you will be typing in the bits, someone could log the bits you type in, someone could have a telephoto lens and take pictures of your dice rolls. It's always possible to be paranoid to the point that whatever you do isn't secure.

olympus 13y ago
>someone could have a telephoto lens and take pictures of your dice rolls< Roll a braille octahedron in your bathroom with the door locked and the lights out. Type the bits on an offline computer so the keylogger can't report back to its owner.
- derefr 13y ago
  They can use an infrared lens to look at indentations created on your fingertips as you read the braille. ;)
zokier 13y ago
> How much entropy is needed to generate a 4096 bit key? 4096 bits?
- aidenn0 13y ago
  I doubt it is 4096 exactly, since a RSA key involves generating random large primes, right?

derefr 13y ago

> Obviously there is still the risk of a tampered compiler but I consider this risk as rather academic. Some part of me wants news to come out that there has for years been an NSA code-injection backdoor in, say, Debian's binary "lineage" of GCC. Imagine the reaction.

lifeisstillgood 13y ago
to be honest not that much. most people have never heard of Linux let alone Debian compiler toolchains. and almost everyone who has heard of it, already is reacting about as hard as they can.

derefr 13y ago

How hard would it be to print a smart card with currently-shipping consumer 3D printers? If not-that-hard, then would collaborating to create a verifiable Open Smartcard Board + Firmware be a useful idea? It'd neatly short-circuit having to trust the entire consumer hardware+software stack.

InTheSwiss 13y ago
The card itself is just a piece of plastic, it is the microchip that is the important part and I am not aware of any 3D printing system that could print something that complex just yet.
- derefr 13y ago
  How many gates does a chip need if it's basically a single-purpose crypto ASIC? Presuming you can expand the traces out to cover the entire back of the card (no die, just raw PCB), what process size would you need? I guess, if that doesn't work, we could always just work on an Open Smartcard Microcontroller For FPGA-based Cards. Then the one thing you need to trust is that FPGAs don't have a special backdoor mode for when they somehow detect that the chip they're running is doing crypto ;)

bdamm 13y ago

I thought this was a great idea, a GnuPGP ready card! This means there's firmware on the card that is known to be compatible with GnuPGP protocols, and pscsd as well. Very nice. So I went to buy, and the seller has a market place with a self-signed certificate. They won't get my dime.