Why not both? Encrypt your message with your home grown encryption, then send it through standard TLS. Both would have to fail for the message to be revealed.
Sometimes when I'm wearing my tinfoil hat I wonder if the advice to avoid rolling your own crypto is a conspiracy. The powers that be want to maintain their backdoors, maybe? Probably not. Of course, it's definitely true that there are more attack vectors out there than an amateur can be aware of.
I also wonder why there's such a pushback against one-time-pads. The common critiques don't seem to be any greater of a risk than the holes we've already encountered (e.g. heartbleed).
I think I remember a scifi story that mentioned some character who worked in the one-time-pad shipping business. I guess a spacecraft full of data storage can hold enough random data to last for a long time.
Seems like we should at least come up with a proper protocol for it, so we can at least get started with something that's broadly compatible.
Unless you’re using a true random number generator that works on a mechanical/electrical process a lot of encryption algorithms are various ways of creating a one-time pad. And they save a lot on space which used to be precious. With a single key much smaller than a megabyte I can encrypt essentially endlessly where for the normal OTP process I need as much random data as there is data to be encrypted which gets unwieldy extremely quickly even with cheap storage.
> Unless you’re using a true random number generator that works on a mechanical/electrical process…
…you're not using a one-time pad. OTP requires the pad to be truly random: at least one bit of unique, never-used-elsewhere entropy for every bit in the message. Merely XORing some plaintext with a pseudo-random stream based on a smaller seed, which as you say is the basis for various other encryption algorithms, is not a one-time pad.
The real problem with OTP is key distribution: You need to share pads with everyone you might want to communicate with, one pad per sender/receiver pair, and those pads need to be at least as large as all the message you'll eventually want to exchange. There is no OTP equivalent to public-key cryptography where you only need one private/public keypair per recipient.
Which is why it seems like there should at least be an RFC for OTP communication - if there's a small group that wants to communicate securely together, it may be worth their time and effort to share that pad securely. Right now, there's no official standard for that.
That's what I was saying a true OTP is a cumbersome version of stream cyphers that trades some improvement in security for a huge increase in fragility and difficulty of use and distribution.
The OTP algorithm can be seen as a form of stream cipher (where the key is the stream), but what you actually said was "a lot of encryption algorithms are various ways of creating a one-time pad". This is false since a one-time pad must be truly random and the stream produced by the other algorithms is only pseudo-random; you can't "create" a one-time pad using a pseudo-random number generator. This is a qualitative difference in security because a pseudo-random stream is subject to brute-force searches to locate the seed which decodes the ciphertext to a meaningful message (the number of possible seeds is much smaller than the number of possible messages, so you can generally determine when you've found the right key) whereas with a properly implemented OTP for any message of size equal to or smaller than the ciphertext there exists a key which will decode the ciphertext into that message (possibly with some padding), so brute-force search is impossible.
I wouldn't call OTP "fragile" or "hard to use", but you're correct about the key distribution difficulties.
Unless that was a preshared key, you're not talking about a one time pad. One time pads are inherently symmetric. If you're comparing symmetric to assymmetric crypto systems, you might as well just say that 'if my grandmother had wheels, she'd be a bicycle'.
Is there a pushback against one-time-pads? I thought they are the perfect, unbreakable encryption scheme - just that they come with extreme logistical problems.
> I think I remember a scifi story that mentioned some character who worked in the one-time-pad shipping business.
One time pads punt on the real problems of key distribution and framing (eg a stream cipher uses a "one time pad" as a building block) and also don't provide all of the qualities we expect from modern cryptographic systems (eg message integrity).
I think that this isn't strictly true. If you naïvely apply bad encryption before good you may weaken the entire system. For a silly example, imagine your "homegrown" crypto adds a publicly known plaintext to the start of the cyphertext. I think this is discussed in Schneier's textbook.
> If you naïvely apply bad encryption before good you may weaken the entire system
The strength of the system can be viewed from multiple angles. From a practical angle, applying one kind of commercial encryption on top of another type of commercial encryption turns it into a technically weaker, but unique cryptosystem. And uniqueness has value if you're just a single fish in a big pond.
For instance, if one single An0m customer had applied a caesar cypher to their communications, the cops might have skipped over him due to the unknown cost of putting dedicated crypto effort into one person in a massive dragnet.
So? https it adds a publicly known header at beginning of any connection anyway and I don't see public key encryption being cracked anyway. Or blockchains do that too, are wallets being emptied by the ones that don't have the private key?
And since you mentioned Schneier textbook, he also said that a good safe is the one that you give to your adversaries with the blue print of how it's made and still is uncracked, not the one that you dump in the middle of the ocean and ask your adversaries to crack it (security through obscurity).
PGP is still uncracked, if I'd become a criminal then public PGP with at least 8k bits key would be my choice.
> PGP is still uncracked, if I'd become a criminal then public PGP with at least 8k bits key would be my choice.
It's not PGP that is uncracked, PGP is a set of tools built on top of RSA. RSA is still secure (other than brute force factoring) with appropriately sized keys.
The biggest problem with PGP isn't PGP itself, it's your opsec approach to everything else. Example... after decrypting a PGP payload - did you save it to disk unencrypted? Did the recipients to your messages save it unencrypted? Are any machines infected with keyloggers? PGP is a great tool, but still requires good opsec overall.
You're technically right, but it's practically true for good algorithms. Yes, if you apply a rot(-13) before your rot(13) "encryption" it's going to make it worse.
I think that if we are going to be concerned about multiple layers of encryption, as you say, then we should be equally concerned with things such as what encoding we use to send text with, or whether we use gzip or bzip. It would suck having to worry about all that; good encryption algorithms work regardless of how their plaintext is encoded, and home grown encryption is just another form of encoding.
Sometimes when I'm wearing my tinfoil hat I wonder if the advice to avoid rolling your own crypto is a conspiracy. The powers that be want to maintain their backdoors, maybe? Probably not. Of course, it's definitely true that there are more attack vectors out there than an amateur can be aware of.