5 ms·

From http://www.gnupg.org/gph/en/manual/x110.html http://www.gnupg.org/gph/en/manual/x110.html "A public and private key each have a specific role when encrypt

by b_emery 13y ago

From http://www.gnupg.org/gph/en/manual/x110.html http://www.gnupg.org/gph/en/manual/x110.html "A public and private key each have a specific role when encrypting and decrypting documents. A public key may be thought of as an open safe. When a correspondent encrypts a document using a public key, that document is put in the safe, the safe shut, and the combination lock spun several times. The corresponding private key is the combination that can reopen the safe and retrieve the document. In other words, only the person who holds the private key can recover a document encrypted using the associated public key."

auctiontheory 13y ago
In a world where the US government is scanning all your electronic communications, and (we'll next discover) searching your OS X- and Windows-based computers at will, how do you, as a practical matter, keep your private key "private"?
- caycep 13y ago
  Obviously, hide it in the "garbage file". Even Angelina Jolie knows this!
- deleted 13y ago
  [deleted]
- mpyne 13y ago
  Keep it public, but use a very good passphrase. That's not impossible to do. I'm not a crypto type but I believe what you want is a password-based key derivation function such as scrypt, the output of which you can then use as the symmetric key to encrypt/decrypt the private key. (This might even be what GPG/SSH does for you; I'm not at all sure)
- trotsky 13y ago
  If you want a realistic chance of not losing control of your private key the only real answers are hardware based - using a tamper resistant smart card, hardware security module, tpm or similar systems in which the signing is done inside the chip that contains your signing keys and no general purpose device ever sees the key at all. Most people using software only solutions won't ever have their keys stolen, but that's because nobody tried to steal them. The compromise of a client os is inevitable if targeted by a competent actor, given enough time. Smartcards and HSM's may not be infallible, but their rate of compromise appears to be negligable at best and an extremely rare capability for an offensive team to have access to. Smartcards are surprisingly cheap and easy to work with, and due to their simplicity and long history are quite secure. The only real attack on them involves physical access and causes obvious physical damage that'd be impossible to miss.
  - nthj 13y ago
    I would be very interested in a a tutorial or guide for getting something like this set up on OS X.
    - dsl 13y ago
      OS X has smart card support for FileVault 1 but not FileVault 2. It only includes enough drivers to support US DoD CAC cards, and other NATO countries that have standardized on our stuff.
      - kgo 13y ago
        With regard to PGP, you can get a reader and smartcard from Kernel Concepts. Assuming you already know how to use GPG, it's pretty easy to set up. http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&language=en http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&l...
    - trotsky 13y ago
      The answer depends on what kind of key material and applications you use. Sadly there is no one size fits all system. https://www.opensc-project.org/opensc/wiki/OverView https://www.opensc-project.org/opensc/wiki/OverView this would probably be the place to start, at least to figure out which type of card you'd want. The main choices are a) support pgp and ssh b) support x.509 certificate based signing c) support time or use type tokens (like smartphone 2 factor apps) or d) some non standardized system running custom code on a tiny jvm inside the card. a) would be what you'd want in the context of this conversation, but b) is much more supported and has a wider set of use cases. In most cases it amounts to making sure you buy the right card & reader, plugging it in, and compiling the opensc and related packages
  - deleted 13y ago
    [deleted]
  - antocv 13y ago
    I may be on the edge but a "Trusted Platform Module" doesnt automatically let me conclude that indeed the hardware module is to be trusted. It seems quite unlikely the masses would have access to a trusted platform of any kind, especially considering that any secure platforms for communication that have existed, like Skype, have been opened up. Even good old GSM (AS/1 was it called?) voice-talk encryption was designed with a backdoor in mind at the urging of NATO.
- jlgreco 13y ago
  Only use your private key with Tinfoil Hat Linux on an offline air-gapped computer: http://tinfoilhat.shmoo.com/ http://tinfoilhat.shmoo.com/ I recommend disconnecting your monitor and only receiving output by having it blinked out at you through your capslock light on your keyboard. Bonus points if you can get your hands on some TEMPEST hardened hardware, and/or tamper-resistant hardware. Anything less will leave you vulnerable to the black helicopters! Note: I'm joking obviously, but this is something to take seriously.
  - MiguelHudnandez 13y ago
    The light reflected off your eyes from the capslock key is readable from high-res cameras. It's better to have leads hooked up to one of your toes and to toggle a 24V source so you can interpret the pulses in morse code. Edit: obviously the 24V must come from a battery which is charged only at specific intervals -- otherwise they can interpret your messages by watching mains voltage variation.
    - cheald 13y ago
      Those leads are gonna generate magnetic distortions. You should only do this with your feet next to a giant 18" subwoofer while blasting dubstep in order to mask any electromagnetic fluctuations. Bonus: Anyone surveilling you via audio bugs will need new ears.
      - trotsky 13y ago
        I know this is all in good fun, but you all are uncomfortably close to describing things that will soon get added to the practical threat landscape. As long as you have a flexible hardware platform that lets you crank up some of the voltage regulator outputs, gpios that can be attached to a long trace/external wire as a makeshift antenna and have a decently fast cpu clock you have all the ingredients for a crude but usable software defined radio. maybe not super fast if you can't repurpose a hardware phy or radio interface, but more than enough bandwidth to exfil a secret key or 10 for maybe a couple dozen meters. Tools to do sdr utilizing only general purpose processors and no radio specific gear are already available here and there as research implementations, and code that uses gpus/audio dacs/ and re-purposed phys to make a radio interface with a different spec or broadcast frequency is already in production use (wifi phy using a dvb radio interface -> tv whitespace communicator). Using an approach like that to exfil or bridge an air gap is just too tempting for it to not happen. Honestly, I'd be willing to bet there's already an example of that somewhere out there in the wild today.
- joeblau 13y ago
  FIPS 140-2 hardware encryption module - Generate your keys on an IronKey.

by b_emery 13y ago

auctiontheory 13y ago

In a world where the US government is scanning all your electronic communications, and (we'll next discover) searching your OS X- and Windows-based computers at will, how do you, as a practical matter, keep your private key "private"?

caycep 13y ago
Obviously, hide it in the "garbage file". Even Angelina Jolie knows this!
deleted 13y ago
[deleted]
mpyne 13y ago
Keep it public, but use a very good passphrase. That's not impossible to do. I'm not a crypto type but I believe what you want is a password-based key derivation function such as scrypt, the output of which you can then use as the symmetric key to encrypt/decrypt the private key. (This might even be what GPG/SSH does for you; I'm not at all sure)
trotsky 13y ago
If you want a realistic chance of not losing control of your private key the only real answers are hardware based - using a tamper resistant smart card, hardware security module, tpm or similar systems in which the signing is done inside the chip that contains your signing keys and no general purpose device ever sees the key at all. Most people using software only solutions won't ever have their keys stolen, but that's because nobody tried to steal them. The compromise of a client os is inevitable if targeted by a competent actor, given enough time. Smartcards and HSM's may not be infallible, but their rate of compromise appears to be negligable at best and an extremely rare capability for an offensive team to have access to. Smartcards are surprisingly cheap and easy to work with, and due to their simplicity and long history are quite secure. The only real attack on them involves physical access and causes obvious physical damage that'd be impossible to miss.
- nthj 13y ago
  I would be very interested in a a tutorial or guide for getting something like this set up on OS X.
  - dsl 13y ago
    OS X has smart card support for FileVault 1 but not FileVault 2. It only includes enough drivers to support US DoD CAC cards, and other NATO countries that have standardized on our stuff.
    - kgo 13y ago
      With regard to PGP, you can get a reader and smartcard from Kernel Concepts. Assuming you already know how to use GPG, it's pretty easy to set up. http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&language=en http://shop.kernelconcepts.de/index.php?cPath=1_26&sort=2a&l...
  - trotsky 13y ago
    The answer depends on what kind of key material and applications you use. Sadly there is no one size fits all system. https://www.opensc-project.org/opensc/wiki/OverView https://www.opensc-project.org/opensc/wiki/OverView this would probably be the place to start, at least to figure out which type of card you'd want. The main choices are a) support pgp and ssh b) support x.509 certificate based signing c) support time or use type tokens (like smartphone 2 factor apps) or d) some non standardized system running custom code on a tiny jvm inside the card. a) would be what you'd want in the context of this conversation, but b) is much more supported and has a wider set of use cases. In most cases it amounts to making sure you buy the right card & reader, plugging it in, and compiling the opensc and related packages
- deleted 13y ago
  [deleted]
- antocv 13y ago
  I may be on the edge but a "Trusted Platform Module" doesnt automatically let me conclude that indeed the hardware module is to be trusted. It seems quite unlikely the masses would have access to a trusted platform of any kind, especially considering that any secure platforms for communication that have existed, like Skype, have been opened up. Even good old GSM (AS/1 was it called?) voice-talk encryption was designed with a backdoor in mind at the urging of NATO.
jlgreco 13y ago
Only use your private key with Tinfoil Hat Linux on an offline air-gapped computer: http://tinfoilhat.shmoo.com/ http://tinfoilhat.shmoo.com/ I recommend disconnecting your monitor and only receiving output by having it blinked out at you through your capslock light on your keyboard. Bonus points if you can get your hands on some TEMPEST hardened hardware, and/or tamper-resistant hardware. Anything less will leave you vulnerable to the black helicopters! Note: I'm joking obviously, but this is something to take seriously.
- MiguelHudnandez 13y ago
  The light reflected off your eyes from the capslock key is readable from high-res cameras. It's better to have leads hooked up to one of your toes and to toggle a 24V source so you can interpret the pulses in morse code. Edit: obviously the 24V must come from a battery which is charged only at specific intervals -- otherwise they can interpret your messages by watching mains voltage variation.
  - cheald 13y ago
    Those leads are gonna generate magnetic distortions. You should only do this with your feet next to a giant 18" subwoofer while blasting dubstep in order to mask any electromagnetic fluctuations. Bonus: Anyone surveilling you via audio bugs will need new ears.
    - trotsky 13y ago
      I know this is all in good fun, but you all are uncomfortably close to describing things that will soon get added to the practical threat landscape. As long as you have a flexible hardware platform that lets you crank up some of the voltage regulator outputs, gpios that can be attached to a long trace/external wire as a makeshift antenna and have a decently fast cpu clock you have all the ingredients for a crude but usable software defined radio. maybe not super fast if you can't repurpose a hardware phy or radio interface, but more than enough bandwidth to exfil a secret key or 10 for maybe a couple dozen meters. Tools to do sdr utilizing only general purpose processors and no radio specific gear are already available here and there as research implementations, and code that uses gpus/audio dacs/ and re-purposed phys to make a radio interface with a different spec or broadcast frequency is already in production use (wifi phy using a dvb radio interface -> tv whitespace communicator). Using an approach like that to exfil or bridge an air gap is just too tempting for it to not happen. Honestly, I'd be willing to bet there's already an example of that somewhere out there in the wild today.
joeblau 13y ago
FIPS 140-2 hardware encryption module - Generate your keys on an IronKey.