Hacker News Reader

Comment by Fiveplus | Hacker News Reader

Claims of said encrochat:

* Each message session with each contact is encrypted with a different set of keys. If any given key is ever compromised, it will never result in the compromise of previously transmitted messages – or even passive observation of future messages.

* Anyone can forge messages after a conversation is complete to make them look like they came from you. However, during a conversation the recipient is assured all messages received are authentic and unmodified. This assures non-reputability of messages.

* The algorithms employed are many times stronger than that of PGP (RSA+AES). We employ algorithms from different families of mathematics, which protects message content in the event that one encryption algorithm is ever solved.

* Messages do not employ digital signatures that provide third party proofs. However, you are still assured you are messaging with whom you think you are.

source: https://encrochat.us/

View on HN

Saying "many times stronger than RSA/AES" but not providing details on the algorithms is a huge red flag.

If they have built some home-grown algorithm, then it's possible the NCA actually cracked the encryption (with a bit of help from GCHQ) rather than using the baseband processor to snoop on the keys or something like that.

It could also be implementation-based.

A few years ago they rounded up a ring of crime phones in the Netherlands.. They were using PGP encryption, however instead of each phone generating its own private key, they generated them centrally and kept them in a database. Obviously this introduced a huge vulnerability.

The police compromised the server and was listening in (through cooperation with Canadian police as they were using Blackberries) for quite a while before they started kicking doors down :D They basically got all the evidence on a silver platter.

I'm surprised someone with the skill to develop such an app and service platform doesn't have the skill for avoiding such common mistakes. Or maybe they weren't able to explain to their users that the fact that they couldn't retrieve their messages after forgetting their pincode is a feature, not a bug. Either way, the police was really happy.

https://nationalpost.com/news/canada/canadian-judge-releases...

Not saying the same would have happened here, but crypto is hard to implement correctly and the algorithms are only part of the problem. And this kind of network is a massive target for law enforcement because the ratio of criminal users is huge.

Actually, according to Dutch press (nrc.nl), it was the same detectives who performed that hack who were flown into France to do this hack as well.

Good for them, but I hope for their sake their names do not leak.

Another famous case was a crime lord who's blackberry pin was written on a sticky note so police got everything.

https://www.chch.com/niagara-drug-kingpin-goes-trial-murder/

I'm surprised someone with the skill to develop such an app and service platform doesn't have the skill for avoiding such common mistakes

My impression is that the way things go is:

* Sure, a smart person can implement a "homebrew" security protocol that seems safe.

* But smarter people never implement a "homebrew" security protocol and instead use existing protocols, 'cause they know how easy it is to fuck-up.

* The smartest people implement real, secure protocols, working in academic or three letter agencies and have those protocols vetted and peer reviewed. And even these fail on a regular basis.

So much this! My learning curve on crypto took me through a few self-evaluations:

- Crypto isn't that hard! I can do this!

- Crypto is a lot harder than I though. I shouldn't do this.

- I've read about a lot of crypto! I can do this!

- People way more experienced than me are making the tiniest mistakes that end up crashing the entire house of cards. I definitely shouldn't do this.

Implementing a protocol correctly is easy. Implementing the primitives is harder (and tons of work), but you can easily grab them from a low-level crypto library like Libsodium or Monocypher.

Designing a protocol correctly is not that hard, as long as you understand exactly what you are doing. By which I mean you are at least able to write an informal (yet rigorous) proof that it has the security properties you seek. Also, verification tools like Verifpal are a godsend. The tricky part here is avoiding the Dunning-Kruger effect. It's easy to have the illusion of perfect understanding while being unable to write the most basic mathematical proof.

The hardest part is convincing others that your protocol is any good. People who don't understand what you are doing cannot (perhaps even must not) trust your work. They need the vetting of someone reputable, and getting those reputable people to take a look is pretty hard if you don't have the right connections (an uphill struggle without a relevant PhD).

It was the French.

https://www.vice.com/en_us/article/3aza95/how-police-took-ov...

No the exploit was by the Dutch supporting the French because the actual physical servers were located in France, under their jurisdiction. Just like the previous time they did this we aren't getting a lot of information of how. But it seems physical access is part of the exploit.

Sure but the "crack" that occurred here was essentially MITM, so regardless of their encryption scheme they would have been caught.

It isn't necessary for a central server to be able to intercept messages. In an end-to-end encrypted system any boxes in the middle can infer stuff from traffic but they can't read message contents.

The article says: "Europol said that French police had discovered some of EncroChat's servers were located in the country, and that it was possible to put a 'technical device' in place to access the messages." Even if it was end-to-end, they at least could intercept the initial key exchange perhaps.

Intercepting a DH key exchange doesn't help you. The whole point of DH is that an eavesdropper doesn't learn the secret even though both of the other participants do.

They probably just didn't use end-to-end because it's easier to offer a nice customer experience without.

Closed source is a huge red flag.

Ideally, nobody should use any form of closed-source crypto any more.

>Anyone can forge messages after a conversation is complete to make them look like they came from you.

"I didn't send those messages your honour. Someone forged them. I am a victim of a conspiracy!"

"Do you have any evidence that this actually happened?"

"No."

"...moving right along..."

It will be fun if someone from this actually tries a cryptogeek argument in real life...

Ross Ulbricht tried essentially that defense.

Exactly. The tricky part of plausible deniability is that it needs to actually be plausible. People very often screw this part up. EG they'll make a TrueCrypt/VeraCrypt hidden volume, but then won't modify the outer volume with the same access patterns to hide their usage of the hidden volume.

Doesn't this put the burden of proof on the accused?

People have been claiming they have been framed since forever. If claiming you were framed with zero proof actually helped in any way then every one would do it and much time would be wasted.

In the case of a crypto forgeablity argument there will never be any proof. It will always be a false claim. It is a silly idea.

> People have been claiming they have been framed since forever.

Yes they have, but they have been doing so in the face of circumstantial evidence: DNA, fingerprints, blood, whatever. Or eyewitness evidence: someone saw you go in the building at such and such time (perhaps there is a surveillence video).

If someone has nothing of the sort on you and their entire claim is that you wrote some digital message, I'd think the onus would be on them to prove their extraordinary claim somehow.

Just like with any other evidence. My point is that the possibility of forgery makes no difference at all to that.

A piece of digital text isn't a forgery; there is no concept of authenticity in it in the first place to serve as a backdrop legitimizing the use of the word "forgery". It's not like planting someone's hair, or imitating their signature. You need absolutely nothing from the victim, and to expend no effort.

The concept seems to have come from the original off the record (OTR) messaging proposal. The concern was that, say, a PGP signature could create a situation where there was objective proof that someone had created a particular message. By making forgery possible the theory was that someone could disclaim the message. I have been writing some PGP fandom articles lately which is why I am up on the subject. The relevant articles:

* https://articles.59.ca/doku.php?id=pgpfan:off_the_record

* https://articles.59.ca/doku.php?id=pgpfan:repudiability

So I am not disagreeing with what you said, it supports my contention that forgability is a silly cryptographic feature if there is no proof in the first place.

algorithms don't matter for shit to the person that controls the (mandatory) updates.

its the same issue with all modern e2e apps like whatsapp or signal, if there is a single client implementation its not secure at all to these kind of attacks.

Exactly! All it takes is a "demand letter" from any government with jurisdiction. See: https://en.wikipedia.org/wiki/Lavabit

> signal [...] > if there is a single client implementation its not secure at all to these kind of attacks.

There are (where?) actually multiple "distributions" of signal, like textSecure on f-droid. Last I checked it worked with signal, but that was a few years ago.

No, Moxy killed the alternatives with really shitty arguments and banning from using Signal official servers.

> Each message session with each contact is encrypted with a different set of keys"

Is this not a bad thing? Since transferring key-pairs is the weakest link on these apps. To be really secure, wouldn't you want to do this as infrequently as possible and ideally outside in person outside the app?

Sounds like they are trying to achieve perfect forward secrecy per message. Typically you might do this with Diffie-Hellman using ephemeral derivation pairs per session. This is good practice as if any one session key is broken, that has no effect on the privacy of past or future messages encrypted under different session keys. They seem to be claiming to use their own crypto based on the parent comment (red flag) and no signature scheme over the top of it to prove a consistent identity, so I'm not sure what they would be doing. Establishing encrypted pipes over an observable medium is very doable, but providing a way to trust that the party on the other end of the pipe is who you think it is is the hard part as you pointed out.

It would be fine if they meant "forward-secure ratchet construction", like Signal does.

You can rotate message/session keys easily enough if you have a shared long(er) term key.

Session keys are fine, and they're usually not the top level identity or key. So long as this is what they're doing, i.e. using an asymmetric KEx (e.g. Diffie-Hellman) to exchange public keys, from which a shared secret would be derived, and then from that a KDF would be used to generate a key using a salt, you can keep generating new keys for each session from that shared secret (shared in the sense that it's symmetric, not that you send it over the wire).

You can still be more secure, but that's a decent start.

No, this is actually normal. For instance, each time you make a SSH connection, it will use a different key for the bulk encryption. A key exchange has to happen to negotiate this randomly generated session key.

> We employ algorithms from different families of mathematics

Did they roll their own?

Could also simply mean that they are chaining different encryption algos from libraries (à la TrueCrypt) which would indeed add to the security level or even at worst not harm it. (This assumes that each step is not broken...)

It's unclear, but that statement alone makes me shudder.

Anyone doing secure comms at this level, and is talking about families of mathematics always gives me the impression they don't really know what they're doing.

> Anyone doing secure comms at this level, and is talking about families of mathematics always gives me the impression they don't really know what they're doing.

Why is that? Do you assume that making competent choices for encryption algorithms (for which you try to understand the math problems involved) and trying to market the systems security means that they also try to implement it themselves? Or is the "family of mathematics" a sign for incompetence that I just don't recognize?

As someone who's worked in the sector (the crypto sector, not the crime one):

"Families of Mathematics" is a marketing statement, or "hot air" as I prefer to call it. The information content of that statement is zero, what it's doing is trying to project warm "you can trust us" feelings.

A statement aimed at technical people would read more like "we use AES-256-OFB with Axolotl on Curve25519 and scrypt(2^14, 8, 1)" or something like that.

To a crypto professional, I'd say any "trust us" statement that's not backed up by technical information actually lowers their trust in the system - it makes you wonder why they're not making their algorithm choice public.

Thanks for clarifying. You convinced me.

The US created a fake bank to catch drug runners and cartel bosses. What's to say this isn't an state intelligence backed company created not to sell a product but to be sold to criminals then listened to until warrants were signed?

I haven't looked into the service at all so could be totally off.

Wow. Do you happen to have more details about that fake bank honeypot?

There's an excellent episode of the npr podcast Planet Money that covers this story: https://www.npr.org/transcripts/694548245

That's where I heard it, yeah.

I just interpreted that as "we use RSA and ECC".

> To a crypto professional, I'd say any "trust us" statement that's not backed up by technical information actually lowers their trust in the system - it makes you wonder why they're not making their algorithm choice public.

IMHO if your solution isn't open source, or least completely documented so it can be verified, then the whole point is moot anyway.

So it's based on my experience. I'm an Engineer in secure comms. I absolutely see the "family of mathematics" card as a sign of incompetence. In the space, nobody talks about the mathematics. The people implementing algos might, but they're in a different space.

A savvy customer wants to know which algos you're using, and how you're using them, where you're using them. EC? RSA? Other? Which implementation are you using, is it audited? Standard based? Working with government, is it FIPS or similar? What does your KEx and KDF look like? Data at rest security? WHAT are you storing, and sending? Transport security? Metadata? Development practices?

There are a LOT of things a customer wants to know, and which or how many "family(/ies) of mathematics" has never been one of them, in my experience.

Waving about "families of mathematics" when selling a product is just an attempt to bamboozle the gullible.

The number of branches of mathematics that you involve in the product doesn't mean anything.

Encrypting a message twice with different keys using exactly the same algorithm (thus the same branch of mathematics) is prima facie as effective a security increase as using some different algorithms involving different mathematics.

Most everyday crypto products rely on the results from several different areas of cryptography with different mathematics.

I have to agree that point 2 is very clever.

"It was not me, your Honour, as anyone can send a message by my (old) name)

It (deniable authentication) has been provided previously by OTR.

https://en.wikipedia.org/wiki/Deniable_authentication

TLS provides a weaker version (instead of everyone in the world being able to forge a message, just your peer is able to forge the message).

>This assures non-reputability of messages.

No, they're assuring reputability, not non-reputability.

Perhaps they were going for non-repudiation?

I've never heard "reputability" used in crypto, but confusingly, it might be the opposite of "repudiability"?

I read it as saying you could deny writing any specific message as it could have been forged after the session ended. Non-reputability.

I disagree, I believe, they're trying to say they provide "non-reputability" (the opposite to non-repudiation) so you can deny messages actually came from you because they could have been "forged".

it's hard to tell though, the statements are a bit of a mess in general.

Hmm, you're right that non-reputability likely means something different than non-repudiation. The problem is I can't find anyone actually using non-reputability in that other meaning.

What I do find is various places using non-reputability erroneously as a synonym for non-repudiation.[1][2][3] So in fact I now think that EncroChat actually made 2 errors: said non-reputability instead of non-repudiation, and also misunderstood non-repudiation as meaning repudiation.

[1] https://books.google.com/books?id=qk_hDwAAQBAJ&pg=PT682&lpg=...

[2] https://books.google.com/books?id=_d7RUNF-2tcC&pg=PR21&lpg=P...

[3] https://books.google.com/books?id=PHBTDwAAQBAJ&pg=PA61&lpg=P...

Damn why didn't they use a messenger not made by idiots

> The algorithms employed are many times stronger than that of PGP (RSA+AES).

If they just used PGP over email, they wouldn't have gotten caught.

From what I have heard most criminals since the 90s use PGP over email (middle management and higher criminals not street thugs who probably just use WhatsApp or worse). They should go back to that.

Well, it tells you a lot about the ease of use of PGP when people prefer to go to jail rather than use PGP ;P

If you read the Vice article, it explains that they were compromised by on-device "malware" that was pushed in an update via the company provider (whose software update process had been taken over by the authorities).

So it doesn't matter what software they would have used since the device itself was capturing data before encryption and after decryption.

They could have been using regular iPhones/Galaxies/Pixels etc. Then it wouldn't rely on this bespoke operating system and its updates. It seems unlikely Play Store or Apple Store would get compromised. But you could always compile the PGP app yourself.

Could law enforcement require access to play and appstores? Has this happened?

Law enforcement could replace an app, with their own, even for one specific user, if they have access to the system, granted by Google or Apple. I presume the signing can can be compromised, this way, but am unfamiliar to know this for sure.

Using those stores means using those centralized services by Apple and Google, which includes device updates, carrier updates and more than just app store downloads.

And those companies would absolutely comply with a legal request to push intercept updates to phones.

Reply on news.ycombinator.com