Quick thoughts & personal review comments EasyCrypt - easycrypt.co - concept

Post date: Feb 7, 2017 5:30:08 PM

Some personal random thoughts about easycrypt.co .

How it works

First it sounds really good, easy, secure, communication using pseudonyms and 'encrypted' metadata. Let's find out what the weak spots are. Because usually things aren't as good as they seem to be on first glance.

It can be used as app or webmail, that's nice. Yet this might mean the legendary 'JavaScript' cryptography problem. No it's not about JavaScript, but generally about browsers and web tech as 'too complex' and therefore insecure platform, with way too many soft spots.

If not using EasyCrypt App / Webmail, then you don't (of course) see the encrypted message content. That's something which is natural and totally expected.

FAQ

Transparent encryption is always nice, but is strong identity management included? Encryption without strong identity is practically useless. It was encrypted to someone's public key, but you're not sure to whom exactly. Not even in pseudonymous sense, except the public key fingerprint. Of course it might not be visible. This is a common weak spot with many public key encryption solutions.

Limited to specific email service provider? - They say you can use any provider. But that's not probably true. I assume they'll be using IMAP and other protocols, which aren't actually provided by "any" provider. Of course you can use copy-paste methodology, it works. But it's annoying. Yet it's universal.

Ok, PGP / OpenPGP support, that's clear and I were kind of waiting to see it. Because they said 'external' users, it sounded like they would be using some common technology like S/MIME or OpenPGP 'internally' too.

Now they said it, IMAP required, yep. I guessed it too. So service can't be practically used with email providers which do not provide IMAP / SMTP support.

EasyCrypt plugin for popular email clients. Ok, now it's interesting, how's that different from standard PGP features integrated in many existing email apps already?

Tor / .onion support, nice.

Secret key is stored by them, and protected using a passphrase. Meaning that they've got access (if required) to everything required to decrypt the data. That's naturally a very weak spot. Even if they wouldn't store the data, they'll have it temporarily. And therefore also have access to it + encryption information, if required.

You can import your private key to PGP client. That's clear, so basically EasyCrypt is just 'alternate user interface' for 'Cloud integrated PGP'. Clear, check.

'Disclose my keys', well. Technically you're not unable. You can modify code to store unencrypted data or to store data required for decrypting data, or encrypt data for multiple recipients, etc. This is just why any single service provider claiming to make secure applications is usually bad idea. There's no way for normal users to know, what happens when they give their pass phrase to an app, is it native or a webapp doesn't really make any difference. Both can be covertly modified by powerful attacker or the authors, if and when required.

Previous things also mean that the metadata claim was isn't totally solid. Because message is transmitted over normal SMTP / email delivery platform, which means that the metadata is available, at least partially.

Time when emails are sent and the size, ahem. Maybe you forgot to mention source and destination. Those aren't directly available, but probably can be statistically correlated later by powerful advisory if required.

Next bullet is interesting. They claim that no email addresses, no IP addresses or other data / metadata will be leaked. This is something which probably will be answered in the Under the Hood section. At his point my guess is that the messages will be sent to some kind of a gateway taking care of the processing, so there's metadata but it's pretty useless. I'm curious to find out the rest. - I'll keep reading.

The OpenPGP statement sounds correct. That's just what I were kind of expecting. 'Full' metadata leak, when using OpenPGP alone.

Using a pseudonym with existing address. This is probably related to the gateway concept. Let's see.

Anonymous statement is interesting. Waiting to see the Under the Hood section. - When they say 'identity' will be hidden. It's a great question what's defined as 'identity'.

They talk about SSL, how about talking about TLS, not about SSL. PFS is good, but that's not alone probably enough. Also mentioning the CA doesn't really matter, because the problem isn't the CA alone, but it's the whole mess of certificate authorities. This is something which is widely covered and known. And I've written about it several times earlier.

Some of my questions weren't addressed, but they made me really interested to read the next section.

Under the Hood

First though, the Under the hood section is a lot shorter than I were expecting. After reading tons of academic research white papers about secure communication, this is a real stub compared to those. Yet that's not necessarily a bad thing. I personally do like very compact documents.

Ok, Tor is also a fundamental part of how EasyCrypt works.

Encryption: '4096 bit encryption', ehh... It doesn't mean anything. Ok ok, of course I know in this case it means 4096 RSA (because of OpenPGP), but in general. I don't ambiguous like statements like that. I've blogged about that earlier too.

Key management

Private keys are stored on EasyCrypt servers, encrypted with a password... - This is one of the primary weak links so far.

Yes, keys can be decrypted on any device, as long as you know the password or able to guess or bruteforce it. Also as said, there's no way for the user knowing, if the data is properly encrypted or not, and or if the encryption key / password is being leaked.

Yet I like their option for external public key registration, I could do that right now. There's nothing wrong with it. Yet for something I would really need OpenPGP for, I wouldn't probably use EasyCrypt for. But that's totally personal paranoid tinfoil hat opinion. Nor I would use any of my regular workstations or phones.

Metadata and anonymization

This should be the interesting part.

Wow, the first sentence / paragraph is cool and confusing at the same time.

Minimization of metadata is always good.

Several terms are bit ambiguous. 'Email pseudonym', 'Anonymous Cryptographic proof'. More details plz. I of course do understand the concepts, but details would be very interesting to see.

Sending data over Tor network indicates participation to Tor network as well as mount of data transferred and timings, which is metadata. Yet of course it's not as bad as the usual email metadata.

Yet again, being anonymous might make blocking different kind of content, abuse & attacks lot harder.

Appending recipient information to the encrypted message, leaves it open if the recipient information is encrypted. From the text it seems that it isn't. Yet Tor does encrypt data for transport. Are additional layers necessary, or being used. I don't know. I personally might wrap that data with EasyCrypts public key and additional OpenPGP encryption, before transferring over Tor. Probably that's just overkill, but it wouldn't hurt too much.

As we're talking about metadata. Also the amount of data and timing information is obviously known to EasyCrypt.

Message transport to the recipient

Filling headers with fake metadata is probably a bad idea for multiple reasons. Spam filtration, and misdirecting abuse, etc... Probably major services like Gmail reject the messages almost immediately. Email doesn't require any extra headers, just leaving those out would be a better option. AFAIK. Probably still leads to high spam score.

Message decryption by the recipient

That's all obvious.

Communication with external PGP users

That's all pretty standard.

Secure Webmail with single password login

Browser based Webmail / HTML5 client, ok. That's also pretty standard. This topic has been discussed deeply in other discussions and there are inherent problems with this approach, if high security is required. Hushmail case could be a good example with Java Applet approach.

bcrypt isn't recommended to be used. Yet scrypt is also pretty new. Generally it seems that using scrypt over bcrypt should be preferred.

Here's also the weak link, yes, password is processed in browser. It can be stolen from browser, or it can be sent without protecting it properly before transmission, plus countless other issues by real hackers. Like the end device security etc. Yet those apply to all encryption applications. These were just the extremely simple obvious attack vectors.

It's not defined exactly how the private key is encrypted / protected, except that it's using the users password. I would assume it's the OpenPGP standard protection, which should be ok.

To sum it up, the users password is the weak link on multiple levels. If and when required, it's trivial to break system security totally transparently, so that nobody likely notices anything.

Random thoughts, questions and comments

These are things I don't know answers to. How do you defend against DDoS on Tor? Maybe there's obvious answer to that, but I don't know it. Initially I would think it's pretty hard due the double blind anonymization.

Omitting information is sometimes a blessing, sometimes it makes things hard to follow. I often like very compact documents. Questions which follow from the reader, also usually clearly indicates how well they've understood the (purposefully) missing obvious parts.

Mixing practical solution: With nerd cypherpunk tech, free and anonymous is usually a hard mix to get right. - Problems are almost inherently guaranteed. - No this doesn't mean it wouldn't work. But it could be very hard or practically impossible to get it right and manage the system and abuse.

Just as a remark, I haven't never ever received PGP, OpenPGP, GnuPG, GPG encrypted spam. Even if my public key(s) are widely and publicly available.

Without seeing the user interface, it's hard to know if the key management provides enough visibility to the end user about the keys being used. It might be really good, or bad. Who knows.

Sometimes I wonder if the whole concept of services like this is to gather 'confidential' data, and then cash out intelligence services and others 'trusted wealthy entities' to pay for accessing the data, or directly blackmail users. Yet, I just wish that would be my personal sick thought.

Conclusions

Pretty basic implementation to utilizing well known standard technologies (mostly). Yet, it's only as secure as they want it to be, and that security and be broken without the end user knowing anything about it.

This writing is based on their web site's information on 2017-02-06. I'm not cryptography professional. These are just my nerd hobby random ramblings about the topic. - Sorry about that.