Dynamic Encryption for Voice

This article reads like snake oil. But the company was founded by Lars Knudsen, so it can't possibly be.

I'm curious.

Posted on October 10, 2014 at 3:07 AM • 35 Comments

Comments

GuestOctober 10, 2014 3:40 AM

Either the article got it all wrong or it really is snake oil.

After all, ciphers are based on the principle of choosing from some subset of algorithms for transforming plaintext blocks into ciphertext blocks and vice versa, while not disclosing to anyone which algorithm you picked. Having a strong cipher is all about which set of algorithms to choose from, so as to make it hard to figure out which one exactly was picked. The encryption key specifies which algorithm from the set to be used.

So dynamic encryption is just a way to make the specification of the set more complex. But what can the purpose of that be? All it does is add inefficiency and it makes the system harder to analyze and understand, which is to say, easier to miss weaknesses. It is diametral to the basic principles of cipher design. It's exactly what you would not do as a prudent cryptosystem engineer.

GuestOctober 10, 2014 4:04 AM

Adding to what I said above, it might be possible that K has some strong proof saying if he does X in addition to AES, what he gets is always at least as strong as AES in all respects.

Then it might arguably be a good thing to do X, if it makes it harder in practice to use brute force.

Though one has to be extremely careful for X not to have any unexpected side-effects in practice that might make breakable easily what is secure in theory.

And of course, the question is obvious, did he publish a paper on his method, or at least disclose it?

Steve BOctober 10, 2014 4:26 AM

It could be that it reads like snake oil because the author of the original article on the DTU website was trying to phrase it in such a way as to enhance the chance of it being be picked up and used by non-specialist journalists.

This perception highlights the problem of setting the right level when communicating the nuances of complex subjects such as cryptography, medical research or even climate research to non-specialist audiences. In the context of the need and desire for research findings and publications to be taken up and communicated ever more widely in order to help ensure future funding support, this is clearly a recipe for trouble.

Whereas it used to be that publications such as the British 'red-top' newspapers could be branded as the worst for misinterpreting or misusing research findings and announcement (deliberately or not, or in the pursuit of sensational headlines) this problem has spread to the more traditional newspapers. It even appears to be spreading inexorably to the most reputable and trusted publications such that either through inadvertent negligence, the pressure of ever increasing volumes of submissions or even basic commercial factors, they may no longer be able to meet the standards they set in the past.

The problem is, however, not the journalists, the publishers, or even the original researchers and authors. It is that the gaps in understanding are getting wider at the same time as general educational standards are falling behind. With the concepts of rigour, precision, clarity, and breadth of understanding all taking a back seat to societal 'needs' for inclusivity and equality, it is hardly surprising that we are where we are.

Karl KoscherOctober 10, 2014 4:58 AM

It's possible that they just mean they're using a session key instead of a long-lived secret, or that they provide an additional layer of encryption (with session keys) on top of whatever the phone system is providing. It reminds me of the JackPair kickstarter.

Rasmus FaberOctober 10, 2014 5:17 AM

The patent is US 2014/0298013 A1:

Abstract:
Disclosed is a method of transmitting a data set using encryption, wherein the method comprises the steps of: selecting a first encryption technique, wherein said first encryption technique comprises a first encryption algorithm for encrypting plain data into cipher data, and a first decryption algorithm for on provision of a specific key, decrypting cipher data and reproduce plain data; encrypting the first data package comprising plain data, using a first encryption program implementing the first encryption algorithm of said first encryption technique, creating a first encrypted data package comprising cipher data; obtaining a first decryption program; and transmitting said first decryption program and said first encrypted data package to a receiver, wherein the first decryption, upon provision of the specific key and the first encrypted data package, will decrypt the cipher data in the first encrypted data package and reproduce the plain data of the first data package.

Sounds neither like a good idea nor patent-worthy (using the encryption method as part of the key seems to be one of the first bad ideas that anyone - including me - comes up with when they start studying cryptography). But there might be a good idea hidden in there somewhere. I have a fair bit of respect for Lars Knudsen, so I would be surprised if there wasn't something that I overlooked.

MartinOctober 10, 2014 6:27 AM

Intriguing. Absolutely fascinating.

So, you're not sure how it works but there must be something wrong with it and deserving of shame...because it is different - which of course is forbidden.

Do you realize this exactly characterizes a field JUST before enormous changes take place?

VanceOctober 10, 2014 7:22 AM

@Martin

Grand and novel claims that cannot be immediately verified also exactly characterize every snake-oil pitch since the beginning of time. Of the two alternatives, guess which happens more frequently?

Jesse ShapiroOctober 10, 2014 8:12 AM

Reading the patent, it almost sounds like it's using public-key crypto to exchange a symmetric key. Isn't that what Diffie-Hellman is for?

Additionally, the article talks about how "hard" public key encryption is, but haven't hardware vendors recently started adding hardware acceleration?

DonaldOctober 10, 2014 10:05 AM

@Martin

I thought everyone was being pretty fair. Comments from Bruce on down seem to be "This sounds fishy BUT, we need more info because there MIGHT be something to it"

KyleOctober 10, 2014 10:15 AM

Wow. That article could not have come across as any fishier. That site appears to be a real news outlet; if so, they need a new editor and site design...

TJ WilliamsOctober 10, 2014 10:21 AM

The way I understand it is that LRK has added rounds to the AES to go, say, up to 20 instead of 14. If this is well done, it can only improve AES against some attacks, e.g., algebraic cryptanalysis, and LRK would not be the first one to consider that. The added rounds may differ from one conversation to another and there are several way to do so.

Now, I am a bit skeptical about:
"And even if the conversation is encrypted -- in principle -- it is still possible to decrypt it provided you have sufficient computer power," he says. This is in no small part due to the fact that the vast majority of telecommunications operators use the same encryption algorithm -- the so-called AES, the outcome of a competition launched by the US government in 1997".

This statement is at best not accurate.

TJ

Nick POctober 10, 2014 10:22 AM

@ Thoth

Here is my comment describing my polymorphic cipher. I made a variant of it years before in response to a snake oil company's claims. Then, they adopted a version of it and blended in some extra snake oil. Lol...

Clive RobinsonOctober 10, 2014 10:28 AM

The Patent is horrible to read and gives the impression of being writen by Google Translate, so I've only had a skim read of it so far.

However if I read it correctly --which I have little certainty of-- the invention is to make an encryption program randomly, execut it on the data to encrypt the data, then send the ciphertext and executable to the recipient...

The patent talks of a hundred, a thousand and a million encryption programs, and selecting a programing language the recipient can compile on their system if they won't accept an executable. It's not clear if this code/executable is to be encrypted or not. One part of the patent aludes to that whilst another talks about not sending keys....

The patent further talks about the attacker having to first work out what the encryption program does as this --very minor difficulty-- is stresed as an advantage or barrier to the attacker. However if the code is being sent as part of the communication which the patent also stresses then the difficulty for the attacker is the same as for the recipient...

Such things have been done already by polymorphic malware, so I don't as yet see any originality that would justify the granting of a patent.

I'm not sure if wasting any more of my spare time on it is justified even out of curiosity.

I suspect the author of the patent will read these comments fairly soon, so perhaps they would care to explain what they consider to be the original work in the patent.

Kent BorgOctober 10, 2014 10:38 AM

Voice encryption isn't so much at risk of the crypto being broken as "traffic analysis" of variable bit rate encoders showing amplitude modulation. No matter how you encrypt it. But without variable bit rate encoders I imagine quality goes down.

VBR + a little extra latency ?= big sound improvement + enormous information leakage.

-kb

Nick POctober 10, 2014 11:08 AM

@ Clive Robinson

If what you're saying is correct, it sounds just like PMC ciphers back when Bruce doghoused them. They've deleted all that content, but I found it here in Wayback Machine. Their new scheme is here. They also claim to have a European patent on "Compiled Polymorphic Encryption Algorithm."

So, this BS patent might be disputed by both prior art and very dedicated conmen waiving a patent drenched in snake oil.

@ Bruce Schneier

Their website in the second link has an advertisement:

"Earn money! Break it! Try to do it better than Bruce Schneier. Break polymorphic encryption."

Lol.

DaveOctober 10, 2014 11:23 AM

I have read many patents in my life and will never get that time back. Patent-ese is a blight on communications and understanding.

@Clive - malware as prior art. lol.

Sadly I seen patents pass with obvious prior art.

MartinOctober 10, 2014 11:39 AM

@Donald

Fair? Read Nick P's comment, then tell me again everyone is being fair.

First of all, everyone keeps calling it a patent, when it's a patent application. Second, did anyone even read the actual claims?

This so reminds me of the group at a university that, all they did was conduct research and then publish the results. They didn't even use the word 'unbreakable.' A pop news article appeared in which the research was poorly represented. Next, a reaction to the article appeared on this blog prompting a slanderous free-for-all. Every jackass self-described crypto genius on Earth repeated the same crap over and over. Best I could tell, they were all too lazy to even read the actual research. Snake Oil? Yeah, you can get it right here, all you want.

Quick, post something about squid.

WaelOctober 10, 2014 12:04 PM

Seems like a combination of Cryptography / Obfuscation controlled by some Device Fingerprinting parameters. I see this to add a minor barrier over standard crypto because the attacker will need to reverse engineer some code to understand the algorithm, how the Device Fingerprint affects the algorithm, etc... Then, for the "obscurity" part... How do we know that knowledge of the design internals doesn’t give the designer an edge over an outside attacker? These comments only focused on the "paper patent". In practice, there'll be other factors to consider such as malware sitting on the device, Big Brother software sitting deep in the bowels of the Phone Firmware -- below kernel level or, say, on a different processor handling the modem stack, or the DSP part. And, what’s to stop the phone from "electrically" having a microphone with two connections to DSP -- one that gets encrypted with the algorithm, and another that gets encrypted with a backdoor key, or sent in the clear?

Nick POctober 10, 2014 1:37 PM

@ Martin

The reason for the knee-jerk reaction here is that Bruce's readers were taught well that crypto algorithms are the strongest link: virtually every attack is on endpoints, implementations of algorithms, implementations of protocols, or protocol design itself. The algorithms themselves are rarely broken with existing ones looking plenty strong. So, yet another researcher patents a new crypto algorithm thing, turns it into a product, and will promote it on users telling them it makes them safer. It *doesn't*. There's research and products out there that potentially can or will. This kind of stuff is mostly a distraction from them solving an almost non-existent problem while providing buyers a false sense of security.

That said, I'll give it a thorough and fair (as possible) review. I say as possible because I've designed competing systems. I'll try to ensure fairness by focusing on the technical details of the product, then comparing them to existing points. I'll also do a risk analysis.

Nick POctober 10, 2014 2:05 PM

A preliminary security assessment of DTU's Double Encryption
(based on patent)

Let's give it a fair review. Here is the patent application from DTU. It's written in legalease like many patents so this is a preliminary review based on little information. Like Clive says, it also seems to have gone through Google Translate. Made abstract and many claims gibberish. Fortunately, the summary section does a *great* job explaining what it is:

"In accordance with this aspect of the invention, it is not necessary for the receiving apparatus to have, pre-installed, a suitable decryption application to match the encryption technique. It is not necessary for the recipient of the data to negotiate which encryption technique has been used, and there is no need for communication between the sender and receiver to identify the technique which will be used. The requirements for decrypting the data are entirely self- contained within the decryption program and there is no need for the permanent installation of a decryption application or an application including a decryption routine on the receiving apparatus. Of course, the decryption routine may need access to standard features of the operating system which will be running on the receiving apparatus. One of the initial steps may be to specify the operating system of the target receiving apparatus. A programming language for the program will be chosen that is compatible with the target operating system. A first encryption technique may be selected automatically without user selection. The sender has access to a plurality of encryption techniques and one of these is selected for a particular message. This could be a matter of personal choice by the sender, or could be in accordance with a set rota, or could be on a random basis. If the sender is not responsible for the choice of encryption technique, that task being left instead to software serving as an encryption management system, then the arrangement may be such that not even the sender knows which encryption technique has been used for any particular message. If an attacker intercepts a message transmitted in accordance with the invention, there is additional secrecy because the attacker must attempt to identify the decryption routine. Not until that has been done, could an attacker attempt to break the encryption technique. If the program is in the form of executable code, then there is the additional obstacle for an attacker that the executable code must be de-compiled into a higher language that can be understood, before attempting to identify the decryption routine. "

The system picks the initial cipher based on the key to create the starting session. This appears to be an obfuscated version of a TLS-like protocol. If it uses TLS, it's equivalent in security so long as algorithms and implementation are strong. If not TLS, protocol design & implementation must be solid too. The author adds an additional obfuscation layer by next generating a custom cryptosystem based on existing algorithms, then sends that to the recipient. So long as only safe interactions & constructions are allowed, this has benefit over relying on one algorithm. The cryptosystem can also be isolated from the application using it in such as way that even the app doesn't know the specifics, although not mandated. Then the author makes the actual security claim: the attacker must identify the custom-generated decryption routine for intercepted messages before cracking it. Author claims this requires decompilation and reverse engineering*.

* It mostly sounded good until he wrote that. From the descriptions, the key drives the whole process by algorithm, starting with one crypto algorithm. Getting the key or cracking the first [single algorithm] lets you decrypt the first session. That gives you the custom program sent over it. Then you use the same custom program to decrypt the rest of the traffic. So, whole scheme security is bounded at the first cipher used, the RNG, or system integrity. That means the security claim of the major innovation is already false. Although, the first part still has potential. Let's proceed.

Risk Assessment

1. They have 100 algorithms available. Any that becomes initial algorithm must be strong. I don't know 100 proven-strong algorithms, so this already concerns me. More on this in 3.

2. The initial protocol must be strong against all of the attacks on protocol design and implementation. This includes covert/side channels. Here be dragons.

3. The encryption algorithm generator must be free of defects and only produce safe constructions. As in, certain algorithms combined actually weaken security. These must either (a) not be available or (b) detected, then automatically remedied in a standardized way. This is a risk as the author just references all kinds of tricks for making variants of block and stream ciphers. Any variant might strengthen or weaken it.

4. Per the patent, No 3 must be true for numerous languages on numerous OS API's and interactions with them.

5. The receiver must verify the incoming code to be safe to execute. Essentially, this scheme runs off foreign code and has the security issues (eg bytecode verification, sandboxing) associated with that.

6. The code itself should have builtin protections against malicious data in case the sending machine gets compromised mid-session & tries to use custom routine to break integrity of receiver.

7. The generated code must be free of covert channels that leak plaintext or key material.

8. One must ensure the compiler doesn't optimize away the steps that wipe the keys or generated programs from memory.

9. The RNG must be a TRNG or CRNG with good seeding. Patent mentions PRNG. I really hope that was a bad translation as PRNG's have no business making keys.

Evaluation

If algorithms and protocols are solid, this does increase work of attacker if first algorithm is unbroken. But, if that's true, then you still get most of the benefit if you just use that one algorithm. So the rest is largely unnecessary. This scheme is a failure before the session even starts. An improvement would be to have both parties generate a custom encryption program immediately from the shared secret, which is never distributed. This cancels out the reduction of security above by overdependence on one cipher and places your trust in key exchange, which is already trusted here.

The bigger issue is trusting foreign code. If you don't have to, JUST DON'T! It's a whole field of research on how to do that so it's a huge risk increase. Plus, the best offerings in higher assurance field rely on static code. That includes secure hardware, transformations, and static analysis. A regular crypto system can be (has been) assured with these schemes. This one can't: you'd have to re-run the verification process during every session. Who wants to put money down that feature will be in the final product? Not me.

Note: So far it's a combo of a polymorphic cipher, a JIT, and a variant of the applet/Javascript model.

Performance is another issue. If they're using the strongest algorithms, there's a cost to setting them up and using them. Then, they have to compile a crypto system. Then they have to use bandwidth and time distributing that. A static polymorphic system has an initial setup cost, then that's it. Less time creating the session, negotiating things, transferring things, compiling things, etc. This cryptosystem is horrible on resources compared to static, simpler polyciphers.

Comparison to my own prior art. My polymorphic cipher used 1-3 algorithms in counter mode on a data stream. The choice of algorithms, their keys/nonces, the counter value, and initial iteration count on each counter were derived from the key. That was either a huge, PSK or a hash-based generation of material from a master secret. The algorithm only used the strongest known algorithms in a safe mode and construction. If a one algorithm solution (comparable to D.E. patent), it's performance impact is the setup cost to some crypto primitives with much of it saying in cache. There is no requirement to trust foreign code or generate/distribute code. Also, substantially less effort reviewing new code, side channels, etc as it's a simple combination of pre-evaluated components.

Conclusion

This cryptosystem is a bad idea. It combines a nice obfuscation (key-driven cipher selection) with a highly risky "JIT for cryptosystems" concept and relatively horrible efficiency. They'd be better off just getting keys to select from strongest algorithms or a combination of them. Of course, then it wouldn't be patentable because many of us have designed and published such schemes before. I advise users they're better off using a simpler, faster, data-driven, polycipher scheme instead of this risky, slower, code-driven scheme.

And remember that your solving the lowest risk part of security: attackers hit the endpoint and implementations often, rarely the crypto algorithms. They'll just hit you with a code injection, then bypass your crypto. So, the assurances provided by these schemes are false unless they're running on a system that can't be compromised or they plus GUI are separated from such a system. The mechanisms used must be highly assured to even stop non-goverment, sophisticated malware. The product will likely run on low assurance systems, so it has little to no benefit over field-proven crypto.

Even if it met its claims in practice, they'd be conning you if they told you that you needed it or it would protect your communications. Just like most of "security" industry's bogus claims. We need strong endpoint security, not more session encryption.

JeremyOctober 10, 2014 2:07 PM

For some reason, the discussion about sending executables to perform decryption at the recipient's end has reminded me of this:

https://www.schneier.com/blog/archives/2014/02/new_results_in.html

Somewhere in there was a mention of how, if we hypothetically had perfect software obfuscation, you could use that obfuscation as a perfect encryption algorithm by sending an obfuscated program that will output your plaintext message when fed the key as input but won't output anything useful for any other input.

Probably unrelated, but that was the only semi-reasonable proposal I could remember reading that involved sending an executable as part of an encryption algorithm.

JeremyOctober 10, 2014 2:19 PM

@Nick P

9. The RNG must be a TRNG or CRNG with good seeding. Patent mentions PRNG. I really hope that was a bad translation as PRNG's have no business making keys.

I was under the impression that "PRNG" stood for "pseudo-random number generator" and described any deterministic algorithm with output designed to look random, regardless of its security properties or how the algorithm works. Have I been misinformed?

Nick POctober 10, 2014 2:30 PM

@ Jeremy

They could have meant it that way as CPRNG's are a subset of PRNG's. As this makes clear, one wants to make sure they use the CPRNG's for any crypto work. The patent isn't clear but I said "I hope" to give them the benefit of the doubt. The two people involved are competent and DTU has plenty of good stuff* in their publications. That's where I got the patent number and application.

* FIDES seemed worthwhile, for instance. Along with plenty cryptanalysis.

DanielOctober 10, 2014 4:40 PM

@Nick P

It's it true though that which scheme you prefer depends on the nature of the attacker? As I understand the core strategy it's to "throw dust in the eyes" of the attacker. In essence, since the attacker doesn't know what is coming by the time he figures it out the call is over. So yes, foreign code would in fact increase risk in a static system but in a dynamic system it reduces risk. If you can't convince 'em, confuse 'em.

ShannonOctober 10, 2014 6:05 PM

@Martin

In the interest of disclosure, be advised that most who comment here regularly are opposed to the issuance of patents AT ALL and this may explain some of the venom you detected.

Nick POctober 10, 2014 7:03 PM

@ Shannon

That's a decent point to keep in mind in a lot of online forums (esp Slashdot). Most of us regular commenters are fine with patents so long as they're done for novel stuff and not predatory. My own critique with this patent application is that little of it is novel. The part that is has little security value, so my critique is there is on utility rather than patent eligibility.

@ Daniel

There's nothing wrong with the obfuscation strategy for reducing opponents' effectiveness. I use it extensively. The problem is how it is being applied. So, let's look at the nature of black hats and TLA's. They mostly dig through the binaries and source to find implementation flaws. Major TLA's regularly find 0-days in common software, use them to take over the machine, and directly have plaintext. They also look for configuration errors, fallback attacks on protocols, firmware issues, peripheral attacks, physical implants, etc. Lots of stuff to work on to keep communications private *in combination with* encryption.

The thing is, this is a solution in search of a problem. It's been a while since the choice of symmetric encryption algorithm doomed a system. I believe it was DES with keys that were too small. The 3DES solution appeared and solved that problem. Over time, we continued to get stronger and stronger algorithms. A few attackers used implementation or side channel attacks on the algorithm, which were remedied. The vast majority 99.999%+ bypassed the encryption entirely with endpoint, network, protocol and application level attacks. All the groups capable of potentially beating a crypto algorithm focus on that other stuff the most because it's easier.

There might eventually be an attack on the strong algorithms. It's understandable that people with long-term protection needs might do a polycipher with a rotating set of algorithms or a cascade of them. This can be done with a few, efficient algorithms. Pre-installed. Adding the risk and inefficiencies of foreign, JIT'd, variants of algorithms to further obfuscate something nobody even has a theoretical attack on just isn't justifiable. Those resources could be spent on one of the area that opponents are actually attacking.

Focusing on this stuff is the classic security problem: replacing an unpicked, strong lock on the front door with a stronger lock while the windows and backdoor are wide open. Better to lock down those windows and backdoor.

Chris AbbottOctober 10, 2014 7:10 PM

There has to be some kind of way for the incoming phone to know which algo to use. It simply couldn't work otherwise. To me, it seems like the mechanism in which that data is transmitted would be just as vulnerable. The only other thing would be if the phone could predict what cipher to use based on some kind of conditions, something somebody could reverse engineer or figure out based on observations. Even then, whatever those conditions are would have to be transmitted back and forth. I don't see how this could work.

Nick POctober 10, 2014 8:25 PM

@ Chris Abbott

It's built into the key exchange that I'm aware of. That's how most polyciphers, including mine, work. The key exchange problem remains. One critique I keep having is people going all out on symmetric cipher strength while using a regular asymmetric key exchange. Obvious issue: the public key algorithms are more likely to be broken than the symmetric. They get weaker every year with an impending "quantum apocalypse" on top of that.

The best place for cryptographers to put their effort in, other than cryptanalysis or efficiency improvements, is currently asymmetric and other crypto used for exchanges and signatures. These are most at risk. A massive effort by the cryptographic community should be put into place to do for them what's been doing in AES, eSTREAM, SHA-3, etc competitions. We need the replacement protocols with assurances ready *before* the current ones get cracked.

The symmetric algorithms are fine & basic polyciphers/obfuscations can make up for any weaknesses. This is evidenced by the leaks showing NSA has to bypass or subvert standard ciphers instead of crack them.

ThothOctober 10, 2014 10:21 PM

This pending patent seems to have a lot of places where it is unclear. Some stuff to expand on Nick P's point of endpoint security:

- Code injection / Deterministic codes / Bad code random
- Cipher selection - not a lot
- OS selection - Windows, Mac, Linux, Unix, BSD ... not too many unless you add distros
- Compilers - .Net, Java, GNU stuff, proprietary stuff...
- Languages - Java, .Net, C/C++, Python, Ruby, OCaml, Ada...

Any of these points weakens or breaks down, it's gone. Most of our telecommunications are cached and recorded (our beloved TLAs and ISPs). They could simply after-the-fact figure out the codes inside with their super machines. So what if the communications ended, they have a record of your key exchanges and they exflitrated some keys or session keys to make matters worse and that's all over as well.

Endpoint security is not doing very well and no the ciphers.

DaveKOctober 11, 2014 5:32 AM

Knudsen may not be a snake-oil merchant, but his definition of the words "free book" to mean "£39.99 from Springer" seems pretty wrong to me.

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.