Unseen.is encryption claims revisited with their proprietary, patented "xAES" algorithm

Question

I had asked last year about the encryption claims by the web service called https://unseen.is. The very same service that had claims of "beyond army level encryption", "4096 bit keys" etc. This is the response from their support:

1. We don't use IKE v1 & v2, no signature too. Here is the way we exchange key:

The initiator generates a random ephemeral NTRU public/private key pair for the specified security strength. The initiator sends the NTRU public key to the responder. The responder generates a random secret s and encrypts it with the NTRU public key. The responder sends the encrypted secret to the initiator. The initiator decrypts it using the NTRU private key and extracts the secret s. Then both initiator and responder use the secret s to compute.

2. xAES (extended AES) is our patented encryption algorithm, based on AES, but has bigger key-size (maximum 8192 bits), much complexer & longer polynomial (in step MixColumn), using Gray-Sbox or Sbox flexibly (in step SubBytes), and some more security modifications (salt, key-expansion, etc...).

3. You can use Javascript debugger to view incoming message and outgoing message and check the message payload to see the encryption text. This is truly end-to-end encryption inside SSL tunnel.

---

UPDATE: 8th October 2015

xAES is a expenontial difficult level to break from base of AES. AES has limit > of 265bits keysize, where xAES has been developed to overcome all AES limitation. For xAES we can have a size of 16kbit (~2^64 times AES), which will be extremely diffulty even if one uses quantum computer to break it.

---

What do you encryption specialist think of this response and especially how would you rate the "xAES", their proprietary and "patented" encryption algorithm? What is the value for user to go put their communications behind a service that has in use a "patented proprietary encryption" out of which at least I have not found any trace from 3rd parties it would have undergone any checks or tests, anything.

UPDATE: 7th March 2018

The patent is number 20160142208 and is titled MULTI-DIMENSIONAL ENCRYPTION.

Answer 1

From what you describe, what they do is that they tunnel data in some SSL (this is reasonable) but add an extra encryption layer in Javascript (this is not reasonable). The whole reasoning is faulty. Indeed, either the SSL ensures security of transmissions, in which case the extra layer is simply useless; or the SSL does not ensure security of transmission, and then attackers can modify the sent Javascript code, thereby nullifying any security gain that could be hoped to be obtained from that extra encryption.

In practical terms, if the SSL is not enough, then you are already doomed. There are basically two ways in which a SSL connection can be intercepted:

• The attacker could plant in the client machine an extra root CA certificate under his control; then he runs a Man-in-the-Middle attack by generating on-the-fly a fake certificate for the server, signed with the attacker-controlled CA. This method is commonly applied in some big organizations, using products such as Blue Coat's ProxySG appliance.

• The attacker could plant some software in the client machine that hooks into the SSL libraries used by the client browser, and reads data directly from the source, before it gets encrypted (or after it gets decrypted, for incoming data).

The first method is what nosy but honest sysadmins do; it scales well and is robust against browser upgrades. It is also less discreet than the second method, since the user can always click on the padlock icon, have a look at the apparent server certificate chain, and notice the extra root CA.

Both methods require the same kind of initial access to the client machine, so if an attacker could use one then he could just as well use the other one, and you would be none the wiser. In simpler words: if the SSL is not enough then your machine was compromised and resistance is futile. Whoever could break through the SSL could also, and probably more easily, simply plant a key logger on the machine and don't even bother with the SSL any more.

---

The "xAES" thing deserves its own section.

First, there is no such thing as a "patented proprietary algorithm". A patent is a publication and that is even its raison d'être. Patents are a deal by which an invention is published, in exchange of a temporary monopoly for its usage. The whole idea was to prevent inventions from being lost because the inventor relied on secrecy, and then died. Whether patents "work" for software is an open (and acrimonious) debate, but the basic property remains: that which is patented is also published, by definition.

Therefore, if the algorithm is really patented, then a patent should exist and they should be able to send you a reference to it (the patent number). But without any reference, one has to assume that the patent may be inexistent, which would imply that they are lying to you (a great way to build trust).

Now let's see some details. AES is an algorithm with a precise definition, built over some elementary components of an algebraic nature. The interactions between these components have been studied at length in the last 15 years, and the overwhelming consensus on the subject is that these things are subtle, and it is not easy to make sure that any given definition ensures the appropriate level of security. Thus, any single change can be highly detrimental to security, and there is no obvious way to detect such an occurrence.

The notion of using a "much complexer & longer polynomial (in step MixColumn)" does not make sense. That step is defined in the AES standard to correspond to a multiplication of a column, taken as a polynomial in GF(256)[X], by a constant polynomial P, modulo a specific degree 4 polynomial M. Since there are four bytes in a column, M can only have degree 4; there is no other choice; and since the operation is done modulo M, then the degree of P cannot exceed 3. Thus, using a "longer polynomial" is meaningless.

(Or, maybe worse, they do multiply with a polynomial P' with a much larger degree, without realising that this is equivalent to multiplying with a polynomial of degree 3 or less when done modulo M.)

The role of the MixColumns transformation in AES is to ensure some avalanche effect. A simplistic view would be that "more avalanche" is better, but that would first require that the standard MixColumns is defective in that respect, which is an unsubstantiated assertion. Moreover, a stronger avalanche effect does not actually correlate with the polynomial seeming "more complex" in the eyes of a human being.

The 8192-bit key size is, of course, highly laughable. 128 bits are already enough and there are strong reasons for that. Key size is not a weakness in symmetric cryptographic algorithms; it used to be a weakness back when Disco was a novelty, because there were some widespread algorithms with really short keys (in particular DES). But things have changed, and symmetric keys were expanded to be safe from brute force attacks, not only from existing hardware, but also from hardware which will be invented in the foreseeable future.

When someone says "I use 8192-bit symmetric keys", what I hear is: "I have no idea what cryptography is, but I really love big numbers".

Last but not least, a common theme in cryptographic research of the last decade is that side-channel attacks are a possible concern, and should be taken care of in the implementation of cryptographic algorithms. There has been a lot of research on that subject, in particular optimized circuit-based descriptions of the AES S-box (e.g. this one) to promote constant-time bitslice implementations. By modifying algorithm elements, they simply forfeit all that research.

---

Summary: I would recommend avoiding this product, because:

• They make claims which are not backed up, or make no sense (e.g. a patented algorithm which is also kept secret).
• If they really do what they claim, then they basically destroyed all attempts at external review, which is a problem because all the security in a cryptographic algorithm comes from external review.
• The security model does not hold up; or rather, they don't describe any security model where all their extra custom crypto would have any tangible effect on security.
• The description of the cryptographic algorithm is full of buzzwords that are usually correlated with an utter lack of cryptographic skills.
• In any case, all of this boils down to: you send your precious data to these people, and you have no way to know what they do with it. All the crypto talks are about the security in transit but the real weaknesses are always at the endpoints. In their Web site, they address that concern with a generic "we are based in Iceland". How exactly living on top of active volcanoes or having a thriving fishing industry are supposed to improve data security, is kept untold.

Answer 2

Without a proper cryptoanalysis there's not much to say definitely, but this sounds a lot of alarm bells.

First, the key exchange algorithm. The secret is never sent in the clear, which is good, but it is send via the network, which is bad. There are ways for both parties to share a secret that is never sent via the network, in any way. See e.g. Diffie-Hellman. Or it's version using Elliptic curves. Good thing they use an ephemeral key, but do they have any protection against MITM attacks?

Second, the communications key. It appears it's generated by client. And is dependent on the client's pseudo-random number generator. Computers are bad at generating random numbers, and javascript (having noharder access to the OS which can gather some entropy) is even worse. So, the key to communications depends only on one, possibly poor pseudo-random number generator. Bad, it could depend on both client and server.

Third, the xAES. While it's possible that they've made some improvements to it, it's not probable. Much more probable is that they've slightly disturbed the needed interactions between the phases, making the outcome much less secure. There are many such attempts in the wild, and most of them are considerably worse than original (a.k.a. crackable immediately).

Fourth, the xAES key length. This one merits it's own paragraph. While it is generally true that more is better for the key size, the 8192 key size for this sounds unreasonable. Such key sizes are common for the asymmetrical algorithms, which need much longer key sizes (see e.g. https://crypto.stackexchange.com/questions/6236/why-does-the-recommended-key-size-between-symmetric-and-asymmetric-encryption-di) (due to the fact that the public and private keys are interconnected), not for symmetric ones. Having a key that is more than 10x longer than commonly used keys? Sounds fishy. Or like Let's make the folks believe we use correct key length values, because the number 8192 shows up often as keysize. Only it's not that keysize.

Overall: No concrete proof, but I'd consider it snake-oil.

---

After question update:

I have no knowledge of US Patent System and I have no desire to learn anything (I'm not from US and have yet to see when any patent did any good). I'm also not a cryptography expert, although I do know more than the average guy, having even some academic exposure and sort of a hobby.

Every serious cryptography book/course/whatever warns you from proprietary, unreviewed crypto algorithms, and for a good reason: It's very easy to make small mistakes that make the system entirely insecure. Only way to ensure it's more secure then the next one is to have a lot of independent review, and a lot of cryptographers trying to break it. If there's a lot of publications that tried to think of something for that algorithm, but with no real success, than we can be pretty sure this algorithm is secure. the xAES algorithm as far as you say has no such review. This does not say it's not secure. It does say that no one bothered to check it's secure. It might be as secure as AES, it may be more secure, it may be less secure than a CAESAR cipher, it may have a backdoor that allows to read everything if you know it. While there are unreviewed algorithms that are secure (AES was an unreviewed algorithm at some point in time), the odds are pretty much against it.

The fact that we know nothing of the authors of it doesn't help. Of course there's no guarantee that a known name will come up with a good algorithms, the chances are bigger, because those guys know about why those thousands of algorithms were not secure. From someone with no publication record? From someone anonymous? It could be good, but it's just a wild guess.

TL;DR: Without having the algorithm and some proficient guys spend some time cracking it, it's a wild guess. This is security, we don't believe in wild guesses.

And we get to the key length again. I can't add anything new to it. Except that it gets better - previously they claimed a key of 8kbit, now 16kbit. Funny, a few days and the maximum used key is doubled? Is this a fixed algorithm, or are they just updating it as we speak? Again, the key of that size (whether 8- or 16- kbit) is just unreasonable for symmetric algorithm. To compare: My browser has a lot of security certificates installed. These are from various CAs. Most of those have a 2048 key. 4x smaller than the first figure for xAES key size. And we are talking here about asymmetric keys, which tend to be at least 10 times larger then the corresponding symmetric keys (xAES) is a symmetric key. The tell you: the community believes reasonable size is x. We tell you we have 32x and show no reason why we believe x is not enough. And now we have 64x with even less reason.

Either 256 bit keys are secure, and having 32 times larger keys is just a waste of resources, or they have a reason to believe it's not, in which case I'd like to see that reason. Larger keysize won't get us far with quantum cryptography, it's an entirely different beast (imagine a machine that tries all keys at once, sort of a multitude of parallel universes with the correct one becoming reality).

Finally, let's return to their quotes and analyse it a bit:

xAES is a expenontial difficult level to break from base of AES.

If you take 2 times larger key, and assume the algorithm is secure, you have 2 times harder algorithm. So yes, if you have exponentially larger key, you have exponentially harder cipher. Sort of makes sense. However I'd like to see the proof of the assume the algorithm is secure part.

AES has limit > of 265bits keysize, where xAES has been developed to overcome all AES limitation.

I assume the 265 bits is a typo, AES uses 128, 192 or 256 bit keys.

For xAES we can have a size of 16kbit (~2⁶⁴ times AES),

Explain to me how 16384 is 2⁶⁴ TIMES more than 256? 16384/256=64. The key is 64 times larger. The keyspace (number of possible keys) is 2⁶⁴ times larger. This is confusing terms.

which will be extremely difficult even if one uses quantum computer to break it.

See above.

xAES (extended AES) is our patented encryption algorithm, based on AES, but has bigger key-size (maximum 8192 bits), much complexer & longer polynomial (in step MixColumn), using Gray-Sbox or Sbox flexibly (in step SubBytes),

Not much to add to Thomas Pornin's answer. But: What is a much more complex polynomial? Polynomials are simple. Longer polynomials are just longer, not more complex. You could say that 100000 is more complex than 100.

and some more security modifications (salt, key-expansion, etc...).

Pretty easy to make a security modification that reduces security and very hard to have a security modification that increases security. There are a lot of very subtle interconnections. You can make a gear in a machine run twice as fast, but it will then wreck havoc in a machine where all other gears run at previous speed.

Salt: Random, usually not secret, data used for one-way function ("hashes"). See https://en.wikipedia.org/wiki/Salt_(cryptography). Could be understood as padding, which is adding (random or deterministic) data to either fill blocks or increase 'randomness' of message. Not part of a symmetric cipher, but of it's way of use.

key-expansion: a process of having a smaller key and producing a larger key or key set from it, with various properties as needed. The process of generating keys for subsequent rounds of symmetric cipher is sometimes called that (as we are expanding the key into several subkeys used in rounds), so AES already has this.

Oh look, we stuff in some fancy crypto-jargon. Too bad from a different context.

It looks that their CEO has no idea what he's talking about. And he sounds that more and more with each answer. No gaining points here.

Let me quote Phill Zimmermann, the guy that wrote PGP:

Anyone who thinks they have devised an unbreakable encryption scheme either is an incredibly rare genius or is naive and inexperienced. Unfortunately, I sometimes have to deal with would-be cryptographers who want to make "improvements" to PGP by adding encryption algorithms of their own design.

I remember a conversation in 1991 with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That made a lot of sense. I observed that practically no one in the commercial world of cryptography qualifies under this criterion. "Yes," he said with a self-assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either.

https://www.philzimmermann.com/EN/essays/SnakeOil.html

Lets's see Bruce Schneier's checklist for snake oil: https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil. In my opinion points 1, 3, 4, 5 and 7 fit perfectly. That's 5 out of 9.