Matthew Green Profile picture
Jul 6, 2021 13 tweets 3 min read Read on X
I was going to laugh off this Kaspersky password manager bug, but it is *amazing*. In the sense that I’ve never seen so many broken things in one simple piece of code. donjon.ledger.com/kaspersky-pass…
Like seriously, WTF is even happening here. Why are they sampling *floats*? Why are they multiplying them together? Is this witchcraft? Image
And here, Kaspersky decided that instead of picking a random password, they should bias the password to be non-random and thus “less likely to be on a cracker list”. 🤦🏻‍♂️ ImageImage
Then they used a non-cryptographic PRNG (Mersenne Twister). Amusingly, this is probably the *least* bad thing Kaspersky did, even though it’s terribly bad. Image
And in case you thought that after doing everything else wrong, they were going to do the next part right: nope. They then proceed to seed the whole damn thing with time(0). Image
I have to admire the combination of needless complexity combined with absolutely breathtaking incompetence.
Anyway, before anyone kills me for being mean to developers doing the best they can… The real takeaway here is that (obviously) nobody with even modest cryptographic knowledge ever audited, thought about, or came near this product.
And in case you’re of the opinion that bad implementations are unique to Kaspersky: it’s entirely possible to make some other mainstream password managers “hang forever” by setting the password chatset constraints too high, indicating that they haven’t figured this out either.
Some actual constructive lessons:

* Always use a real RNG to generate unpredictable seeds, never time(0)
* Always use a cryptographic RNG
* Never ever use floats in cryptography (I suspect some Javascript nonsense here)
* To convert from bits to an alphabet of symbols… 1/
(Rewriting this because now I’m afraid people will take advice from tweets)

You should use rejection sampling, with you can find articles about online. Be careful that your rejection loop doesn’t run forever.
And please, get someone to look at your code. Especially if it’s going to be in a mainstream product. You cannot ever ship anything bespoke like this without having an expert glance it over. Even an hour would have flagged all this stuff.
Oh gosh. Image
Anyway I recently had a discussion with a group of expert cryptographers/cryptographic engineers about whether “don’t roll your own crypto” is a helpful rule, or if it’s non-inclusive.

I don’t know the answer, but stuff like this is why the phrase was invented.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Matthew Green

Matthew Green Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @matthew_d_green

Sep 19
Most of cryptography research is developing a really nice mental model for what’s possible and impossible in the field, so you can avoid wasting time on dead ends. But every now and then someone kicks down a door and blows up that intuition, which is the best kind of result.
One of the most surprising privacy results of the last 5 years is the LMW “doubly efficient PIR” paper. The basic idea is that I can load an item from a public database without the operator seeing which item I’m loading & without it having to touch every item in the DB each time.
Short background: Private Information Retrieval isn’t a new idea. It lets me load items from a (remote) public database without the operator learning what item I’m asking for. But traditionally there’s a *huge* performance hit for doing this.
Read 14 tweets
Sep 12
The new and revived Chat Control regulation is back. It still appears to demand client side scanning in encrypted messengers. But removes “detection of new CSAM” and simply demands detection of known CSAM. However: it retains the option to change this requirement back.
For those who haven’t been paying attention, the EU Council and Commission have been relentlessly pushing a regulation that would break encryption. It died last year, but it’s back again — this time with Hungary in the driver’s seat. And the timelines are short. Image
The goal is to require all apps to scan messages for child sexual abuse content (at first: other types of content have been proposed, and will probably be added later.) This is not possible for encrypted messengers without new technology that may break encryption.
Read 4 tweets
Sep 10
One of the things we need to discuss is that LLMs listening to your conversations and phone calls, reading your texts and emails — this is all going to be normalized and inevitable within seven years.
In a very short timespan it’s going to be expected that your phone can answer questions about what you did or talked about recently, what restaurants you went to. More capability is going to drive more data access, and people will grant it.
I absolutely do believe that (at least initially), vendors will try to do this privately. The models will live on your device or, like Apple Intelligence, they’ll use some kind of secure outsourcing. It’ll be required for adoption.
Read 6 tweets
Aug 26
I hope that the arrest of Pavel Durov does not lead to him or Telegram being held up as some hero of privacy. Telegram has consistently acted to collect huge amounts of unnecessary private data on their servers, and their only measure to protect it was “trust us.”
For years people begged them to roll out even rudimentary default encryption, and they pretty aggressively did not of that. Their response was to move their data centers to various middle eastern countries, and to argue that this made your data safe. Somehow.
Over the years I’ve heard dozens of theories about which nation-states were gaining access to that giant mousetrap full of data they’d built. I have no idea if any of those theories were true. Maybe none were, maybe they all were.
Read 6 tweets
Aug 25
Apropos Pavel Durov’s arrest, I wrote a short post about whether Telegram is an “encrypted messaging app”. blog.cryptographyengineering.com/2024/08/25/tel…
The TL;DR here is that Telegram has an optional end-to-end encryption mode that you have to turn on manually. It only works for individual conversations, not for group chats. This is so relatively annoying to turn on (and invisible to most users) that I doubt many people do.
This on paper isn’t that big a deal, but Telegram’s decision to market itself as a secure messenger means that loads of people (and policymakers) probably assume that lots of its content is end-to-end encrypted. Why wouldn’t you?
Read 5 tweets
Jul 13
If you want to avoid disasters like the AT&T breach, there are basically only three solutions:

1. Don’t store data
2. Don’t store unencrypted data
3. Have security practices like Google

Very few companies can handle (3), certainly not AT&T.
One of the things policymakers refuse to understand is that securing large amounts of customer data, particularly data that needs to be “hot” and continually queried (eg by law enforcement) is just beyond the means of most US companies.
If you’re a policymaker and the your policy requires company X \notin {Apple, Google, Microsoft, Meta}* to store “hot” databases of customer data: congrats, it’s 1941 and you just anchored all the aircraft carriers at Pearl Harbor.

* Frankly I’m being generous with this list.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(