Thanks for sharing. I'm one of the co-authors of the blog post. Let me know if you have any questions!
tl;dr: We analyzed a LockBit v3 variant, and rediscovered a bug that allows us to decrypt some data without paying the ransom. We also found a design flaw that may cause permanent data loss. Nothing's earth-shattering, but it should be a fun read if you're into crypto and security!
You can use Google Search and tell Google not to log your search history or use the data for advertising purposes. See my comment [1] for how to turn on these privacy controls.
> not to log your search history or use the data for advertising purposes
People already know/feel that when Google states that it will not do something with people’s information but it does not say what it does... well, that doesn’t feel very comfortable. In fact, it’s so uncomfortable, that people avoid asking what does Google do with that not logged or not for advertising data. On mobile, being the only alternative a device that costs about 5 months of my work, I may not what to know the answer for that questions too and just hope for the best
This assumes Google is acting in good faith, and I find that hard to believe when Google's consent prompts are intentionally annoying and not GDPR compliant (for reasons outlined in another comment of mine: https://news.ycombinator.com/item?id=25373600) and they used dark patterns like intentionally disabling functionality such as saving specific locations when location history is disabled in Google Maps.
If you want to keep using Google services, here are some Google Alternatives Alternatives:
1/ Google Search, YouTube, Maps: visit https://myactivity.google.com/activitycontrols to turn on auto-deletion or turn off search history, location history or YouTube watch history. This page also allows you to turn off ads personalization. There are many security and privacy controls on https://myaccount.google.com/, turn them on however you see fit.
2/ Chrome: visit chrome://settings/syncSetup to turn off Chromesync, disallow Chrome sign-in, disable automcomplete searches and URLs, etc. You can also change the default search engine to something else, but see point 1/ if you want to use Google Search. Use Incognito mode more often.
3/ Gmail, Photos, Calendar, Drive, Docs: "we don’t use information in apps where you primarily store personal content—such as Gmail, Drive, Calendar and Photos—for advertising purposes, period." [1] In other words, Gmail, YouTube or Search ads are not targeted or personalized using your emails, photos, events, docs, etc.
Disclosure: I'm a Google's security engineer, advocating for and contributing to some of the aforementioned security/privacy controls.
For point 2/ if you are unwilling to switch to Firefox and want to keep using Chromium based browsers take a look at Ungoogled Chromium.
I switched from Firefox to Ungoogled Chromium after a long time because of atrocious UI/UX on macOS. However I am stuck with Google pushing Manifest v3
LOL no. Try using Google Maps logged out on an Android phone for more than a week. Google will find a way to reconnect you to the default Google account on the device.
An even better test:
- get an Android device (say, a OnePlus 6T)
- create some contacts on the phone, and add a few events in the default calendar
- open the Play Store (required to get many of the most popular apps)
- you're required to logged into a Google account
- log in and try to not have your contacts and calendar events uploaded to Google's servers.
That is not possible, because
1. you must be connected to the Internet in order to log into a Google account (obvious)
2. Google does not let you enable or disable the sync for a particular item before starting uploading everything
3. Google will enable the sync for all possible items (starting w/ contacts) in the background, and you cannot switch screens fast enough to prevent that.
This must have been the default for most Android devices for a decade now. They keep collecting billions contacts details without users' explicit consent, which is 100% illegal.
> Companies like Google get huge fines when they break their promise -- even accidentally.
Source?
Facebook has used phone numbers given exclusively for 2FA purposes for targeted advertising and got away with merely a slap on the wrist considering their revenue.
Facebook also collected data for years from their trackers but only relatively recently started exposing that to users (with their "Off-Facebook activity" page), which means that for 2 years they were in breach of the GDPR by not allowing people access to their own data and incriminated themselves (by now providing that webpage which proves they've collected this data for years). They are yet to be investigated & fined for this.
GDPR and privacy regulation enforcement is still a complete joke.
>Crypto is hard because you don't get quick feedback on whether you are doing well.
Well said.
If you are to implement a sorting algorithm, you'll know immediately whether it works or is fast enough. Crypto doesn't provide this feedback. It's important to get help from others, if you can't tell yourself whether your code works.
I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun?
>Those rules aren't easy to follow, but they are simple to know about.
If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained?
The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me.
>About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work?
You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either.
>About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ can be a great help when designing a protocol.
This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto.
There are two approaches to learning: top down or bottom up.
The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc.
The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.
On the off chance that anyone here isn't familiar with 'cryptbe, he broke the Flickr URL signing scheme, he and Juliano Rizzo discovered and worked out the BEAST TLS attack (which, to hear Kenny Paterson describe it, more or less set the template for the next 10 years of applied TLS attack research), and then discovered CRIME, which is the first in a line of compression oracle attacks. He works on Daniel Bleichenbacher's team now doing Tink and and Wycheproof.
Hmm, that came out too harsh, sorry about that. I could clearly read your good intentions. It's just that at the same time, you bowed to the zeitgeist of "don't do this for real". It's kind of a ritual I see everywhere. Every time anyone writes about crypto, they feel obligated to say "oh by the way this is scary stuff".
Cryptography seems to be the only domain where this happens, even though many other kinds of code are just as critical: parsers, readers & players, network code… anything that reads potentially hostile input. I hate that double standard.
> If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained?
Because no single source actually explained what the rules were. I simply didn't know them. I didn't even know how to make a proper test suite when I introduced the vulnerability (in Spring 2017, well before v1.0.0).
By the time the vulnerability was discovered (in June 2018), I had a much better understanding of those rules, which allowed me to find the vulnerability from an odd report (which by itself wasn't a bug). The rule being "if you don't understand something, dig deeper". In other words, "don't mess with maths you don't understand".
Now however, after 4 years of practice, I think I have a rather keen understanding of the rules. And what do you know, they turned out to be fairly simple. Even side effects: you can know you've avoided all possible timing attacks. It's only a matter of making sure nothing flows from secrets to timings. (Side effects play a very small role in making code non-obvious. Almost negligible, compared to optimisations.)
---
Re CTF/challenges, my apologies. I should have qualified. I cannot deny they help you get a feel. I didn't go this route, but I reckon it's a valid one, especially if it's fun for you. Beyond that initial kick however, it really depends what you mean to do. Do you want to make crypto? Or do you want to break crypto?
If you want to break crypto (which would be extremely useful when dealing with existing systems), then sure, actually breaking broken crypto would be a huge help. Hands on experience.
I however want to make crypto. I don't care for legacy, I just want to either select or make something simple that suits my needs (something I'm currently doing at work, incidentally). And for this, I strongly believe that learning to break crypto is unnecessary. And beyond the very basics, inefficient. A faster way to build crypto is learning about testing and proofs. (I believe Collin Percival has a similar opinion https://www.daemonology.net/blog/2013-06-17-crypto-science-n...)
I don't think we need to go full top-down, however. My focus would be on mathematical proofs (proofs about algebra, about discrete maths, and about programs).
>I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.
>I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.
Author here. I mentioned libsodium [1] and Tink [2]. We started Tink because we want to provide more/better libraries.
>Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.
It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?
> It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?
I don't have any particular plans of something I want to build at the moment. I was just using group chat as an example where there on one hand you're told to not roll your own crypto, but otoh you can't really just use someone else's crypto because there's no way to just use it.
Say I want to use an encrypted transport, that's trivial, I can just use TLS relatively easy. For the most straight forward case i can do `http.Get("https://example.org")` in go and not have to worry at all about the crypto.
If I want E2E, there's libsodium and tink, yes. But then am I "allowed" to build e.g. a forward secrecy scheme using ephemeral keys with these libraries? On one hand I know enough about crypto that I could do that, otoh, I also know enough about crypto that doing so would already make me uncomfortable.
So what I dream about is to have something like "ssh/tls" for E2E. Something like libsignal generalized. Of course you will have to do some key management, and it will never be as simple as `http.Get("https://example.org")`.
I notice at the end you imply that a senior software engineer claiming they weren’t rolling their own crypto because they used OpenSSL was doing so in error. What sorts of issues could arise if they were using OpenSSL to handle cryptography? Or was it that they were trying to use low level APIs in OpenSSL to create some higher-level cryptosystem they perhaps didn’t fully understand?
For the very example-driven people, can you give a couple of examples of some of those non-obvious, subtle implementation details that completely destroy crypto schemes?
Symmetric encryption algorithms usually need an input called the initialization vector (IV), but different algorithms have different requirements.
AES-CBC requires unpredictability, but AES-CTR (and AES-GCM) require uniqueness. Misunderstanding of these requirements have led to real world attacks, see for example BEAST or https://eprint.iacr.org/2016/475.pdf.
Here's a random example. HMAC is frequently used in security protocols to generate more keys from a master key (for example, to generate temporary keys from a session key). The input to HMAC is (internally) padded with null bytes (<NUL>) before processing, so that for example "abc" and "abc<NUL><NUL><NUL>" will generate the same result. You may need to be aware of that padding when designing protocols that rely on HMAC, in order to avoid certain weaknesses. https://crypto.stackexchange.com/q/52161
As a very basic but very common example, I've seen many non-experts jump to encryption or symmetric crypto signatures whenever they want to prevent tampering with data, when what they needed was a simple integrity check.
Or, they want to do an integrity check, but don't realize that they need a canonical serialization algorithm for their implementation. So they use a standard, non-canonical serialization algorithm, and most of the time it works (because these algorithms typically don't vary that much, especially across tests on a single machine), but that's dangerous because it fails randomly in real life.
Encrypting too much data with the same key immediately comes to my mind. Due to subtle issues involving birthday bounds, encrypting e.g. terabytes of data using AES-128-CTR (or GCM or other counter modes) can be insecure. Note that this can become an issue when CTR mode is used as a PRG for other cryptosystems, particularly if there is no good entropy source available and the system is demanding a lot of pseudorandom bytes (e.g. because there are many TLS sessions being served).
Another issue to look out for is compressing plaintext before encryption, which in some cases makes the encryption itself close to useless. Skype had this issue a few years ago and it is a tricky problem for secure voice or video conferencing.
If speed was not an issue and you don't mind having to have 3 keys, could you cover all the bases by doing MAC-then-encrypt, then treat that as cleartext and do encrypt-and-MAC on that, and finally treat the result of that as cleartext and do encrypt-then-MAC on that to get the final thing you send?
Given how long side channels and timing attacks have been causing problems why haven't compilers tried to meet the requirements of crypto authors and implementors?
Feels like people are fighting against compiler optimisations more than ever.
Crypto code and non-crypto code have different requirements. For compiling non-crypto code you often want the fastest code that still matches the language spec. "Fast" is usually even relative to target platform. For crypto code, you need a very narrowly defined abstract machine that you program against and since that's a much stronger requirement than what the language is defined for, you take the next best thing by turning off all optimizations and hoping you understand well enough how your compiler generates code.
In other words, they already do their best by giving authors control over how much optimization is applied. Anything beyond that is a language design problem, not compiler construction problem.
The last vulnerability [1] is super cool, as it allows to decrypt AES-GCM ciphertexts using an AES-CBC padding oracle!
The exploit is very efficient and fits in a tweet:
1. Take C = E(K, IV) \xor P from GCM encryption
2. Make a guess of P, send (IV \ xor PADDING) || (C \xor P_guess) to the CBC oracle where PADDING is a fixed constant. If the oracle returns that the padding is correct, P_guess is correct. Otherwise make another guess.
The root cause of the issue runs pretty deep. It's a class of crypto vulnerabilities we called "in-band protocol negotiation". That is, the ciphertext contains protocol-related parameters that determine how it should be decrypted. The JWT standard has this issue, which has led to countless "alg": "none" vulnerabilities. JWT is not alone, this mistake is presented in many other libraries or standards.
I wrote about how we avoid this issue in Tink [2] [3]:
>2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
>This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
>JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
>To the best of my knowledge, Tink is the only high-level library that gets this right.
tl;dr: We analyzed a LockBit v3 variant, and rediscovered a bug that allows us to decrypt some data without paying the ransom. We also found a design flaw that may cause permanent data loss. Nothing's earth-shattering, but it should be a fun read if you're into crypto and security!