"This is not a vulnerability in Tutanota. We have built Tutanota with multiple layers of protection for our users. We currently use TLS and DANE to protect authentication and data integrity and (only tunneled) RSA-OAEP and AES-CBC to provide confidentiality. We have always communicated this transparently, it is nothing new. Neither the confidentiality nor the integrity of our users' data has been at risk. However, we know that the implementation is not perfect regarding this detail. That is why we are going to implement the following features as soon as possible: - Signatures/MAC - 2-factor authentication - Algorithms resistant to attacks of quantum computers - Simple verification of downloaded Tutanota apps Regarding the described issue, we know of two possible attacks on AES-CBC. Neither of them is feasible against Tutanota users: - Bit flipping: You need access to the plain text email and you have to be the MITM. - -Plaintexts are available at the sender and recipient only. We use secure TLS algorithms and DANE to protect against MITM. - Padding oracle: There is no padding oracle in Tutanota. Tl;dr There is no known vulnerability in Tutanota. Security is the heart of Tutanota, and we will fix vulnerabilities immediately."
They seem to confuse digital signatures with message authentication.
> Padding oracle: There is no padding oracle in Tutanota.
Interesting claim. They're using PKCS5 which means that, yes, there is a padding oracle vulnerability, but triggering it is orders of magnitude more difficult than null padding.
> They seem to confuse digital signatures with message authentication.
Why do you think that? Of course we (I am one of the founders of Tutanota) understand the difference of the two.
> They're using PKCS5 which means that, yes, there is a padding oracle vulnerability
Could you please describe the padding oracle? Knowing the padding algorithm is not enough to make up a padding oracle. The oracle must be able to decrypt the cipher text in order to tell the attacker if the padding is valid or not.
> Could you please describe the padding oracle? Knowing the padding algorithm is not enough to make up a padding oracle. The oracle must be able to decrypt the cipher text in order to tell the attacker if the padding is valid or not.
For fuck's sake, Google it. The top two search results explain it perfectly.
TL;DR if you aren't using authenticated encryption, because you're using CBC mode with a block cipher, an attacker can keep sending forged messages until it decrypts successfully. It's much easier to forge messages on zero byte padding than exploit PKCS(5|7), but attackers can still exploit padding errors to tell if their message decrypted.
> an attacker can keep sending forged messages until it decrypts successfully
There is simply no way for an attacker to find out if his forged messages decrypt successfully besides having full control of the recipients machine. The padding oracle is useless in this case.
"The padding oracle is useless because we don't behave differently if decryption fails" doesn't really inspire confidence.
Why is there so much resistance to implementing authenticated encryption? It would literally take 10 minutes to implement, with constant time MAC verification on the recipient's end. That includes the time to unit test it.
Hell, I could send a pull request right now to do it if your team doesn't have the expertise on board.
> Why is there so much resistance to implementing authenticated encryption?
We already stated that we are going to implement authenticated encryption. But when we do it we have to do it right. We have to keep everything backwards compatible and we can't enable one client to use the new implementation until all supported clients (JS, .NET (Outlook), Android and iOS) are upgraded. Implementing this kind of backward compatibility will not take only 10 minutes.
Please submit a pull request that keeps everything backwards compatible and works for all platforms. We are happy about everyone who wants to contribute.
"There is simply no reason NOT to encrypt anymore
Even to people not very interested in protecting their privacy, there is simply no reason anymore to let the spies look into their mailbox while they can have exactly the same product with automatic encryption."
Actually, there are good reasons not to: Spam filtering. People have forgotten how bad spam was. It isn't possible to fight spam centrally when all email is encrypted.
Pretending that there aren't any downsides isn't the way forward. It's important to be open about the issues at stake, then say what's possible with the tools that can be created.
Maybe spam filtering could be pushed client side? Granted you end up with more email being pushed through the servers, but at least the client can decrypt and mark it as spam locally.
Using Spamhaus alone will block (with a very low FP rate) about 99% of spam. Throw in a few other simple techniques and the inbox is pretty clean, all without even looking at the message body. Most spammers haven't caught up to techniques more than a decade old, so I don't expect them to suddenly start encrypting E2E to evade (e.g.) uribls. I've received about 5 spams in the last year (self hosted), and I can live with that.
Let's imagine a world where spammers has to encrypt their emails. That would initially be a hassle and resource demanding, but it would be used against spammers. The recipient could demand a resource demanding encryption which for a normal server take about a second but if you were to send out millions it would be impractical.
If that's so easy to do, why don't recipients "demand" some proof-of-work right now?
There's also exactly zero overlap between encryption and proof-of-work. I don't see why you phrase it as if encryption makes proof-of-work either possible or easy.
The network effect changes (very expensive) which limit adoption of proof of work also limit adoption of encryption. Assuming encryption is adopted, the vendor(s) involved could simultaneously demand using Hashcash or another email proof of work system.
One should seriously estimate and discuss the environmental implications of such a change before working towards it though, I think.
Rather, not giving someone the only key to your house if there's a high chance they are going to lose it. It doesn't make sense to encrypt certain things.
You can even do that, plus add two things. 1) mail that gets filtered gets an automatic reply 'your email went into the spam folder, here's how to reach me if it's genuine', and 2) any email with say $1 or some threshold you can manually set is accepted into the inbox with a 'paid' label.
Things like bitcoin have made it pretty easy to add digital money attachment to email as an anti-spam measure, first proposed as a proof of work system by Cryptographer Adam Back to introduce a cost to sending email, a bit like a computerised form of a captcha, something that doesn't affect normal users but is disastrously expensive for power users like spammers.
The combination ensures that 1) spam gets filtered 2) genuine emailers flagged as spammers get notified their email didn't arrive 3) important email can reach the recipient if it's worth enough (say $1, totally undoable for a spammer who'd end up with a cost-per-click on his email campaign of hundreds of dollars instead of cents, completely unworkable on any scale, but financially no problem for when say a stranger wants to send you a genuine email for the first time with a non-trusted key).
about the similarity between his ideas about Hitler's ideology and a short story Borges published in 1946. We had never communicated before; I heard of him for the first time through this press interview. He replied and said the connection was interesting.
I wouldn't be that opposed to ideas where people should put money at stake when making new unsolicited contacts, but I think a challenge is that people's wealth varies by many orders of magnitude, the recipient-perceived relevance of what they want to say varies by orders of magnitude, and the correlation between the two is often only moderate (maybe mediated by things like education, social capital, and fame).
It's ironic: In many ways, the simplest problems are the hardest for hackers to solve. We naturally understand programs and protocols that flummox average users, including PGP and Bitcoin. Donning the veil of techno-ignorance is an elusive skill, so it can take a long time to figure out how something valuable can be reduced to a truly idiot-proof format.
Lots of different approaches to encryption have pitched themselves as the easy-to-use replacement for PGP. Alas, so far, none of them have taken the world by storm.
Lots of different approaches to encryption have pitched themselves as the easy-to-use replacement for PGP. Alas, so far, none of them have taken the world by storm.
That's good, though. PGP is the only one that's given true safety. Everything else has broken, either in theory or (mostly) in implementation. The problem is a social one, and it doesn't need to be solved quickly. It's fine if it takes several more decades before we find the right model.
Those that want to protect themselves can do so. Those that don't, don't. Not such a bad outcome, all things considered.
It seems like PGP's web of trust model was the mistake, anyway. There's not much wrong with the model of "here's my pubkey, and now you can send me data securely." The key can be intercepted or subverted, but what changed since the 80's was the rise of instant messaging. In 2015, you're often talking to people in realtime, and you want to talk and send data to them securely. To do that, you're exchanging keys in realtime, over some kind of chat program. (Even emailing someone a pubkey counts as a form of chat.) In that context, the web of trust is unnecessary.
Emailing somebody your public key sounds like a really bad idea. What about your friend's evil sysadmin who replaces the public key that you sent with another one, thereby enabling MITM? You might as well not use PGP in that case. Of course, once your friend has established that it was indeed your public key, it's all fine, but doing initial key exchange over unauthenticated channels sounds like a recipe for disaster.
> What about your friend's evil sysadmin who replaces the public key that you sent with another one, thereby enabling MITM?
You could also send with it detached key signatures from mutually trusted friends. This would add weight to your claim that this key belongs to you. Then, your recipient can check that your message's contents (including your pubkey) are signed by a key that your receiver can adequately measure authenticity. Does that seem right?
If a hostile MITM modifies your message and/or your key and signature, then these friend's signatures won't match. If they change these signatures as well, then those won't match the receiver's already trusted keys.
[Aside: One other way I have played with was to rate another signed message by a friend (who sent me his pubkey as an email attachment) with a likelihood that he wrote it, and then I checked if that message's signature matched. As a qualitative heuristic test, it did increase my confidence in that key significantly, though I would have liked to have some trusted 3rd parties witness his possession of it.]
I haven't fully figured out the solution (if I had, I'd be writing it), but I suspect it will ultimately involve the widespread availability of smartphones and laptops with the capacity to record and transmit video. For the time being, the human face and voice are a fairly robust medium for embedding data in a way that is resistant to MITM.
At Palo Alto Research Center in the 1970s, they brought children into their lab and watched as they used or played with the then-new graphical user interfaces.
I am aware of only two general principles to do this: centralized certificate authorities (possibly chained), and decentralized assurance, a. k. a. web of trust. Their advantages and drawbacks seem pretty clear by now.
So, which is it, and if a CA (which I'd assume), who has the keys and how is crytographic trust obtained?
There is nothing wrong with PGP, and I don't understand the desire to see its demise. I agree that it has not been properly integrated with MUA's to the point it is seamless for casual users, but I believe it's the best we have for now.
http://seclists.org/fulldisclosure/2015/Jun/58
How do they prevent man-in-the-middle attacks on their customers, even if their server is the one performing the attack?