A Graduate Course in Applied Cryptography
crypto.stanford.edu
crypto.stanford.edu
I think people are hoping for Cryptography II to be more Terminator 2 than Duke Nukem Forever in terms of sequels.
I loved Crypto 1, and was one of the small % that finished it and did all the extra credit on its first run in ... 2012 IIRC.
Been looking forward to part 2 ever since but I will admit having given up waiting!
It's been invaluable.
Article "How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits" https://arxiv.org/abs/1905.09749 shows how to significantly reduce the cost of factoring integers and computing discrete logarithms. Implementation of the efficient device mentioned in the article requires 2.7 billion Toffoli gates for 2048 bit input. It could factor one key in 8 hours.
Microprocessors reached that high MOS transistor count less than 10 years ago. For example, 8-core Core i7 Haswell-E has 2.6 billion transistors (2014). If quantum computers follow Moore's law like conventional IC, it will take 40-years before they can factor 2048 bit RSA.
Note however that quantum computers can potentially benefit from existing lithography processes, so it may not take as long to scale up as we have already developed processes for very small highly integrated circuits.
The devise itself can be huge, mostly because it's cooled, but the actual quantum state inside is just tiny chip.
Yep, it's definitely a scaling thing. If it weren't then we could simply use Daniel Bernstein's (et al) proposal for Post Quantum RSA.
We have factored some small numbers on quantum computers but nothing a classical one couldn't do in a split second. https://en.wikipedia.org/wiki/Integer_factorization_records / https://arxiv.org/abs/1805.10478
Regarding the „except possibly contrived problems designed to be fast on quantum computers“ part: That’s their entire purpose. They cannot and will never be faster for all applications compared to a classical computer. They are designed to solve some very special problems efficiently, such as solving dlog and RSA using Shor‘s algorithm or database search using Grover.
Shor's or Grover's aren't contrived problems, they're real problems which is why they're interesting. And none of today's quantum computers can run these for non-trivial inputs.
The scalable way to factor is using Shor, but Shor only becomes practical once we have thousands of qubits, and it breaks RSA2048 with about 20 million qubits. (For clarification, a "qubit" here is a noisy qubit.)
Cartoon Cryptography
1min animated series that explains cryptography with cooking analogies
Great share. Pulsed thanks
> Sure, their servers might be in a top secret location. But the problem is that they know your password. Which means any bad actor, like a rogue employee, a hacker, or a government agency can snoop on your data without you knowing.
What on earth?
1. The server operator might accuse you of doing something offering as proof a record that "you" logged in, but actually they knew the password so it was them.
This seems kind of silly if the server is a forum about a video game you like and the consequence of the alleged wrong doing is a permanent ban. But if the server is your bank, and the consequence is they convince a jury you tried to commit fraud and you go to jail when actually their employee has stolen your money using access to your password... that's pretty serious.
2. People re-use passwords. They know they shouldn't, but they do anyway. So "of course" the operator of "Puppy Fan Forum" knows your password, but it's also the password for your Amazon account, and next thing you know there's $1000 of dog treats billed to your credit card going to the operator's home in Ohio.
1. This is actually good news. It provides deniability. You can, for instance, do something bad and then claim that the owner did it.
2. People really shouldn't reuse passwords, but I see your point.
Imagine the reaction a person from the 18th century would have if I told them it's silly to burn things to make light. You're the 18th century person in this scenario. You have never seen an incandescent light bulb, let alone an LED so I'm clearly crazy right? Of course you burn things to make light, how else would it be possible?
There is no need to send your password to somebody in order for them to authenticate you as someone who knows the password. Symmetric PAKEs which do this are actually relatively common in new systems that had a cryptographer help design them today, Bob knows the correct password is "Sesame" and Alice tells Bob something which proves to Bob she knows it too, but even if Eve hears everything both of them say she doesn't learn "Sesame" and won't be able to satisfy Bob that she knows the password.
For real human passwords, verified by humans, like "What's my favourite vegetable?" there's a wonderful protocol the Socialist Millionaire's Protocol, which lets you play this out, each participant says what they think the password is, and the protocol tells them both if they gave the same answer. Because humans are in the loop this can use low quality passwords, if I try to "brute force" you by guessing every possible vegetable you'll get sick of me wasting your time and disconnect.
Better yet, asymmetric PAKEs make it possible for Alice to tell Bob a fact which Bob can use to verify that Alice knows some password P, but without Bob knowing P. Eve can hear everything they say and still doesn't know P and can't impersonate Alice.
This stuff is almost as old as the World Wide Web.
Your "you're the 18th century person" comment is needlessly insulting as well, especially given that what you've commented is basically irrelevant.
Everything we do is Open Source.
Get your facts straight.
Yes, the NSA really did use backdoor access to servers to spy on millions of people.
Snowden.
So use better security, like real cryptography.
No, they're true, which is what makes your reaction so interesting. You might more successfully argue that this (other people knowing your password) is a trade worth making, but then as I explained you don't need to make this trade at all, so the value you're getting by accepting the current practice is zero.
The thing they're "selling" on that site (promoting) is a distributed system where only you can decrypt your own data. There are a bunch of situations where that's not applicable, but even in those situations the other party doesn't need to know your password - so why do most sites do this?
Mostly laziness.
There are literally zero situations in which I would get actual real-world better security from a site not having my password, given (a) that they're properly hashing it, and (b) the password isn't used to encrypt any personal data.
Claiming that sites doing those two things have "fake security" is the kind of bullshit that smells like a marketing scam, which is exactly what makes me suspect they're selling something. (Again, without having any further evidence in that regard.)
Even if a site is using a password to encrypt personal data (basically the ProtonMail scenario), I still have to trust the site itself not to steal my password, so additional security provided in that scenario is marginal at best.
The claims are akin to "we use only 512 bit AES, sites with only 256 bit keys have FAKE SECURITY". It's at best extremely misleading, and hard to imagine that it's not some cynical FUD marketing technique.
https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
Claims that this means Facebook weren't "really" properly hashing it or are otherwise an exception constitute a No True Scotsman argument.
It is _definitively_ less safe to do what is commonly done today. There is no _practical_ benefit and there are plenty of things that can go wrong.
That being said, it was incredibly interesting and I do not regret it.
I wish this book was in a public git, TBH.
Edit: I don't know why I'm being downvoted.
The rest of it appears to consist of "areas that theoretical cryptographers are refining in preparation for real world use". This is the stuff that will be deployed in the real world come 2030.
So, to answer your question: More than half of it is actually used today, and at least 80% of it will be used soon. If you're going to take a course in this, it's better to be ahead of the curve than behind it. (Otherwise, we'll all be suffering through textbook RSA ad nauseum.)
In the 1990s, French banks apparently considered providing online banking on the open and public Internet as much riskier than on the closed and proven Minitel (and probably quite rightly so).
I Googled for minitel cryptography. The first result was your comment. I suppose that tells me there was no crypto on minitel, as well as that google doesn't miss a beat.
Other people have answered the direct superficial question: A lot of this stuff is used already to make stuff work. TLS (for HTTPS) has been mentioned, but if you have a work laptop it's probably using Full Disk Encryption, if you use git for revision control the content addressability that makes that possible is only safe with cryptographic hash functions, the reason a bored teenager can't listen in to all your mobile telephone calls is cryptography, the reason it's very hard (and ought to be impossible if they'd done a better job) to use a chip-and-PIN credit card without the PIN is cryptography and so on.
Now the more subtle question: Do you need any of this? Well no for a lot of jobs you don't, just as a car mechanic doesn't need a grasp of aerodynamics to do their job, but if they fancy designing jet aeroplanes that's going to be a problem. This course is about applying cryptography but it isn't an engineering bootstrap course, so it expects you to understand why rather than only learning how.
The answer, as others have said, is most of it. In my role in fintech/banking we are indeed using many of these things - digital signatures using traditional or elliptic curve keys, authenticated constructions built of block ciphers and macs, key derivation techniques using stream ciphers etc etc.
While we do not commit the cardinal sin (though shalt not design thy own cryptosystem), knowing how they work can be invaluable to working with them.
With that said, if your employer has an educational plan that can cover the cost, then it is definitely worth pursuing. I am working on a AI graduate certificate and have just completed CS 221. The level of rigor in instruction and course work is far better than any online MOOC course I've taken.