NTRU crypto from unseen.is; myth busting help

Question

I am always on the look out for privacy enhancing technologies. I stumbled upon the service from unseen.is. I had a look at their site (specifically here) and even though I lack knowledge there are a few early warning signs:

a former security contractor told us "if it's publicly available, it's cracked"

I think this is untrue?

extremely strong but not widely available encryption

I thought extremely strong = widely used/available?

We've use only super strong NTRU encryption for public key exchange that is believed to be resistant to even quantum computing attacks

Quantum computing doesn't even exist in any (realistically) applicable way, so I think this a bold statement?

I contacted the service asking about their encryption algorithm, how they exchange keys, if they have cryptographers on their team and got this response:

For the chat we use NTRU for the key and xAES for the message, 4096 bit key. For email we are using PGP at the moment 2048 bit or 4096 bit. The email will get upgraded to the same encryption as the chat at some point. Probably this summer.

I also found out that NTRU is in fact a known standard and has a wikipedia article although I am suspicious of the concept.

Simply put my question is this: would this service and their claims fall under "have no clue" or is it my lack of knowledge and could this be a very decent, functional service?

---

Update: the website's FAQ (or this recent archive) states about xAES (an AES replacement with 4096-bit key) something that seems falsifiable:

we add an advanced symmetrical encryption which is very easy to use with keys 16x longer than those found in AEA256, an industry standard. According to our engineers, this will take 23840 times longer to crack than aes256, which is commonly known as "military grade" encryption.

Answer 1

I'll comment only the statement referring to an AES-256 replacement with 4096-bit key:

According to our engineers, this will take 23840 times longer to crack than aes256

Bob writing that is not able to correctly transcribe even the numbers that engineer Alice allegedly spelled: most likely, $23840$ is intended to be $2^{3840}$, which is the ratio $2^{4096}/2^{256}$ of the number of 4096-bit keys to that of 256-bit keys. For reasons that I'll detail, that ratio of number of keys is irrelevant. Bob is incompetent at crypto, or totally gullible, or dishonest (I mean or as inclusive, not xor). And if anyone left Alice with the impression that $2^{3840}$ was a meaningful number, Alice is incompetent or dishonest, and that does not spell well for the system or code Alice designed or wrote.

Thus at least one holds: The FAQ's author is dishonest; it is dangerous to trust the engineer cited by the FAQ as advisor.

---

AES-256 is a symmetric cipher with a huge key of 256-bit. Remember the tale of the man who asked the sultan as reward for his good services 1 grain or rice on a first square of a checkerboard, 2 on the second, 4 on the third.. and got impaled for having asked $2^{64}-1$ grains of rice, which is orders of magnitude more than the worldwide yearly rice production nowadays? Well, 256-bit instead of 64-bit is like this man asking a checkerboard with 256 squares instead of 64. 64-bit of key was considered quite safe against key enumeration in 1970, and the reasonable optimists about the power of Moore's law agree that 1 year does not quite give 1 bit when it comes to brute force, and that whatever exponential trend there has been has already started to slow. Meaning 128-bit is still safe from key enumeration for the next two decades, and 256-bit is safe from key enumeration for whatever matters to man (the later is even with quantum computers running full gear). Increasing key size to 4096-bit serves no purpose towards the threat of key enumeration, and it is pointless to consider the ratio $2^{4096}/2^{256}$ of keys for whatever security consideration or practical purpose.

Increasing the key size of a block cipher could conceivably serve some other purpose (like making side-channel attacks harder, although the opposite could also occur). But if that was the intend, the extra protection obtained (if any) would not be anywhere near $2^{3840}$, or quantifiable to 4-digit precision (if we trust $23840$).

Fact is, past a certain key size, the time (as in the quoted statement) or effort it takes to recover a key does not depend so much on the key size (at least, not as $2^\text{size}$), but on how the key is generated in the first place, and how well it is protected from later leakage. Over that limit (much less than 128-bit nowadays), a bad RNG, careless storage, a buffer overflow, another side-channel (timing, power consumed..), a fault-injection attack, younamit, are more likely threats to a key's confidentiality than key enumeration is.

Answer 2

The claims made are pretty much all nonsense or do not represent an accurate understanding of the state of the art. I'm not going to go into a point-by-point response; suffice it to say that I would not trust any advice or representations they may make about what is or isn't secure. Their system might be fine, or it might not be, but their public statements do not give grounds for confidence.

So, yes, their claims fall under "have no clue". Whether it is a decent, functional service, I can't say. It could be... but my a posteriori estimate of the probability of that has gone down, after reading their public statements.