Why We All Need To Agree That It Is Flat Out Unacceptable To Use RSA in 2019 (trailofbits.com) 188
An excerpt from a post on Trail of Bits: From major open source projects to exciting new proprietary software, we've seen it all. But one common denominator in all of these systems is that for some inexplicable reason people still seem to think RSA is a good cryptosystem to use. Let me save you a bit of time and money and just say outright -- if you come to us with a codebase that uses RSA, you will be paying for the hour of time required for us to explain why you should stop using it. RSA is an intrinsically fragile cryptosystem containing countless foot-guns which the average software engineer cannot be expected to avoid. Weak parameters can be difficult, if not impossible, to check, and its poor performance compels developers to take risky shortcuts. Even worse, padding oracle attacks remain rampant 20 years after they were discovered. While it may be theoretically possible to implement RSA correctly, decades of devastating attacks have proven that such a feat may be unachievable in practice.
Totally ignorant article (Score:5, Insightful)
Completely confused the problems of rolling your own crypto with the topic of if RSA or ECC is more secure.
Re: (Score:2, Funny)
You missed the opportunity to call it a "Really Stupid Article".
Re:Totally ignorant article (Score:5, Insightful)
Right. It's really a rant against rolling your own crypto, which is stupid. Using a solid crypto library that's widely used and thus published, reviewed, and more widely debugged by use in the field is smarter, no matter what the underlying algorithms.
Re:Totally ignorant article (Score:5, Insightful)
Using a solid crypto library that's widely used and thus published, reviewed, and more widely debugged by use in the field is smarter, no matter what the underlying algorithms.
QFT.
Some knucklehead is going to try to implement lattice crypto to try to stay ahead of the quantum curve and speculation attacks and forget to address timing.
This comment is worth more than the article, folks.
Re: (Score:3, Funny)
Quite right. You should all be using a known good implementation of Dual EC DRBG! It's NIST approved!
Re:Totally ignorant article (Score:5, Funny)
Right. It's really a rant against rolling your own crypto, which is stupid.
Unless it's OpenSSL. Then there's a good chance you could roll your own crypto better.
Re: (Score:2)
Unless it's OpenSSL. Then there's a good chance you could roll your own crypto better.
It's weird how much modern software still tolerate SSLeay, especially on Microsoft Windows. There are so many better libraries out there like Mozilla NSS, Botan, GnuTLS, and RSA BSAFE (excluding the SSL-C suite in BSAFE which is just a rebadged SSLeay).
The Java problem (Score:2)
Java has a problem: it's so good at error handling and memory protection that it's impossible for a non-technical manager to tell the difference between a good java programmer and a bad one. This has resulted in a large number of bad java programmers writing faulty code.
You don't see as high a proportion of bad C programmers because the bad ones can't get their C programs to run without segfaulting. They move on to a more forgiving language. Like java.
The article posits that RSA has the same problem: too ea
Re: (Score:2)
In C#, if you do something stupid, it might not compile. Sometimes the compiler is stupid, so you get things like declaring a variable without initialization and then a set of conditions that mathematically can't all be false to set the variable, then use it, and the compiler refuses to compile because it can't prove to itself that you're not using an uninitialized variable.
In Java, you get a null pointer dereference with managed memory.
Re: (Score:2)
You don't see as high a proportion of bad C programmers because the bad ones can't get their C programs to run without segfaulting.
There's a huge chasm between getting your C program to run without *obvious* segfaults, and actually being secure even in the face of deliberate attacks.
I'm sure that at least 90% of your surviving C programmers are still in that chasm, but nevertheless think that their code is bulletproof.
Re: (Score:2)
There are plenty of bad C programmers, masses amount of copy and paste, no idea how to use or write a reusable library, there isn't even a standard map library in C it is 46 years old. Yes they do need to know how actual actual memory works, because almost every line in C requires you to think about it, but C if doing it diligently is about 90% error checking and handling and cleaning up if it fails, however that code never actually gets tested since random errors inside you code generally never happen.
Re: (Score:2)
Boost is a set of C++ libraries. It's used by folks willing to sacrifice efficiency to get Java-like protections. Which is a mystery to me because if protection is more important to you than speed, why not use a language that's built for it? Like Java.
Re: (Score:2)
Actually, a Java program is just as likely, if not more likely, to crash than a C program. It may not seg fault but if you dereference a null pointer, it will throw an exception, just like C. On the other hand, if you reference memory outside an array bound, it will throw an exception, just like C... oh wait, no, the C program will likely carry on as if nothing is the matter.
There's a world of difference between writing code that won't crash because of such basic errors and writing code that is cryptographi
Re: (Score:2)
Java throws an exception and you catch it. No data corruption has occurred. C generally segfaults after a series of mistakes has irredeemably corrupted memory. Even if you catch the signal, the program can't continue.
Re: (Score:2)
Re: (Score:2)
The article doesn't really back up that point very well. They mostly rail against parameter selection in RSA, while admitting that their suggested alternative, ECC, can also be screwed up by poor parameter selection. ECC has fewer parameters... is that better?
RSA has been around for a long time, and is used very extensively. Many of those libraries have been very well tested. ECC is younger, so less well tested.
The article seems to be aimed at developers who don't really understand what they're doing (elli
Re: (Score:2)
The article seems to be aimed at developers who don't really understand what they're doing
No, because developers who don't really understand what they're doing are likely to take on an RSA implementation. This is more for project managers, designers, and OSS cowboys who may not have the math or security background to realize that just because a coder can produce code "on deadline" doesn't mean they can count on coding bugs or QA to catch a flawed RSA implementation.
Re: (Score:2)
I think I agree with you, but it would have been better to start your post with "Yes, because...." The article assumes that the developer, or whoever, doesn't know what they're doing and thus decides coding their own cryptography would be a good idea.
Re: (Score:2)
Re: (Score:2)
RSA is more resistant to quantum attacks than is ECC. ECC is faster and (usually) requires less memory. But more importantly, the RSA libraries that exist are generally older and better tested than ECC. Both algorithms are mathematically secure, so practical attacks come down to implementation details.
ECC isn't really more complicated than RSA, provided you get the fairly elementary generalization that you can do modulo arithmetic over groups other than trivial subsets of the natural numbers. It's equally
Re: (Score:2)
"It might take like 8-12x as many q-buts to factor integers compared to in ECC groups of similar classical security"
There you go, you said it. I didn't say RSA is O more resistant, but it is more resistant. It's also a *big* assumption that quantum computing capacity will grow exponentially. Stringing classical transistors together isn't much of an issue, except for heat, and for embarrassingly parallel problems like factoring you can just keep going by using clusters. Quantum computing is very different.
rolling your own is a problem (Score:2)
How many times have we have input validation done wrong and we get a SQL or JSON attack? It's not that you can't do validation correctly but it's as noted, like juggling chainaws in the dark for most people. They don't know what they can't see.
If there's a lot of number theory issues like if P is a prime but P-1 is easily factored then P was a bad prime to choose. Or if the binary representation of P has a lot of zeros. Or P and Q share the same set of upper bits (because gueass what they are the same si
Re: (Score:3)
"if P is a prime but P-1 is easily factored": This is *always* true, isn't it? If P is a prime, then it's either 2 or an odd number, so P-1 is either 1 or an even number. And you can get at least two factors of even numbers quite easily... (I'll leave the factorization of 1 to the student.)
Re: (Score:2)
Or perhaps you're confused over what development managers and security specialists should be aware about RSA implementation concerning reliability. This is an article equivalent to explaining why a programmer shouldn't use GOTO even though it may be available instruction. Its possible to write a reliable programs using GOTO/JMPs; but it doesn't mean project managers should consider such coding choices acceptable for code submission.
Re: Nothing wrong with rolling your own. (Score:2, Interesting)
Nope you roll your own you get fucked. I have seen that too many times. Arrogant pricks like you who think they understand and get ass fucked because your implementation was hoarked. Sorry but you are a ticking time bomb.
Re: (Score:2)
Nope you roll your own you get fucked. I have seen that too many times.
You've seen it too many times? Why are you so often on teams that roll their own crypto? It smells like BS.
Re: (Score:2)
Re: (Score:2)
Those of us who write in Hebrew, or Russian, or most any other alphabet, would notice.
Speaking of which, I wonder what the equivalent of Rot-anything would be in Chinese characters?
Re: (Score:3)
Unfortunately there are a lot of insane developers out there, who frequently choose to roll their own poorly designed crypto instead of using an existing tried and tested algorithm. They think that rolling their own will be more secure, because they believe in security through obscurity, so in almost all cases there are severe flaws found.
It's not just the implementation to consider, it's also correct use of the implementation.
Re: (Score:2)
Re: (Score:2)
This whole idea that crypto software is magic to be cast only by the most trained sorcerers is such nonsense, and has done incredible damage to this useful domain of software infrastructure.
No, but an experienced security coder will understand an algorithm can be mathematically secure, the crypto library vetted, yet still result in an insecure product because the coder fucked up the implementation, which wasn't as trivial as you believed.
Honestly, your best bet for security is to roll your own, but that means actually understanding the mathematics and algorithms at play; of course, you dumbfuck codemonkies can't be expected to do that, which is why you just copy trash around like a virulent STD.
It also means understanding good security practices and issues when implementing code, which is why you dumbfuck codemonkeys can't implement secure software.
anonymous (Score:1)
coward
Why We All Need To Agree... (Score:1)
I stopped reading after that.
Re: (Score:2)
Re: Why We All Need To Agree... (Score:5, Funny)
Re: Why We All Need To Agree... (Score:5, Informative)
In this case, I have to agree with the AC. Articles that start off with "we all need to agree" are very rarely worth reading. This one is no exception (regretfully, I did read it).
Re: (Score:2)
Why? Did you suspect that the fact was in doubt? Read on, McDuff!
So, what should we use instead? (Score:5, Insightful)
If crypto is used as per a standard, RSA is pretty secure. For example, if I use OpenSSL or the OpenPGP format for securing files, this is solid against many attacks.
Rolling your own is bad, but RSA is still a solid crypto algorithm. Yes, you can implement it badly, just like using ECB with AES, but that is what crypto standards are for.
Comment removed (Score:5, Funny)
Re: So, what should we use instead? (Score:2)
Speaking of repeating things (it works for DES, but not everything in general): here's an example of why you shouldn't roll your own (except to educate yourself): what happens if you hash the hash of a value?
Welp, most people new to crypto assume that it's okay. But because a hash function takes a large input space and returns a smaller one, you've just limited the input space of your 2nd output hash to the output space of the first hash function--making life simpler for an attacker.
Moral of the story: lear
Re: (Score:2)
In the 1990s, when people didn't trust hashes, one company I worked for would take the first 64 bits of the MD2/MD4 hash, use the first 48 bits of that as the key, use the second 64 bits as an initialization vector, and encrypt a bunch of 0s with DES, giving a 128 bit output. This is functionally similar to the crypt(3) function that was used around that time to secure passwords in /etc/passwd before machines moved to /etc/shadow, and it did help ensure that the hash used was a lot more sturdy, crypto-wise
Re: (Score:2)
That AES key is then used to encrypt communications between the computers. The fancy algorithm is only used for the initial AES key exchange. And as computers have gotten faster (making cracki
How does one do public key with Eliptic curves (Score:2)
Could someone explain this to me as a public service?
Doesn't it require a secure prior key exchange which is the problem public keys solve?
Re: (Score:3)
Elliptic curve cryptography [wikipedia.org] can do a bunch of things. One of those is Diffie-Hellman key exchange [wikipedia.org], which is a protocol for two people to agree on a secret key using a public channel. You can then use that secret key for symmetric encryption. RSA is often used similarly, to secure the exchange of a symmetric key, which is used subsequently.
Very basically, you have some operation that is easy to perform but hard to undo. For RSA it's multiplying primes / factoring composites; for ECC it's the discrete logarit
Re: (Score:2)
To be pedantic, for RSA the believed-hard operation is also discrete logarithm. Factoring the modulus would trivialise the logarithm, but I believe it's still an open question whether fast discrete logarithms would give fast factorisation.
Re: (Score:2)
To be extra pedantic....
I'm not a cryptographer, but my understanding is this:
RSA depends on both factorization and the discrete log. If you can factor the divisor, you can generate the private key from the public, and thus decrypt any message. If you can solve the discrete log you can recover the message, but that doesn't necessarily get you the private key. The whole-thing-is-broken algorithm for RSA is factorization, and discrete log for ECC. BUT, under certain circumstances, you can use a fast discrete
Re: (Score:2)
Rolling your own is bad, but RSA is still a solid crypto algorithm. Yes, you can implement it badly, just like using ECB with AES, but that is what crypto standards are for.
The author didn't say RSA is an insecure or hopelessly broken crypto algorithm; he said that RSA is subject to many more attacks caused by implementations that are code correct, but vulnerable to attacks which requires a greater cognizance of security issues. That's why he recommends "code monkeys" move to other algorithms, like ECC with a vetted library, who's implementation can still be fucked up, but won't be vulnerable to the same exploits caused by imperfectly implemented code using an RSA library. I
Re: (Score:2)
The things he's complaining about are mostly related to key generation with RSA. If you're using a decent crypto library it will also do the key generation for you, properly. Same thing with ECC... if you (for some reason) roll your own ECC key generation, there are gotchas.
If you're paranoid, ECC has the additional issue that, unless you want to do a whole bunch of work, you pretty much have to use a curve that's been precalculated for you by the NSA... I mean NIST. You might be a bit suspicious of those
Re: (Score:3)
No, he's saying "rolling your own is bad" because it's the truth, and easily explained.
1. Encryption is complicated, and subject to extremely subtle bugs.
2. Encryption bugs can lead to situations where the encrypting and unencrypting run fine, but the encryption can be easily broken.
3. It is difficult to test for how easy your encryption is to break--if you don't stumble on the specific weakness you have, you'll never see it.
4. Therefore code written by experts and extensively inspected by third parties
Re: (Score:2)
Not just encryption. You should do your best to avoid writing your own for any basic and critical software component. There's a reason everyone still uses LAPACK, an old FORTRAN library.
If you do find yourself in some special snowflake situation where you have to write something like that, it's best to open source it in the hope that some experts will wander by and find your mistakes. For example, Google open sourcing TensorFlow, which despite the branding, is a math library.
Re: (Score:2)
Yep, it's true for anything, but particularly encryption, as it's trickier and harder to test than most code.
Re: (Score:2)
Like for example math code being used in computational physics, or calculating spacecraft trajectory, or the like needs to be correct. But it's not working with secret data and usually isn't exposed to external adversaries.
Crypto code not only needs to be correct, but also worry about information leakage that may undermine its security. For example in normal usage it's a good thing if operations th
Re: (Score:2)
Damn, I wish I had points to upvote this.
Re: (Score:2)
Good God. I sincerely hope there's a court order that mandates you keep at least a fifty foot distance from any encryption code.
Re: Rolling your own is the best. (Score:5, Informative)
No, "rolling your own" implementation is bad, precisely because with RSA, the way you generate your keys & USE them (including short-term memory allocation & scratch files) matters at least as much as RSA (the algorithm) itself. And if you try to do it yourself, you WILL fuck up in entirely predictable ways, and make EXACTLY the kind of mistakes that have allowed RSA's ultimate security to be compromised in the first place.
There's even name for an entire class of such exploits: "Textbook RSA". Those are the exploitable weaknesses you end up with whenever someone tries to use Bruce Schnierer's book like a literal cookbook (which it was never intended to be).
Libraries like BouncyCastle aren't immune to fuck-ups. The difference is, when BouncyCastle fucks up, the fuckup gets quickly discovered & fixed. If YOUR home-rolled scheme has a weakness, the only people likely to know about it for years are attackers.
The big thing with Java crypto is, you NEED to keep your app in a state that allows it to be rebuilt with a newer library & updated at a moment's notice. It doesn't help your app at all if a vulnerability in version x.y.z.8 of BouncyCastle gets fixed in x.y.z.11 if the copy of YOUR app on the user's hard drive is still using x.y.z.9.
RSA is no better or worse than other asymmetric encryption schemes in this regard. It has more public vulnerabilities than others, but nobody can say that others don't have even WORSE issues that simply aren't public knowledge. Crypto is DEFINITELY one of those areas where "works for me" isn't good enough, and rigorous mathematical proof is essential. Crypto that appears to work, but without proof, might very well be a metaphorical skeleton key (or a more secure key, hidden nearby under a flower pot).
Re: (Score:2)
> You just said that copying from the guy who literally wrote the book—the expert of experts—is a bad idea.
Bruce HIMSELF will be one of the first to tell you that blindly copying anything from his book & trusting it just because he's one of the world's foremost authorities on crypto is a bad idea.
Crypto isn't "fair". You can do everything perfectly, and STILL have your scheme burned to ashes months later by some new vulnerability. It's the nature of the beast. The best you can ever hope t
so? (Score:2)
Do you have an alternative option?
I'm a pretty decent software developer. So I
a) am going to need some crypto-solution from time to time and
b) I know that I must not write my own.
In other words I don't care if I have to integrate RSA, ABC or XYZ, but I need a clear decision path on which solution to use. Tell me what's state of the art and I'll use it. I'm not attached to RSA in any way, if I use it it may be simply because the best article I read online during evaluation was from 6 years ago.
TLS 1.3 uses Curve25519 (Score:2)
The end of the featured article recommends using an elliptic curve cipher instead of RSA. For the common application of RSA to authenticate parties negotiating session keys, you can use Diffie-Hellman over Curve25519 [wikipedia.org]. For digital signatures, use EdDSA over Curve25519 [wikipedia.org]. TLS 1.3 incorporates both.
Re: (Score:2)
What's wrong with 3 kbit RSA? (Score:2)
Even so, it may still be Good Enough(tm). What's the best theoretical attack on, say, 3072-bit RSA? Does it finish in the life of the author plus 70 years?
Re: (Score:2)
The article suggests using DSA or ECC because they're (supposedly) harder to screw up if you don't know what you're doing and you insist on writing your own. That is the only merit considered.
The article doesn't even fathom that you might not make the colossally stupid mistake of writing your own amateur cryptography library.
Re: (Score:3, Insightful)
The article doesn't even fathom that you might not make the colossally stupid mistake of writing your own amateur cryptography library.
When the widely vetted open source libraries won't fit into the memory of the 8-bit microprocessor that has been chosen for you, what alternative is there to coding your own crypto?
Re: (Score:2)
When the widely vetted open source libraries won't fit into the memory of the 8-bit microprocessor that has been chosen for you, what alternative is there to coding your own crypto?
If you want it to be actually secure, hire someone who's specializes in such things, probably for a lot of money. If you don't mind it being only a bit secure, then implement it yourself.
Re: (Score:2)
Find a crypto library that has been written for 8-bit microprocessors, there are plenty out there.
Re: (Score:2)
1. Simple Google search. There are lots of embedded crypto libraries.
2. Use a processor that can handle the library you like. Memory is cheap.
3. Add external memory.
4. Use a microcontroller with built in cryptography.
5. Use an external cryptography chip.
6. Hire someone who knows what they're doing.
7. Study hard and acquire sufficient knowledge yourself.
You might also ask why you're trying to do public key encryption in an 8-bit severely memory constrained embedded application in the first place.
Re: (Score:2)
Please, sir, can I use a 12-bit processor?
Why can't I get a PDP8 on a chip from anywhere? The architecture was in the public domain from year dot, and it can do a lot for not much electricity - and there is no shortage of software that has actually been tested (for over 40 years).
These days, a very basic chip could do the whole CPU and memory space - and a second memory space for the OS.
Perhaps someone could make USB memory sticks with a free PDP
Re: (Score:2)
The problem isn't putting a PDP8 processor on a chip.
The issue is I/O: Shrinking the punched card reader to that scale makes the system too unreliable for real-world use. (The damned things barely worked full sized.)
Replacing paid-for hardware costs money (Score:2)
Then you chose a 16 bit microprocessor that can run it.
The hard part about that is justifying to your customers the greater cost of a hardware replacement instead of a software upgrade.
Re: (Score:2)
If you're constrained by processing and power, you don't really want to be doing asymmetric encryption, of any kind.
Re: (Score:2)
Do you have an alternative option?
Their alternative seems to be paying them to spend an hour telling you why they don't want to use RSA.
Re: (Score:2)
I should adopt that business model.
Re: (Score:2)
I've very occasionally had the opportunity to get paid to tell people what they shouldn't do. It's really great. Unfortunately, most of the time I get paid (or not) to tell people it's okay to do whatever the hell they want. With numbers, to make it more truthy.
slashdot's TLS cert (Score:2)
Re:slashdot's TLS cert (Score:5, Funny)
The certificate for the linked company blog where this stupid article appears is also RSA.
Re: (Score:2)
Re: (Score:2)
Agreed. I was pointing out that the company that published this rant against using RSA uses it to secure their website. With a certificate from Let's Encrypt, no less.
Re: (Score:1)
vague (Score:1)
Re: (Score:2)
so i think what he is really saying is...anyone?...bueller?
The author is saying if you roll your own RSA implementation, you'll probably screw it up.
Oddly enough, it appears the author did not consider the much, much, much, much more common case where you use someone else's RSA implementation.
The point is FUD (Score:3)
The point is FUD.
When a salesman has an inferior product and is trying to switch customers away from something substantially superior and robust, he dan't make valid, concrete comparisons of the comparative virtues and vices of the two. If he did, he'd just lose, and everybody's tim
There is nothing wrong with RSA (Score:5, Informative)
Re: (Score:1)
My advice is "Do roll your own." But, that means understand what you're doing.
So your advice is to spend months, possibly even longer studying ALL the potential pitfalls in implementing a crypto-primitive, and then hope to fuck that you haven't missed one, or made some other mistake? You can say "understand what you're doing" 10 times, but how does one know when they've actually achieved that, rather than just think they do? This is a fail in the first sentence, since no real developer has the time to lea
Re: (Score:3)
I'd say roll your own as an academic exercise, not for actual use. It's good to understand how the things work, though you should keep in mind all the complexities you would be missing if you did it for real.
Re: (Score:2)
Crypto is hard in general. Using it is problematic (Score:2)
Re: (Score:2)
Do this: try to figure out what the optimal tradeoff point for performance versus security is for an arbitrary setting for a tunable cryptographic parameter for TLS, SSH, or IPSec.
Unless you have invested a lot of time in building a background in cryptography, you'll either end up wondering whether you should really base your decision off what some guys says on a reddit thread, or lost trying to figure out what the domain-specific notation used in an academic paper means.
More useful than this article would
Re: (Score:2)
Re: (Score:2)
I read a bit on the lattice based kex and it seemed like something that should be understandable in two and three dimensions, and then you just explain that the complexity to crack it goes up thusly every time you add a dimension.
The paper was using some notation with a carrot that wasn't in any other literature I could find and I couldn't manage to google anyone explaining that usage, so I couldn't quite come to grips with it entirely, and was having trouble picturing it. The security proof just maps it t
Re: (Score:2)
I don't understand (Score:5, Insightful)
if you come to us with a codebase that uses RSA
What does this mean? If I come to you .... as what? A prospective employee? Then I don't have to 'agree' to anything. You are building a product spec'd to use ROT13. Then it's up to me to build the best ROT13 implementation I possibly can.
If I come to you looking for a development shop, then the shoe is on the other foot. I'm the customer. If I come in with a codebase, I'll expect you to work with it. There are lots of other shops who won't argue with me.
If you are the end user and I am a salesman, then it's up to me whether I want to rewrite my codebase to suit your requirements (on your nickel). Or show you the door. IMO, more software vendors need to take whiny customers and escort them off the premises.
Re: (Score:2)
You are building a product spec'd to use ROT13.
If you're going to use something as weak as ROT13, then at least make sure you run it twice.
How to get your blog sponsored by no such agency (Score:2)
The only thing we all need to agree on is how foolish it is whine about how hard it is to roll your own crypto in 2019.
Yes, foot-guns are a problem. (Score:2)
RSA is an intrinsically fragile cryptosystem containing countless foot-guns which the average software engineer cannot be expected to avoid.
That's why coders should use the updated finger-guns version -- problem solved. (pew, pew pew)
Discrete log is just as fragile (Score:1)
This article is right about the problems with RSA, but it's not like discrete log (including elliptic curve discrete log) systems are much better.
It's not an exact one-to-one correspondence, but there are equivalent subtle implementation gotchas with every public-key algorithm. if you generate a private key with a bad RNG, it's crackable. If you choose bad parameters, it's crackable.
Quite simply, public-key encryption just barely works, and must be implemented with great caution and exacting input validat
IT Security vs the real world (Score:5, Interesting)
My front door has a lock. It is easily defeated with a card. It has a dead-bolt. It is easily defeated with some lock picks.
Still doesn't matter, because there are glass windows everywhere. Maybe you live with bars on your windows.
Still doesn't matter, the door/window frames that hold the bars aren't strong, your garage door isn't strong, I can smoke you out through your own ventilation system, and even using your own smoke.
My air conditioner is outside of my house, and for weeks every year you can kill me just by turning it off -- with the safety switch on the outside.
I drive 140 kph surrounded by other cars going 140 kph, and separated from on-coming 140 kph cars by nothing more than a yellow strip of paint.
Our lovely IT industry is a protection racket, of which any organized crime ring must be so proud.
We entered a world where machines were unreliable and needed maintenance, we made them completely reliable with no moving parts and zero maintenance required, then we spawned groups of people to simply attack everything, so that other groups of people could tell us that we need more security.
And there's no law enforcement action against any of it.
I'll remind you that law enforcement is the only thing that stops us from having the wild wild west today. It's the only reason that you don't steal windshield wipers, shrubbery, and pets.
If you're upset that someone is using old security, just be happy that they're using any security at all. Most of the rest of life isn't secured by anything ever.
There's a parking lot full of windshield wipers right across the street from you. Think about that the next time you buy a set.
Re: (Score:2)
Those people who try to act as you say, typically start by introducing themselves. You, friend, are simply a fraud on all fronts.
And you might notice the keyword above being "try".
First off, treating others how you would like to be treated presumes that others are like you. Try, instead, to treat others how THEY would like to be treated, and you'll find that you have absolutely no idea how others want to be treated. Languages, religions, cultures. Unless you wear a white cone-shaped hat, you have no ide
Re: (Score:2)
Like I said, the problem is that we have no law enforcement of cybercrimes.
Re: (Score:2)
TLS *can* use RSA and a random 'generate a certificate' howto is still likely to be RSA based rather than ECDSA.
However you can use ECDSA instead of RSA in this specific circumstance.
In general, I tend to desire ECDHE and ECDSA for the roles that RSA historically could play in live encryption and signature.
What is in somewhat more short supply is tools like GPG/PGP doing 'offline' asymmetric encryption using ECC. As far as I know, if you were really gung-ho anti-RSA, you'd have to 'roll your own' scheme, w
Re: (Score:2)
Unlike RSA ECC doesn't really do encryption, so you can't do the classic GPG/PGP thing of randomly generating an ephemeral symmetric key, using it to encrypt your message, then encrypting that ephemeral key with the recipient's public key.
However you can achieve a similar enoug
Re: (Score:2)
It's not saying use no encryption, it's saying to use ECC.
Which is... fine... Though RSA hasn't really displayed any particular weakness. Sure it's a bit more resource intensive than EC in various ways, but it's not 'broken' or even vaguely close to breaking. The biggest hand wringing would be if suddenly quantum computing breaks RSA, but EC is theoretically in the same boat. He mentions that RSA parameter selection is tricky, but that applies to ECC as well and it's a key reason why if you don't know,