New Al Qaeda Encryption Software

The Web intelligence company Recorded Future is reporting—picked up by the Wall Street Journal—that al Qaeda is using new encryption software in the wake of the Snowden stories. I’ve been fielding press queries, asking me how this will adversely affect US intelligence efforts.

I think the reverse is true. I think this will help US intelligence efforts. Cryptography is hard, and the odds that a home-brew encryption product is better than a well-studied open-source tool is slight. Last fall, Matt Blaze said to me that he thought that the Snowden documents will usher in a new dark age of cryptography, as people abandon good algorithms and software for snake oil of their own devising. My guess is that this an example of that.

Tags: , , , ,

Posted on May 14, 2014 at 6:30 AM • 64 Comments

Comments

Autolykos • May 14, 2014 6:58 AM

Anyone paranoid but not completely clueless will probably cascade the homegrown stuff with a common and well-tested algorithm. But unless they are overlaying their stuff over a widely-used program without touching anything (like putting their “encrypted” files inside a TrueCrypt container), they are still likely to screw up their implementation…
Still pointless, IMHO. A simple AES->Twofish->Serpent cascade should be more than conservative enough for even the most paranoid guy out there. It is highly unlikely that even one algorithm is backdoored, let alone all three of them.
Ironically, it may be that Snowden did more for intelligence on AQ than all of the surveillance by NSA and friends combined.

Dan • May 14, 2014 7:03 AM

I’ll stick with tried-and-true encryption tools (Truecrypt, GnuPG) and proper primitives (AES, SHA-2, DHE).

Clive Robinson • May 14, 2014 7:06 AM

The terrorists have two issues where as state level actors generaly only have one.

Terrorists need not just secure communications but also invisable or not findable communications.

Statelevel actors rarely have to conceal their prescence from each other thus their way to deal with traffic analysis is to keep circuits open for fixed periods always to the same points and stuff the circuit to maximum capacity irrespective of if they are actually carrying secure messages.

Terrorist etc do have the problems associated with traffic analysis which with most comms channels suffering from the “all pieces of string have two ends” problem which enables state level actors to identify both ends thus make the terrorit network and major actors visable with time.

No reliable encryption is going to help with the two ends issue or the other many traffic analysis issues, thus they have resorted in the past to “code talk” and similar obsfication/stenography to try to make the traffic look harmless. And the lower the bandwidth of such a covert channel in relation to the normal channel bandwidth the more likely it is to remain invisable.

Or that was the general theory prior to the Ed Snowden Revelations, however whilst most people assumed you could have invisable electronic communications prior to the revelations, it is apparent that terrorists and criminals were more than awre this was not the case (think of the way OBL worked his end of the comms).

Thus the question is wether these supposed changes are for real or just another part of the terrorists Meta-Data tricks such as knowing how long to use a burner phone prior to getting rid of it to some innocent who then gets droned.

Simon • May 14, 2014 7:14 AM

Cascading encryption? So, if once isn’t enough the second should make sure…right? Now who doesn’t know what they’re talking about? And of course one of those algorithms would HAVE to be a Twofish. What a crock. And I guess you’re going to yank strong unique keys for each out of thin air, then manage them all without compromising the application itself. Oh, and of course, be sure to throw in some mention of “tried and true” TC.

You’re all smoking crack. If you want some real snake oil this is the place to buy it.

TJ Williams • May 14, 2014 7:14 AM

Many assupmtions about what terrorists do or don’t do. A couple more:
– what if some groups have been infiltrated and that these “new” encryption tools have a backdoor?
– what if some groups have powerful sponsors and have access to crypto savvy resources?

Jacob • May 14, 2014 7:17 AM

My guess is that they may use existing crypto cipher primitives, or even the full encryption scheme, and then just repackage it for the specific app (like chat, mobile etc) and rename it to their liking.

Snarki, child of Loki • May 14, 2014 7:27 AM

If AQ responds to Snowden’s leaks by using insecure homebrew crypto, then Snowden has done the NSA (and the global anti-AQ effort) a good turn.

Why, they might even give him a medal, right before execution.

Clive Robinson • May 14, 2014 7:30 AM

If you look at the time line grafic you might actually find their argument unconvincing.

For instance the changes shortly before the Snowden revelations with an assumed lead time to develop of six months suggests the changes might have arisen due to organisational changes such as rifts etc. Thus changes shortly after the Snowden revelations might be a continuance of the other changes.

As normal the raw data needs to be available and analysable in a dispassionat way and other points in time added to the time line to show if other events are more likely…

Autolykos • May 14, 2014 7:46 AM

@Simon: If you know something about TrueCrypt or Twofish or supposed weaknesses in cascading that I don’t, feel free to put that right here where we can see and discuss it instead of spreading FUD. But judging from the style and tone of your post, you’re just out to randomly insult people on the web, so my hopes for learning something new from you are probably in vain.

species5618 • May 14, 2014 7:49 AM

my grasp of the the Al-Qaeda “problem” is point to point delivery of one off, time sensitive messages. Which I believe changes the requirements.

My in-depth knowledge of cryptography is limited, but if I were looking implement a system for a large organisation wanting lots of point to point encrypted messages. I may consider ebook sourced one time pads, distribution of the ebook identifier may be problematic. But the message it self should be unbreakable without the it.

Jackson • May 14, 2014 8:42 AM

I don’t think it serves us well to be too close minded about variations of crypto routines. If truecrypt may be compromised, which I believe we will discover it is – simply because compromise is the logic of the NSA, and truecrypt is a major product and so there is little doubt that it is targeted – what does it hurt to use any other encryption method, homebrewed or not, before or after it? It would foil, at least temporarily, any mass-decryptor.

Secure encryption transforms a message so that no significant knowledge of the plaintext besides its length is available in non-exponential time. Polynomial time preprocessing and postprocessing cannot harm its security and it certainly mixes things up. I would love to hear an actual argument why pre/post processing the input and the output of encryption doesn’t make it harder to break. Transform the input and any brute force attack on the central encryption algorithm has no markers to indicate that it has found the right key. And any attack on the post processing has to be able to tell which version of apparently random data is the central ciphertext.

Most attacks on encryption do not fully disable it. They just make brute forcing feasible. Why not make it hard for the brute forcing algorithm to detect success?

Yes, it is important to have strong central encryption algorithms in the mix, like AES. But I am sure that NSA would be pleased if the world is convinced to only use a small set of tools, limiting the number it has to break or compromise.

Autolykos • May 14, 2014 9:14 AM

@Jackson: Yup, that’s what I meant with “cascade it with something generally considered secure”. The stuff you built yourself is almost guaranteed to be bad crypto, but it is probably not backdoored (still, there are some arcane ways to backdoor compilers), so it will provide at least some obstacle if it passes basic statistical tests, and force the adversaries to dedicate some human brainpower to figure out what you did (but once they did that, it might as well not exist at all). You should think of it as obfuscation only.
The commonly used stuff is probably still computationally intensive to crack, even if the implementation is broken/compromised (otherwise it may well be impossible), but that can be automated.
If, however, you just want to make cracking harder by making the (intermediate) plaintext seem random, you might as well cascade good algorithms. They’re usually faster and definitely safer than anything you could build yourself.

Carl 'SAI' Mitchell • May 14, 2014 9:18 AM

If I were going to mess with an encryption algorithm I’d probably just add more rounds. It’s the change least likely to decrease security. 32-round AES-256 is unlikely to be less secure than 14-round AES-256, will probably still have reasonable performance thanks to AES-NI instructions, and might have improved security (depending on the types of attacks used against it.)

Clive Robinson • May 14, 2014 9:36 AM

@Jackson,

The idea of using even weak crypto as a precursor stage to stronger encryption has historic president.

Basicaly a keyed cipher that behaved more like a statistics flattener than a cipher was used. In many respects this is like using the likes of zip et al on a file prior to encrypting.

Further if the weaker cipher behaved in an orthagonal manner to the main encryption algorithm then it almost certainly will make the overall system stronger against the usual attacks.

Several constructs have been sugested such as stream ciphers preceading block ciphers, others have involved dynamic keying using a stream cipher to make a new block cipher key every few encryptions. And stream ciphers have been sugested as a method to “whiten” both input and output to the main block cipher used in simple Electronic Code Book mode, or the block cipher to replace the mixer function in a stream cipher.

No doubt other constructs will be found in various publications.

Just for fun how about considering AES256 with the left half of the input being fed from AES128 CTR mode and the plain text in 128bit blocks fed in the right half. Obviously it’s inefficient but does it have stronger properties against attack than XORing the plaintext with the AES128-CTR output and then feeding the result into AES128 in the same mode as the AES256 construct…

It’s finding the answers to such questions that keep students and others awake thinking in the middle of the night 😉

wiredog • May 14, 2014 9:37 AM

Also, this will, if anything, move AQ from the (supposedly compromised) homebrew system they used to known secure systems. If this gives them tactical security they didn’t have, and that results in a successful attack that otherwise would have failed, then Mr Snowden would definitely have gotten people killed.

Several ‘ifs’, and fortunately for him AQ and other Islamist organizations never bother going after Russians anyway.

The Fallacy of Accent • May 14, 2014 10:11 AM

Taking a step back to look at news stories about AQ encryption in context, it appears that they serve a propaganda purpose which empowers the NSA.

If I wanted to rule the world like the NSA, the propaganda strategy I would adopt is to widely publish news that links encryption use with an enemy.

Hammer two points home:

1) encryption use implies an enemy.

2) the NSA mission is defense against an enemy.

Having that established in the popular mind, then it automatically seems unpatriotic to be using encryption to protect your privacy.

To fight off “the inside threat” from “homegrown radicals”, laws can then be passed to regulate the use of encryption, limiting it to difficult to use and backdoored options.

Most people will abandon encryption after that, and control of their lives will pass to the NSA.

So, if we’re talking about AQ encryption rather than the criminality of mass surveillance, we are simply promoting the NSA’s talking points.

Martin Bonner • May 14, 2014 10:52 AM

wiredog:

AQ and other Islamist organizations never bother going after Russians

tell that to Russian soldiers serving in Chechnya!

AQz • May 14, 2014 11:07 AM

This software was obviously designed by a nation state to fool wannabe future terrorists into using it. I have never heard of any “operational planning” by Islamic militants being sent electronically. That ended years ago when they started catching cruise missiles after turning on their phones, and after #2 guy in AQ fled a safehouse in Egypt during a raid, and some journalist bought his drive from a parts dealer after it was looted.

These guy’s are not very organized. There is no bearded Dr. Evil in a secret bunker directing his army of militants with by the minute operational instructions. They aren’t a cartel or army. They plan stuff in safe houses in person then use couriers to keep in touch, sending clear text messages that are mainly just encouragement from their ‘spiritual leaders’ from what I’ve seen that was leaked. The bulk of their insurgency training comes for the late 70s I don’t see them changing anytime soon. That and Bin Laden lived in a technological black hole to avoid surveillance, so further credence to the argument none of these guy’s are using anything except word of mouth to pass crucial intel.

Since the Glen Greenwald/Snowden revelations that talking points are released to the media by intel agencies to warp political discussions and opinions this story is either a trojan horse to get militants to seek out this phony encryption or some lobbyists are trying to push for mandatory backdoors in encryption software and have begun the fear campaign so their shills in Congress can hold up articles like these and demand access to everything.

wiredog • May 14, 2014 11:08 AM

Martin Bonner
“It’s a joke, son, you’re supposed to laugh.”

If I were Snowden I’d be looking for a new home, fast. Assuming he’s allowed to leave.

Chris Abbott • May 14, 2014 11:14 AM

I’ve made my own homebrew crypto for fun before, but don’t actually use it for anything but experimental/educational purposes. I always use things like TrueCrypt and when possible, I use CSipSimple with ZRTP for talking to friends that have Android phones and TextSecure for SMS.

Given how cheap Androids are, this seems a lot more logical than homebrewing something, because these can be compiled from source to verify no backdoors.

I just wish there was more crypto software for communication that’s easy to use and actually has decent sound quality for both Android and iPhone. My girlfriend and I have had to resort to using proprietary stuff because she has an iPhone and I have an Android, and call quality is still a problem with a lot of Android stuff.

I just wonder what this terrorware actually looks like and what their trying to use. I can’t believe there’s a lot of super genius coders and cryptographers working for AQ.

@Clive

You’re right. Look at the software they were using pre-Snowden, they’re probably just upgrading or changing things up. We know they knew a lot of things before, like that cell phones could be used to track them, duh. I don’t see how the leaks really helped them a whole lot.

Eternal September • May 14, 2014 11:35 AM

@Chris Abbott
Textsecure should be available for iOS soon if not already. The sound quality also has to do with the handset, some older Nexus phones like Nexus 4 were notorious for dropping calls and having other problems when using encrypted voIP. You also get what you pay for, the quality for Silent Circle is quite high.

Anura • May 14, 2014 11:44 AM

@Clive Robinson

Just for fun how about considering AES256 with the left half of the input being fed from AES128 CTR mode and the plain text in 128bit blocks fed in the right half. Obviously it’s inefficient but does it have stronger properties against attack than XORing the plaintext with the AES128-CTR output and then feeding the result into AES128 in the same mode as the AES256 construct…

Why use AES-CTR at all? Why not get data from /dev/urandom? Why half? Why not take it further? Threefish-1024, with 1023 bits of random data, and 1 bit of plaintext data per round in CBC mode. It has the distinct advantage that it doesn’t require any extra padding scheme. Also, you might as well go ahead and encrypt the output in ECB-mode with AES, then Twofish, then Serpent. You might as well encrypt the whole shebang with ChaCha20 for good measure.

Also, make sure you shred and incinerate any device or person that saw the plaintext, immediately after they are no longer needed for the message exchange. All work should be done a kilometert under ground, surrounded by 10-meters of concrete lined with industrial aluminium foil, and an additional 1mm copper mesh faraday cage inside that on a raised platform. Devices should be powered by batteries, of course, and batteries should be stored in the inner faraday cage.

Ray Dillinger • May 14, 2014 11:53 AM

On the ground, this command probably came to somebody – or some small set of somebodies – who are highly computer and security savvy. Al Quaeda is known to have good operational security, or it wouldn’t have taken nearly as long to find bin Laden as it did. So presumably their people who do computer security are good at it. Hell, they probably read this blog.

If somebody who is actually good at computer security and programming, but not an actual crypto mathematician, gets an order to build a ‘new’ cipher, they’re probably going to know that they don’t have the mathematical chops to make a competitive one. This is especially a problem because as a secret organization they don’t have much access to publication and widespread review. However, they don’t have to worry about the stringent encryption/decryption speed requirements on which existing ciphers compete, so compute power is a design resource they can spend for security.

Under those circumstances I’d expect them to do their level best to create a secure cipher using the designs and properties of existing ciphers to make it at least as hard to crack as those ciphers. Thus, my bet would be on the ‘new’ cipher encapsulating a straightforward transformation of one or more existing trusted ciphers, and adding stuff (more rounds, extended key schedule, extra mixing steps…. ) that they’re “pretty sure” won’t interfere with the resistance to analysis of the reused parts.

As an example of the kind of design I’m talking about, If it were me I’d probably start with something like CAST-256 – a 16-year-old highly-studied Feistel cipher with no known breaks and a really impressive key size, that works on 64-bit blocks – then run it on two blocks at a time, compose the first 32 bits of each encrypted block with the last 32 bits of the other, run CAST-256 again on the resulting blocks, then repeat the switch-and-reencrypt step a third time, making something I could reasonably call “Triple CAST” but which an AQ designer under orders from that group would probably name for some holy site or martyrdom event in order to please his bosses. This would be a cipher working on 128-bit blocks.

Would it ever win a crypto design competition? Hell no, it’s an inelegant hack and something that takes one-third the time to encrypt/decrypt has already lost a competition for being too computationally heavy. But would anybody ever crack it? I’d be confident that for as long as nobody had yet announced a break on CAST-256, my 3CAST “invention” would be safe from cryptanalysis.

Chris Abbott • May 14, 2014 3:51 PM

@Ray Dillinger

If you’re more concerned about security than speed, which certainly AQ is, they may come up with something like that. Computing power has increased so much since the AES competition that it’s something to think about. A cipher with a large key size and a lot of rounds I think will be used in the future. I think someone will eventually someday probably have a practical attack on AES, just like what we’re seeing with RC4. Nothing can last forever.

4uhfi3ufh3iuh • May 14, 2014 4:23 PM

Yeah everyone should use a good NSA/CIA approved encryption like AES…

E Julia • May 14, 2014 5:12 PM

These are all CIA bait tools anyway. Terrorists know to use couriers, not the Internet.

Adjuvant • May 14, 2014 6:37 PM

@The Fallacy of Accent

Taking a step back to look at news stories about AQ encryption in context, it appears that they serve a propaganda purpose which empowers the NSA. If I wanted to rule the world like the NSA, the propaganda strategy I would adopt is to widely publish news that links encryption use with an enemy.

That’s more than a bit fuzzy conceptually, but I expect you’re thinking broadly in the right direction. Personally I take these latest revelations from the In-Q-Tel stable at face value roughly to the same degree as I did the alleged AQAP rag — which was greeted by well-deserved incredulity on its first appearance. (Cupcake recipes, indeed!)

@Ray Dillinger “Al Quaeda is known to have good operational security, or it wouldn’t have taken nearly as long to find bin Laden as it did.”

Now, that’s a bit too cut and dried. How certain are we that we should be taking that entire kettle of fish at face value in the first place? Journalist Ray Baker, via his WhoWhatWhy organ (backed by a veritable Who’s Who of thoughtful media criticism in this US) has given a creditable rundown of the matter here.

“So presumably their people who do computer security are good at it.”
They’re as good as they’ve been trained — or facilitated — to be.

Thoth • May 14, 2014 11:54 PM

Everyone’s favourtie story:
Someone creates a new “secret” or open algorithm and wants a review. Write on slips of paper different commonly used attack methods and roll them up. Ask the creator to open any of the paper slips containing these attack methods and if their algorithm can’t stand up to any of the common attack vectors, it’s not gonna be a secure algorithm.

Those terrorist ain’t brilliant otherwise they would have just got themselves a copy of well known crypto library and use Serpent 256 if they want hardcore security and if they want a small and fast one, just stick to XTEA.

Even among common crypto, the ciphertext and keys are always expected to have a limited lifespan (to the point the algorithm gets broken or the keys are revealed). Being able to flexibly adapt to situations is always the best choice.

Honey Encryption (http://eprint.iacr.org/2014/155) seems to be an interesting research that makes it more difficult to tell if the decrypted ciphertext is a genuine one or a forged one.

Trying to grab a known crypto algorithm and adding stuff here and there

It is easy to plug in a portal device to internet cafes to do the encryption but that doesn’t mean the computers there shared by many people are not “in a healthy shape”.

Passwords have always been a key factor as key materials to generate subkeys and how many people could actually gotten password security correct ? Password and key distribution / use has always and will always be a big headache regardless if you use Serpent, Chacha, AES or whatever.

Thoth • May 15, 2014 12:01 AM

Was writing half way and accidentally hit submit:

Trying to grab a known crypto algorithm and adding stuff here and there may not always be a good choice. Recent ePrint publication (http://eprint.iacr.org/2014/315) discusses why not to simply add some XORs or ANDs onto an existing algorithm. Algorithm designs are rather rigid in the sense, if you tamper with the operational functions, you may get undesirable results. The best is to make another algorithm with similar design principles or just use existing ones. If you are about to add more rounds, make sure to stress test it with the rounds you want and make sure the ciphertext still looks random. I have seen scenarios where adding more rounds can be detrimental sometimes (my own experimental ciphers that are not well designed).

Nick P • May 15, 2014 12:15 AM

@ Thoth

If you want fast, I’d recommend Salsa20 instead. It comes from Bernstein who is brilliant and put US govt in their place during “crypto wars.” His NaCl library has that with a signing mechanism, each focusing on speed and immunity to side/timing channels. One could even reduce rounds a bit for more speed and still be quite safe far as current cryptanalysis shows.

Thoth • May 15, 2014 2:10 AM

@Nick P
Yes I was about to recommend Salsa20. Slipped my mind when I was writing the comments.

beta • May 15, 2014 3:02 AM

people tinkering with crypto will learn more about it eventually and better protect themselves and others, while there is that possibility of locking out yourself, people would make mistakes and learn, not in a hopeful way but actually doing it, now you would say i am over-expecting, over-correcting, but a win makes me exposed to all the praise and stuff that comes with it, while a loss makes me sulk in the corner and actually think and correct where i went wrong, not immediately but still it makes me learn about algorithms, encryption, ciphers in a way i could never appreciate otherwise, now don’t make out like to appreciate you have to go the “wrong way”, i see the wrong way as an evolution towards better compensating!

Jacob • May 15, 2014 5:45 AM

I think that we all look at this from the wrong angle, namely from a technologist-engineer-scientist POV. The question whether AQ’d own crypto is more or less secure than existing and well proven methods may be of secondary consideration in their ecosystem.

If those religous fanatics consider using anything created by Jews as sacrilege, then effectively they must develop their own crypto.

Clive Robinson • May 15, 2014 7:53 AM

@Anura,

Why use AES-CTR at all? Why not get data from /dev/urandom?

Ahh, I see we have a missunderstanding.

Firstly to answer your question it’s an effective stream cipher which enables it to work both for encryption and decryption, but more importantly makes it testable.

We are looking at my “just for fun” in two differing ways. My view is one of people developing new modes for various basic cipher components. After all ECB is generaly not considered secure for various reasons, neither for that matter is the XOR function.

However XOR is usually quoted as being the mixer function for a stream cipher, specificaly it’s usually –but incorrectly– given as the mixer function for the One Time Pad [1]. Thus the security in OTP systems is located in the Pad not the mixer function, and the same is true for stream ciphers, the security rests in the key stream generator which introduces a whole series of problems.

Thus what would happen if you used a more secure mixer function like AES in ECB mode, what security properties or advantages would it add or subtract in a stream cipher?

It’s thinking in this way that even crypto experts use when designing new modes for base cipher components and I feel we should encorage even novices to think that way from the outset. Rules when based on previous experiance should be repeatedly chalenged in the light of new experiance otherwise the field of endevour will become dead in the water.

[1] In practical Pad and pencil form the OTP mixer function is actually ADD with no carry not XOR. XOR was and is used in electromechanical and later electronic forms of the OTP which should be more correctly be called a One Time Tape system.

Jackson • May 15, 2014 8:17 AM

@Thoth et all

Thanks for the responses. And the link, Thoth. It is very interesting. but the problem demonstrated in the paper occurs when operations are added inside the algorithm, not before or after. It is certainly a useful warning.

But if simple xors and adds external to the algorithms hurt its security, the algorithm could not have been secure in the first place. Secure algorithms are not defeated by operations that run in linear time on number of bits.

minime • May 15, 2014 9:57 AM

Imagine you are sitting at the NSA and realize “damn, the people are too advanced in cryptography, we can not read as much stuff as we want” and then you ask your good friend jon “hey jon, what would you make stop using ?” and jon says “well, if you guys can read it, I will for sure search for alternatives”. and then you go out and tell everyone “hey, I am from the NSA, we can read your super secure encryption”….

g3i5uhg3i5gu • May 15, 2014 1:18 PM

@Andrew Wallace: Yeah, by using messengers they could avoid all the US military that are still there plus the digital and analog surveillance. The only thing they’d have a problem with is all the selective satellite surveillance..

They’d actually be better off using custom encrypted radio, but military probably have spectrum monitoring set up there and it’ll still end up with NSA and army intelligence..

I know there are some highly educated people in AQ, but I doubt they’d make a solid encryption cipher, or secure software to handle keys and messages.. But it’s also kind of idiotic to suggest they use US government approved ciphers like AES..

flanders • May 15, 2014 3:18 PM

Al Quaeda is known to have good operational security, or it wouldn’t have taken nearly as long to find the target as it did.

The argument against this opinion is Pakistan was protecting him. Additional evidence supporting the idea that the target was protected was the house he was living was the opposite of a a safe house with multiple exits and whatever else would be fashioned for a high-risk target. There’s a recent book about it that covers Pakistan’s motivations and other details.

The Fallacy of Accent’s post is relevant and interesting.

Thoth • May 15, 2014 8:35 PM

Thanks for the reply, @Jackson. It is always useful to write your own ciphers for fun so you understand the inner workings of ciphers as long as you dont use some homebrew crypto without proper reviews for serious stuff you want to protect.

KnowitAll • May 15, 2014 9:24 PM

I am little bit fuzzy about “Good” and “Bad” Ciphers. What is (are) the measure(s) used to judge security before the cipher is actually and publically broken.

All previous “competitions” were mostly based on performance measures. With the continued advances in processor design and increased memory capacity and lower cost per bit stored, these performance measures became rather academic.

I think we should always keep in mind that Encryption is an art before it is a pure science and it will remain this way for sometime in the foreseen future.

Nick P • May 15, 2014 9:25 PM

re Don’t write your own ciphers

re Schneier’s rule of “anyone can design a cryptosystem they can’t break”

My attempt to beat the rule

Alright, my turn at one. My cryptosystem is a cascading design that encrypts the plaintext with three passes:

  1. XOR’s it with a series of 0’s
  2. Further scramble it by applying ROT47 cipher
  3. Use a one time pad on the result.

The pads are to be delivered in person or by trusted, armed intermediary using tamper-evident packages. There exists a mathematical proof somewhere that my cryptosystem is provably secure against an effort to crack the ciphertext. So, does this amateur first attempt sound like it might work? Or am I the only guy who can’t break it? (evil laughter)

Thoth • May 15, 2014 10:02 PM

OTPs if generated properly and keys are used strictly once would be a good thing for any system relying on the security of OTPs. Truth is not every one is good at obeying the rules of OTPs. So the first thing to break is the OTP. I would assume the OTP would be broken into 3 parts for each pass and are operated as stream cipher ?

Anyone else interested in creating ciphers besides Nick P down here ?

I wonder how secure/insecure are the ciphers we can just create.

Nick P • May 15, 2014 11:25 PM

Well the last one was a joke. My first real one was a triple encryption by several good ciphers, either in same or diff modes. Later, I came up with a polymorphic cipher where the key exchange includes what randomly chosen ciphers to use, but on outside the results look the same. Each primitive is strong. Ive seen no evidence anything better was needed as the first scheme is still very strong and endpoints+protocols were weakest link.

So began my focus on that. Nothing has changed since then so most energy stays on that. 😉

Wael • May 15, 2014 11:49 PM

@ Nick P,

Alright, my turn at one. My cryptosystem is a cascading design that encrypts the plaintext with three passes:
1. XOR’s it with a series of 0’s
2. Further scramble it by applying ROT47 cipher
3. Use a one time pad on the result.

1- What’s the purpose of the first pass ? It leaves the input unchanged?
2- The second ?
3- If you are going to apply a one time pad to the output, what do 1 and 2 d o?I hear your evil laugh, so there must be a hidden thing I missed…

Wael • May 15, 2014 11:53 PM

@Nick P,

Well the last one was a joke…

And my cipher will not use keys. The keys are extracted from the noise of the channel 😉 Remember this one?

Andrew • May 16, 2014 1:10 AM

I think somethink like this is good enough for everybody:
-Encrypt your data with any public algo you think is safe but remember that during this process you may lose the key. Public encryption libraries may be already compromised even if the alghoritm is safe.
-Encrypt the result with a custom, unknown, personal algorithm, with a different key.
– just respect all decent procedure related to a safe OS, air-gapping, other ways to bypass/trick possible hardware backdoors.
I would add one more, a 32 bytes key is easier to by wired/airborn without noticing than a dvd size key. A password combined with such key would be an interesting combination.

Anura • May 16, 2014 2:10 AM

I did write a nonlinear transformation over the weekend for use as a component in a stream cipher, block cipher, hash function, and sponge function/PRNG that I talked about in the last squid post.

http://pastebin.com/RCim9AZG

Rotations are powers of prime numbers mod 64 (could probably choose better rotations) and constants are from the hex portion of pi. I figure the block cipher would be 12 rounds with each round being a call to that function (based purely on the intuition that 3 rounds would be the bare minimum to be resistant to cryptanalysis, given one round is the minimum for diffusion), with key mixing before and after every call using XOR, and the key schedule generated by the sponge function, which should give you over 1 Gbps of throughput on a fairly recent system.

Haven’t bothered actually writing the functions to use it, since now I’m starting a non-crypto project, which I could actually publish and use. For crypto, I may make the cipher I described above using AES, ChaCha20, Serpent, Threefish, and Twofish, with the addition of XSalsa20 to encrypt just the plaintext before the rest. I will call it RDQLS47: For when you absolutely have to waste every bit of room.

Michael • May 16, 2014 8:45 AM

This is such nonsense, all one has to do is to use Serpent – that’s right serpent. Forget about AES. Any Computer Science major should be able to get a library like Crypto++ and write a small app that use the Serpent cypher from it to encrypt data. After a little bit of testing, it can be shown that the data produced is properly encrypted (i.e., by virtue of the fact that it can be decrypted).

Bottom line, in about a day, just about any Computer Science major in the world can write a working application for encryption/decryption that uses probably the most secure cypher known to date and it isn’t even AES.

Nick P • May 16, 2014 12:10 PM

@ Wael

The purpose of 1 and 2 is to make it different enough from One Time Pad to pretend I invented something. The OTP is what provides actual security. The joke in the joke is that each of 1 and 2 are the worst constructions in cryptography often used as an insult to poor designs. “He just XORed it” “What a ROT13 knockoff!” So, I designed a three pass cryptosystem that uses the worst things in cryptography & is still provably secure. :O

“And my cipher will not use keys. The keys are extracted from the noise of the channel 😉 Remember this one?”

Sadly several come to mind. It’s starting to become a recurring theme. Funny thing is NSA vacuums up all data on channels and their competitors oversees are trying to do the same. So, tying your security to an aspect of the channel is a FAIL. That competing solutions can distrust the channel entirely throws in some extra FAIL. 😉

Anura • May 16, 2014 3:22 PM

You know, there are plenty of “Well, I can’t break this” encryption algorithms available, so I think I’ll release my own encryption suite, using known secure algorihms in high level protocols deisgned specifically so that I can prove that no one can break it but me.

Thoth • May 16, 2014 8:48 PM

I think rather than putting it as “cannot be broken”, the better way to put it is “cannot be broken now”. Encryption simply makes it more difficult to get the plaintext at the current moment but not 5 years or 10 years down the road when someone discovered a way to break all rounds of Serpent trivially (if they are that good to discover it) sooner or later. What is most important is cipher mobility. If one breaks, another one quickly gets into position. This is where cipher cascades comes into use.

@Michael
Data are encrypted and protected against known cryptanalysis methods. If by your definition that data are properly encrypted by virtue it can be decrypted, any weak ciphers or encodings can fall into such categories.

All ciphers have their own weakness. It is impossible to create the perfect cipher unless you can generate true randomness and one time use of secret materials. That said, I do agree Serpent is a very strong cipher and I personally think highly about it and recommend it if someone needs that level of protection.

Anyone can pick up a crypto library and call it’s methods. But not knowing how the cipher works is what’s going on out there with all those badly implemented cryto products. Anyone may simply call Cipher.doFinal(); and expect something to occur. I have seen cases normal programmers not knowing proper PKCS paddings, whether to use PBE or not and whole load of other considerations. There are also poor implementations like not wiping secret keys after use from memory and poor programming practices. Picking a library up and start calling methods is the easy part. Properly deploying it with good knowledge and careful consideration is the deciding factor whether someone must attack the algorithm of the crypto or attack the programming codes that are badly implemented.

Chris Abbott • May 18, 2014 9:27 PM

@Thoth

I may have mentioned this before, but IMHO, NIST should have multiple standards other than just Rijndael. This would make a good fail-well system. Every cipher will eventually be broken someday, so if one falls we would have the mobility you mentioned.

mijaw • May 19, 2014 5:46 AM

they are young al qaeda members, older ones don’t use any kind of telecommunication.

Thoth • May 19, 2014 9:59 PM

@Chris Abbott
That is a good idea to have multiple algorithms just in case. Cipher cascading should provide that kind of failsafe. If NIST doesn’t specify, we can (as a community) start to debate on how to draft good failsafe options.

Clive Robinson • May 20, 2014 12:25 AM

@Thoth, @Chris Abbott,

Whilst I agree we need multiple crypto algorithms (and have been saying so for many years), it is not enough by a long way.

You also need an entire framework of standards to turn the algorithms into working and reliable systems that can interwork with other systems without breaking if you swap an algorithm.

Put it this way for various reasons crypto algorithms are very different some are block ciphers some stream, they have different widths for plain/cipher text and key sizes. Thus you need a set of standard protocols to map the differences (think about the issue with type conversion in programing languages for a similar but considerably less exacting issue). Then there are the “modes” ciphers are used in which can turn block ciphers to stream ciphers or hashes add authentication replay prevention and a whole host of other useful functionality.

Basicaly there is one heck of a lot to consider at the various layers of the networking stack such that what goes in at the application layer makes it down the sending stack and back up the receiving stack and pop out correctly despite any changes in the crypto stack.

Thus as I’ve said for many years NIST should be putting their minds to use on framework standards rather than “winner take all” crypto competitions.

To give you an idea of how silly the NIST aproach is it is like holding a contest for the “Best Fastener” which will replace all nails, screws, rivets, glues, bolts etc with just one that will only come in three sizes and one strength…

Mr. Pragma • May 20, 2014 1:00 AM

Clive Robinson (May 20, 2014 12:25 AM)

Whilst I agree we need multiple crypto algorithms (and have been saying so for many years), it is not enough by a long way.

You are damn right.

For those, however, who still didn’t get the message I strongly encourage them to read P. Gutmann. He has a simple but striking message: Pretty nobody breaks encryption (probably not even lousy encryption); they simply go around it.

Now, while I’m not naive enough to comfortably believe that openssl is so extremely lousy crafted by mere happenstance (unless one calls nsa & friends “happenstance”), I’m neither naive enough to believe that openssl is so full of crap only because nsa wanted it that way.

And even if so, C lends itself very well to crap-production.

Either the “millions of eyes” (foss credo) didn’t see any problems (or didn’t look at all in the first place. But then, we don’t want to call out foss fairy tales or religious beliefs, do we?) or they saw problems that were so utterly ugly – in major part due to C being used at all and on top of it very, uhm, creatively – that their urge to “unsee” the crap and to run away was uncontrollable.

And again, the message is the same. C lends itself very well to crap-production.

And we’re back at P. Gutmann. How do they circumvent whatever crypto protection is used? Hint: The answer, at least in shockingly many cases, is to do with C/C++/java,go, …

Our problem isn’t crypto. Even nsa tainted crypto is a medium problem quite well manageable. Our problem is implementation. Unfortunately hundreds of millions of loc.

If anyone needs another hint: AFAIK the libreSSL (OpenBSD) guys who are working in shifts to save our a**es did ask the linucks foundation for funds but didn’t get a yes, let alone any funds so far.

yesme • May 20, 2014 2:30 AM

@Clive Robinson

Sorry, but you are not entirely right with blaming who/what. It’s the spec.

We are talking about a secure layer. How hard can that be?

Well, if you design it by a committee, you end up with ssl/tls. And you need Snowden to point that out.

The problem with committees is that they can be influenced. The OOXML ISO standardization process is a perfect example. MS just hires lots of lawyers / spinners and they go to these ISO process meetings. Just enough to have a majority. And after the voting is done, the lawyers / spinners go home, never to go back again. Big Corp wins. Or to be more direct, money wins.

And while doing that they make the world a bit more worse.

Big Corp (and other parties with deep pockets) is the doom for committees. In fact, people leave committees for that reason.

On the other hand if you would have designed it by a dedicated team of professionals you would probably get something that is both simple and extendable, that really acted as an independed secure layer and that would have resulted in an implementation with max 10% of the code of OpenSSL (300.000 LOC).

That said, and talking about which programming language to blame. It is C (and C++). Nothing more, nothing less.

Btw, the biggest problem that the LibreSSL devs are facing now (after the initial removal of all the crap) is the API. It turns out that the OpenSSL API has just too much exposed. Now the LS guys are looking at what can be removed from the API without creating collateral damage for the ports collection apps.

yesme • May 20, 2014 2:37 AM

Sorry, my last post should have been addressed to Mr. Pragma instead of Clive Robinson.

Mr. Pragma • May 20, 2014 4:32 AM

yesme

You are right. That (committees, in particular the way they are and work) are a major component of the problem, too.

But now assume that someone were independent of fips (like, in fact, most users actually are). If an error was found, even a big one like heartbleed, it could be fixed within days if not hours.

The way things are, however, it’s a major, painful, and long process to fix things (just ask the libreSSL guys).
Similarly the fact that errors aren’t found for months or even years is not a committee problem. It’s a problem related to C/C++/java/go, etc.

“Funnily” those problems are very closely related to those of normal code maintenance. “Readability” is one magic key. Modularity is another. As it just so happens those two are classical weaknesses of C/C++ etc.

If openssl code were readable, Bob Beck from OpenBSD wouldn’t have to “confess” The code was too horrible. Nobody wanted to work with it. … Those of us that looked just hoped the upstream could deal with it. We are all guilty.

And that from a very grown up and experienced C developer!

Some of the sins discovered: memory not freed or even freed memory happily reused.

Actually he states that openssl code could not even be checked!
(Valgrind, Coverity, etc.)

Some major bugs have been in there, in some cases even flagged but ignored, for YEARS.

Yes, committees are a bad way to develop, design, and decide standards. Yes the relevant committees are guilty of pretty every sin, failure, and fu**up possible, incl. intentionally and/or knowingly watering down security – but all that could be relatively easily and quickly repaired or simply excluded from usage.

And again, crypto weakness is rarely a problem in the first place because it’s basically almost simply circumvented.

Now, we have 2 very major problems on the code side (because it’s lousy code that enables to simply go around crypto).

Add to that the 3rd code related problem, namely 100s of Mlocs in C/C++, etc. in virtually all TLS implementations, major libraries, operating systems, compilers, aso, aso.

In other words: One could de principe bring the 20 smartest and most trustworthy crypto guys into a hotel for a weekend and have a quite rich “basic” set of trustworthy crypto.
Bringing 20 of the smartest and most professional coders to a hotel for a weekend on the other hand would, no matter how well intentioned they were, hardly be a drop into an ocean.

Thoth • May 20, 2014 7:26 AM

If we have to put it this way in a very generalized context, security is not a single ended approach. Not a crypto problem, not a framework problem …etc.. When something breaks, it breaks on many levels. Cascading crypto and multi ciphers would be for the cipher layer. Good programming for the program language layer, netowrk protection for the networking layer and the list go on. Cryptography engineering book by Bruce made it clear that crypto have done more harm than good (quote Crypto Engineering book by Bruce) because crypto has always been thought as a magic bullet that solves everything when there truth is improper usage and multiple other factors brought us to where we are currently.

If I do see a ciphertext, I wouldn’t try to look it up on a table and break the cipher. I would just walk around it and look for other possible entries unless the ciphertext shows a huge probability of me being able to decrypt it in the first place.

Security is hard to get right with so much gimmicks out there :S .

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.