4 ms·

The only encryption I truly trust is one-time pad. Discrete log may be NP-intermediate (if P!=NP, which is open), and we know from the Snowden disclosures that

by 1001101 10y ago

The only encryption I truly trust is one-time pad. Discrete log may be NP-intermediate (if P!=NP, which is open), and we know from the Snowden disclosures that NSA was working with U Maryland on a quantum computer which will be a reality at some point (Shor's algorithm). With 'collect it all,' today's ciphertext is tomorrow's plaintext. Always be skeptical.

notfed 10y ago
If you trust a one-time pad---which no one actually uses---you can trust stream ciphers, which are actually practical.
- im3w1l 10y ago
  That doesn't follow at all...
  - notfed 10y ago
    Sure it does. A stream cipher is essentially the practical version of a one-time pad. Neither system is vulnerable to quantum attacks. For both, the weak link is in keeping the key secure. If you can keep a one-time pad secure, you can keep a 256-bit key secure.
    - 1001101 10y ago
      By all means, continue using RC4, A5, etc.
andai 10y ago
Your downvotes courtesy of NSA's botnet ;) Do you use OTP? I've done some little experiments. I'm surprised at the lack of interest in the only form of encryption that is literally unbreakable, in this age of surveillance paranoia.
- 1001101 10y ago
  I have not. I had discussed a theoretical len(CT) == len(key) system with a friend for about 30 mins as a thought experiment, but we immediately poked a number of holes in it -- not the least of which being that we couldn't say anything about the security of the system on which it was deployed. Other questions: what to do with the key material files (their remnants would no doubt be left intact in NAND by opaque eMMC and SD controller implementations - and if not, some signal processing on the charge of the cells themselves combined with the regularity of whatever language was being used would give it up anyway - encrypting the key material might solve this to a degree). Also: where to get quality key material in the first place, and how to exchange it (NFC was discussed). I'll certainly take Claude Shannon's word on the security :)
  - andai 10y ago
    1. Security of the system: I'm thinking about this lately: below in this thread I mentioned a setup involving an airgapped non-intel (eg. Rpi) computer that communicates ascii in morse code. This machine would hold the keys and encrypt / decrypt. 2. What to do with the files? You'd need to keep them as long as you need to use them. In my scenario it would be on an SD card in the raspberry pi. Afterwards.. there are many creative ways to destroy them :) i think an advantage of SD over HDDs is they are small enough to reasonably melt. 3. Key exchange: exchange the key on physical media, in person. Ensure the key does not come into contact with a networked computer (ask your friend nicely) and keep it away from any untrusted USB devices. 4. Quality key material: Hardware random number generator (also done on an airgapped etc machine). I think I've covered everything, the only thing that crypto people on IRC could really complain about (it seems they really don't like OTP?) was integrity: an attacker could modify the message if they guessed parts of it. I'm still figuring out how that would work (they assumed it would be used for a standard protocol with something like "From: andai@andai.tv" at the start of every message). Now I'm just trying to make it so that anyone could set this up, which is turning out to be the trickiest step. For the simplest form of encryption there sure aren't a lot of implementations out there...
    - 1001101 10y ago

by 1001101 10y ago

notfed 10y ago

If you trust a one-time pad---which no one actually uses---you can trust stream ciphers, which are actually practical.

im3w1l 10y ago
That doesn't follow at all...
- notfed 10y ago
  Sure it does. A stream cipher is essentially the practical version of a one-time pad. Neither system is vulnerable to quantum attacks. For both, the weak link is in keeping the key secure. If you can keep a one-time pad secure, you can keep a 256-bit key secure.
  - 1001101 10y ago
    By all means, continue using RC4, A5, etc.

andai 10y ago

Your downvotes courtesy of NSA's botnet ;) Do you use OTP? I've done some little experiments. I'm surprised at the lack of interest in the only form of encryption that is literally unbreakable, in this age of surveillance paranoia.

1001101 10y ago
I have not. I had discussed a theoretical len(CT) == len(key) system with a friend for about 30 mins as a thought experiment, but we immediately poked a number of holes in it -- not the least of which being that we couldn't say anything about the security of the system on which it was deployed. Other questions: what to do with the key material files (their remnants would no doubt be left intact in NAND by opaque eMMC and SD controller implementations - and if not, some signal processing on the charge of the cells themselves combined with the regularity of whatever language was being used would give it up anyway - encrypting the key material might solve this to a degree). Also: where to get quality key material in the first place, and how to exchange it (NFC was discussed). I'll certainly take Claude Shannon's word on the security :)
- andai 10y ago
  1. Security of the system: I'm thinking about this lately: below in this thread I mentioned a setup involving an airgapped non-intel (eg. Rpi) computer that communicates ascii in morse code. This machine would hold the keys and encrypt / decrypt. 2. What to do with the files? You'd need to keep them as long as you need to use them. In my scenario it would be on an SD card in the raspberry pi. Afterwards.. there are many creative ways to destroy them :) i think an advantage of SD over HDDs is they are small enough to reasonably melt. 3. Key exchange: exchange the key on physical media, in person. Ensure the key does not come into contact with a networked computer (ask your friend nicely) and keep it away from any untrusted USB devices. 4. Quality key material: Hardware random number generator (also done on an airgapped etc machine). I think I've covered everything, the only thing that crypto people on IRC could really complain about (it seems they really don't like OTP?) was integrity: an attacker could modify the message if they guessed parts of it. I'm still figuring out how that would work (they assumed it would be used for a standard protocol with something like "From: andai@andai.tv" at the start of every message). Now I'm just trying to make it so that anyone could set this up, which is turning out to be the trickiest step. For the simplest form of encryption there sure aren't a lot of implementations out there...
  - 1001101 10y ago