site: blog.cryptographyengineering.com
Ok Google: please publish your DKIM secret keys
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ [blog.cryptographyengineering.com]
2020-12-11 06:27
tags:
admin
crypto
email
opsec
security
This post is about the situation with Domain Keys Identified Mail (DKIM), a harmless little spam protocol that has somehow become a monster. My request is simple and can be summarized as follows: Dear Google: would you mind rotating and publishing your DKIM secret keys on a periodic basis? This would make the entire Internet quite a bit more secure, by removing a strong incentive for criminals to steal and leak emails. The fix would cost you basically nothing, and would remove a powerful tool from hands of thieves.
source: green
What is the random oracle model and why should you care?
https://blog.cryptographyengineering.com/2020/01/05/what-is-the-random-oracle-model-and-why-should-you-care-part-5/ [blog.cryptographyengineering.com]
2020-01-16 04:14
tags:
compsci
crypto
hash
security
About eight years ago I set out to write a very informal piece on a specific cryptographic modeling technique called the “random oracle model”. This was way back in the good old days of 2011, which was a more innocent and gentle era of cryptography. Back then nobody foresaw that all of our standard cryptography would turn out to be riddled with bugs; you didn’t have to be reminded that “crypto means cryptography“. People even used Bitcoin to actually buy things.
That first random oracle post somehow sprouted three sequels, each more ridiculous than the last. I guess at some point I got embarrassed about the whole thing — it’s pretty cheesy, to be honest — so I kind of abandoned it unfinished. And that’s been a major source of regret for me, since I had always planned a fifth, and final post, to cap the whole messy thing off. This was going to be the best of the bunch: the one I wanted to write all along.
source: green
Looking back at the Snowden revelations
https://blog.cryptographyengineering.com/2019/09/24/looking-back-at-the-snowden-revelations/ [blog.cryptographyengineering.com]
2019-09-25 21:34
tags:
crypto
development
networking
opsec
security
web
It’s no coincidence that this is a cryptography blog, which means that I’m not concerned with the same things as the general public. That is, I’m not terribly interested in debating the value of whistleblower laws (for some of that, see this excellent Twitter thread by Jake Williams). Instead, when it comes to Snowden’s leaks, I think the question we should be asking ourselves is very different. Namely:
What did the Snowden leaks tell us about modern surveillance capabilities? And what did we learn about our ability to defend against them?
source: green
How does Apple (privately) find your offline devices?
https://blog.cryptographyengineering.com/2019/06/05/how-does-apple-privately-find-your-offline-devices/ [blog.cryptographyengineering.com]
2019-06-06 12:27
tags:
crypto
iphone
opsec
security
vapor
A big caveat: much of this could be totally wrong. I’ll update it relentlessly when Apple tells us more.
Since this is a security system, the first question you should ask is: who’s the bad guy? The answer in this setting is unfortunate: everyone is potentially a bad guy. That’s what makes this problem so exciting.
source: green
On Ghost Users and Messaging Backdoors
https://blog.cryptographyengineering.com/2018/12/17/on-ghost-users-and-messaging-backdoors/ [blog.cryptographyengineering.com]
2018-12-18 17:31
tags:
networking
policy
security
social
Which brings us to the real problem with the GCHQ proposal. As far as I can see, there are two likely outcomes. In the first, providers harden their system and kill off the vulnerabilities that make GCHQ’s proposal viable. The more interest that governments express towards the proposal, the faster this will happen. In the second outcome, the UK government (and perhaps other governments) force the providers not to lock them out. This second outcome is what I worry about.
More specifically, today’s systems may include existing flaws that are easy to exploit. But once law enforcement begins to rely on those exploits, the systems can never change or improve. Over time what seems like a “modest proposal” using known flaws could lead us to world in which ancient flaws are preserved, and where agencies like GCHQ become the ultimate architect of Apple and Facebook’s communication systems.
source: green
Let’s talk about PAKE
https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ [blog.cryptographyengineering.com]
2018-10-24 03:13
tags:
auth
crypto
networking
security
standard
Now, the login problem doesn’t negate the advantage of password hashing in any way. But it does demand a better solution: one where the user’s password never has to go to the server in cleartext. The cryptographic tool that can give this to us is PAKE, and in particular a new protocol called OPAQUE, which I’ll get to at the end of this post.
source: green
Hash-based Signatures: An illustrated Primer
https://blog.cryptographyengineering.com/2018/04/07/hash-based-signatures-an-illustrated-primer/ [blog.cryptographyengineering.com]
2018-04-16 20:55
tags:
auth
crypto
hash
intro-programming
security
But before I get to all of that — much further below — let me stress that this is not a post about the quantum computing apocalypse, nor is it about the success of cryptography in the 21st century. Instead I’m going to talk about something much more wonky. This post will be about one of the simplest (and coolest!) cryptographic technologies ever developed: hash-based signatures.
source: green
Attack of the Week: Group Messaging in WhatsApp and Signal
https://blog.cryptographyengineering.com/2018/01/10/attack-of-the-week-group-messaging-in-whatsapp-and-signal/ [blog.cryptographyengineering.com]
2018-01-11 09:25
tags:
crypto
networking
security
social
This result comes from a new paper by Rösler, Mainka and Schwenk from Ruhr-Universität Bochum (affectionately known as “RUB”). The RUB paper paper takes a close look at the problem of group messaging, and finds that while messengers may be doing fine with normal (pairwise) messaging, group messaging is still kind of a hack.
source: green
The strange story of “Extended Random”
https://blog.cryptographyengineering.com/2017/12/19/the-strange-story-of-extended-random/ [blog.cryptographyengineering.com]
2017-12-22 04:22
tags:
crypto
networking
standard
A little more commentary on the funny TLS extension found in some printers.
Which brings us to the moral of the story: not only are cryptographic backdoors a terrible idea, but they totally screw up the assigned numbering system for future versions of your protocol.
Actually no, that’s a pretty useless moral. Instead, let’s just say that you can deploy a cryptographic backdoor, but it’s awfully hard to control where it will end up.
source: green
Attack of the week: DUHK
https://blog.cryptographyengineering.com/2017/10/23/attack-of-the-week-duhk/ [blog.cryptographyengineering.com]
2017-10-23 20:28
tags:
crypto
ioshit
paper
random
security
The paper is called “Practical state recovery attacks against legacy RNG implementation“, and it attacks an old vulnerability in a pseudorandom number generator called ANSI X9.31, which is used in a lot of government certified products. The TL;DR is that this ANSI generator really sucks, and is easy to misuse. Worse, when it’s misused — as it has been — some very bad things can happen to the cryptography that relies on it.
See also: https://duhkattack.com/
source: green
Regarding "patching is hard, you've never patched a production system" hot takes
https://blog.cryptographyengineering.com/2017/09/15/patching-is-hard-so-what/ [blog.cryptographyengineering.com]
2017-09-15 22:51
tags:
admin
business
development
security
The key point is that once you’ve baked this cake, you’d better be willing to eat it. If your system design assumes that application servers will not contain critical vulnerabilities — and you don’t have resilient systems in place to handle the possibility that they do — then you’ve implicitly made the decision that you’re never ever going to allow those vulnerabilities to fester.
Also on the twits: https://twitter.com/matthew_d_green/status/908707591840296961
Agree with the punchline: If you can’t patch struts in a reasonable manner, then you can’t put struts in the critical path for system security.
source: green
The future of Ransomware
https://blog.cryptographyengineering.com/2017/02/28/the-future-of-ransomware/ [blog.cryptographyengineering.com]
2017-02-28 17:04
tags:
blockchain
crypto
essay
future
hash
malware
networking
security
Is blockchain!
This hasn’t been a terribly serious post, although it was fun to write.
source: green
In defense of Applied Cryptography
https://blog.cryptographyengineering.com/2011/11/07/in-defense-of-applied-cryptography/ [blog.cryptographyengineering.com]
2017-02-06 13:01
tags:
book
crypto
retro
As in it’s still not a good book to read today (if you want to learn crypto), but nevertheless a great historical artifact and record of earlier times.
source: green
The limitations of Android N Encryption
https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/ [blog.cryptographyengineering.com]
2016-11-25 01:09
tags:
android
crypto
security
Getting better, but still not good (enough)?