If you do roll your own and you’re not a high value target (aka there aren’t a lot of assets they can seize or are a notorious criminal) nobody is going to take the time to bust open your homegrown setup. Security by obscurity is powerful. There is a reason why Wordpress sites get hacked a lot: the exploit has a lot of leverage with 1/4 to 1/3 of the public web using it.
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.
It's definitely a dilemma. I guess the sweet spot would be security systems that are well understood in house but built on existing, well understood and studied standards and theory.
A starting point might be to use battle-tested open source systems but subject them to detailed in-house analysis and audit.
I always took this as "you're not a domain expert so you'll get it wrong", with the implied corollary that if you actually _are_ a domain expert, then you know what you're doing. IOW, hire bonafide domain experts rather than trying to cheap out.
Oh, indeed, unless you're DJB, never roll your own. I mean you should understand what you're doing and why you're doing it, not leave it up to someone else to make decisions for you. Not that you should re-invent the wheel. :-)
Do not rely on technical means to solve an administrative problems. Vito Corleone didn't have messenger apps, email or ERP systems, but his enterprise ran like like a clock. So should yours.
1. That's it, if you don't use phones for your criminal activities, most modern technological surveillance techniques will not be effective against you.
2. There were a lot of non-fictional organizations that ran just fine without any modern means. Genghis Khan conquered a lot of countries without relying on radio for communications or satellites for reconnaissance. Using a WhatsApp-like chat apps to communicate about criminal activities is very convenient, but opens a new vector of attack against you.
One time pads are really inconvenient and hard to get right. That's why they are almost never used in practice, despite being theoretically perfect.
First, you need to generate large amounts of unbiased, true random data. If it is not true randomness, you have a stream cypher, and if you "rolled your own", probably not a good one.
They you have to store the one-time pad. It is usually too big to memorize. You have to store in on a device like a USB stick or a book, and guard it well.
Then, you have to share the secret, and for that you need a secure channel and that shouldn't rely on encryption, because it would miss the point. Essentially, you need to meet in person, in a secure location.
Then, you need to make sure that the one-time pad really is one-time. It should be securely destroyed after each use, preferably on both ends.
IF you want to send arbitrary data. Usually people don't need that.
For something like coke smuggling you just need to know its on the way, get ready. So the OTP could be something as lame as "if you get a phone call from some rando who says 'Taste the Feeling'" then the next boat is full of coke, or if not, then the next boat is not full of coke". Actually terrible idea as taste the feeling was a coke company slogan a couple years back, but you get the general idea.
Most criminal activity involves communicating arbitrary data. Communicating that a drug boat is coming across a border is a tiny fraction of the communication in a criminal organization. In the scenario you described, planning out the communication protocol itself is an example of communicating arbitrary data... That needs to happen, at every physical hand-off point.
I had recently finished reading both books by Robert Mason, who started out flying helicopters for the Army in Vietnam and ended up smuggling literal tons of weed and got caught and did federal time. Pretty interesting autobiography. Anyway my comments fit pretty well with his description contained in his second book.
Mr Mason got caught by bad luck. There will always be small timers who do things small timer style who get caught by being verbose and oversharing, and to catch those we'll have "encrypted" smartphones.
You generally need more information flow than that to successfully coordinate a big logistics move like this though which is where you need arbitrary messages.
In this situation that would leave you open to network analysis and location analysis, even if no payloads were decryptable.
Using enough data warehousing and artificial intelligence, eventually some algorithm would notice that every time some dude gets a phone call, next month the same boat gets a bill for servicing its water intakes, and a month later coke supply increases in .au decreasing the price. Might take a few times, but someone's getting caught.
The best part is if they go in shooting on a warrant and kill some random completely uninvolved people, it was all an algorithm's fault and nobody is to blame and I guess we just need more police involvement and surveillance to prevent future tragedies.
If you have a way to security distribute one time pads you don't actually need one time pads as you have a way to security distribute the messages as the one time pads are higher than the size of the messages you are distributing.
- It was specifically marketed to criminal entities. That is, it sharply reduced the search space. In a 33 bit world, An0m is 14 bits.
- It was specifically back-doored.
"Roll your own" avoids the 2nd case but not the first. By definition, rolling your own already reduces search space to the domain of interest. (Other means of evidence gathering may be needed, but should be reasonably viablle.)
Instead, what you want is:
- Blend in with the crowd.
- Utilise widely-shared communications protocols, implementations, and tools.
- Ensure that these have secure cryptographic methods and implementations.
- Audit the hell out of these and offer bounties for any vulnerabilities which can be demonstrated.
If at all possible, see to it that widely-used, generally-available communications tools themselves offer secure cryptographic methods and implemntations. And school your minions in their proper and effective use and limits.
> - Audit the hell out of these and offer bounties for any vulnerabilities which can be demonstrated.
The NSA backdoors will be pretty hard to find if they are there - It's not like you are going to see something like "If User == "NSA" Then Divulge_Key()". The backdoor is going to be something like a very subtle bug with how a particular crypto library is implemented, or some obscure buffer oveflow attack, and it probably won't even be discernible from an accidental bug.
In reality I doubt there is any way to know if the NSA can eavesdrop, it's a complete coin toss.
AFAIU most of the NSA's capabilities come through workfactor-reduction values --- seed values to cryptographic functions which reduce the time to crack a given message (if the secret seeds are known).
Avoiding NIST-recommended ciphers seems to be generally-advisable in this case.
There are other backdoors (see the case of Juniper Networks), but there's probably an enumerable set of pracices.
One helpful option is to use Free Software tools in which single actors are ulikely to be able to subvert the tool, and many have an interest in its integrity.
