What a blast from the past!!! I have never met another person who watched that show. I thought it was some show I invented in a dream or in my head and didn’t actually exist.
What a blast from the past!!! I have never met another person who watched that show. I thought it was some show I invented in a dream or in my head and didn’t actually exist.
We got all 4 seasons on DVD from Ebay just last week. :) "Who are you?" "I'm the Librarian." Somewhat smarmy, intentionally cheesy, as whimsical as Willy Wonka. Loving it.
We got all 4 seasons on DVD from Ebay just last week. :) "Who are you?" "I'm the Librarian." Somewhat smarmy, intentionally cheesy, as whimsical as Willy Wonka. Loving it.
RSA the algorithm is different from RSA the company, the only thing they have in common is the name, derived from the founders of the company / inventors of the algorithm. RSA the algorithm is...
RSA the algorithm is different from RSA the company, the only thing they have in common is the name, derived from the founders of the company / inventors of the algorithm. RSA the algorithm is public-domain at this point, so RSA the company has moved on to doing other things that they can actually charge money for, like the RSA tokens that your company probably spends $$$ on.
There is a standard way of doing the "code changes every X seconds", called TOTP. If you have two-factor auth enabled on your Tildes account (or your Reddit account, for that matter) this is what it uses.
The RSA token appears not to use the TOTP standard, but this is just based on their marketing materials claiming "we're secure because we use AES-128 encryption!" but TOTP does not use AES, instead relying on an HMAC. This means the people at RSA invented their own way of doing it instead of following the standard...sigh.
The idea behind both systems is the same though - there's a secret key shared by both the backend server and your authentication fob (or the Google Authenticator app on your phone, for other uses of 2FA). That secret key is exchanged once (this is the "scan this QR code" step in GAuth) and after that never sent between client and server. Instead, client and server have their clocks synchronized (to within X seconds), and the 6-digit code you enter is based on the secret key plus the current time. This is done in a way that if an malicious party looks over your shoulder and sees the 6-digit code at time X, that won't help them log in as you if they try to impersonate you at time X + 5 minutes. Each time the code changes, it's completely unpredictable if you don't know the secret key, even if you've observed previous codes.
So your token is probably secure...certainly none of the arguments in the linked article about RSA the algorithm apply. RSA the company using their own algorithm instead of the TOTP standard is annoying, and means the proprietary algorithm won't have had nearly as much external analysis as TOTP has.
Depends very much on whether the devs were hacks who had to roll their own crypto. If you're using one of the big libraries and stick to best practices and a good key length, RSA is perfectly fine...
Depends very much on whether the devs were hacks who had to roll their own crypto. If you're using one of the big libraries and stick to best practices and a good key length, RSA is perfectly fine imo. The trouble is making your own. It's also not very quantum-computer secure and we have alternatives for that, so we should phase it out, but that's happening only slowly.
But that's not nearly the cybersec risk as some of the bullshit you expose yourself to by using some bigger websites that should really do better. (Unsalted md5-hashed passwords anyone?)
I'm not a CyberSec guy, just a moderately security-aware code person.
I am not taking sides, it is just interesting that the author of the blog post is taking the extreme opposite opinion.
I am not taking sides, it is just interesting that the author of the blog post is taking the extreme opposite opinion.
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..... 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.
As I said, don't roll your own. That's extremely hard and risky. Leave that to the absolute pros. And yes, there might still be bugs to be had there, but if we have a very few crypto systems that...
As I said, don't roll your own. That's extremely hard and risky. Leave that to the absolute pros. And yes, there might still be bugs to be had there, but if we have a very few crypto systems that implement RSA, the number of zero-day exploits we get out of that is limited.
Look, I can go "ssh-keygen -t RSA -b 4096" and get a reasonably secure RSA key. Is that NSA-proof? Probably not. Is it very good security? I think so. As a software engineer that just needs some generic crypto without tight performance constraints (key fob could be such a case...) I can use RSA without shooting myself in the foot by just using an established implementation.
That's not to say the article is wrong. I just think it might be addressed at a different group. The post is not about which crypto to use as the end-user. It's about which crypto to use as a developer, particularly if you have special requirements. I just fail to see as much of an urgency as the author portrays.
The thing is, why use RSA when there are other alternatives that just do better? For asymmetric, you have the ellipsoid based methods as well as el gamal, that don't suffer from the issues...
The thing is, why use RSA when there are other alternatives that just do better? For asymmetric, you have the ellipsoid based methods as well as el gamal, that don't suffer from the issues outlined in the article. Already the usage of RSA is decreasing. TLS, for instance, no longer supports the old RSA based handshake, because it suffered from replay attacks.
Granted. If you're doing crypto these days, might as well do it right. Though I think "Fuck RSA" and "it is flat out unacceptable to use RSA in 2019. No exceptions." are just statements that are a...
Granted. If you're doing crypto these days, might as well do it right. Though I think "Fuck RSA" and "it is flat out unacceptable to use RSA in 2019. No exceptions." are just statements that are a bit too... strong. I don't see them supported. There's no good reason to throw out a proven RSA-protected system. This post doesn't call for me to disable my RSA key on github. This calls for github to offer elliptic curve encryption as an alternative and for me to use it. It also calls for developers that interface with crypto directly to use the same over RSA - which imo aren't most software devs; they'll just rely on pre-rolled solutions that encrypt password DBs or web traffic. I can say for myself that I have yet to directly interface with a encryption algorithm with two exceptions: A) RSA keygen outlined above for SSH (both SSH servers as well as github) and B) classes about crypto. IMO this confirms that the article above is addressed at a different group: Those who actually interact with crypto directly.
Not the same thing, but the same company. the "RSA Token" is a two step authentication system. What is being described in the article is a "public-key cryptosystem". With that said, back in 2011...
same thing as the RSA Token
Not the same thing, but the same company. the "RSA Token" is a two step authentication system. What is being described in the article is a "public-key cryptosystem".
With that said, back in 2011 RSA was compromised, most likely by a state actor and the RSA Token system was potentially exposed.
The RSA token is a form of 2 Factor Authentication, I.e. I need 2 things to prove that I am the legitimate owner of X account. The RSA mentioned here is an algorithm for encrypting information,...
The RSA token is a form of 2 Factor Authentication, I.e. I need 2 things to prove that I am the legitimate owner of X account. The RSA mentioned here is an algorithm for encrypting information, I.e. obscuring your password to X account.
I remember learning about this in an episode of The Librarians awhile back. What a show that was.
What a blast from the past!!! I have never met another person who watched that show. I thought it was some show I invented in a dream or in my head and didn’t actually exist.
We got all 4 seasons on DVD from Ebay just last week. :) "Who are you?" "I'm the Librarian." Somewhat smarmy, intentionally cheesy, as whimsical as Willy Wonka. Loving it.
RSA the algorithm is different from RSA the company, the only thing they have in common is the name, derived from the founders of the company / inventors of the algorithm. RSA the algorithm is public-domain at this point, so RSA the company has moved on to doing other things that they can actually charge money for, like the RSA tokens that your company probably spends $$$ on.
There is a standard way of doing the "code changes every X seconds", called TOTP. If you have two-factor auth enabled on your Tildes account (or your Reddit account, for that matter) this is what it uses.
The RSA token appears not to use the TOTP standard, but this is just based on their marketing materials claiming "we're secure because we use AES-128 encryption!" but TOTP does not use AES, instead relying on an HMAC. This means the people at RSA invented their own way of doing it instead of following the standard...sigh.
The idea behind both systems is the same though - there's a secret key shared by both the backend server and your authentication fob (or the Google Authenticator app on your phone, for other uses of 2FA). That secret key is exchanged once (this is the "scan this QR code" step in GAuth) and after that never sent between client and server. Instead, client and server have their clocks synchronized (to within X seconds), and the 6-digit code you enter is based on the secret key plus the current time. This is done in a way that if an malicious party looks over your shoulder and sees the 6-digit code at time X, that won't help them log in as you if they try to impersonate you at time X + 5 minutes. Each time the code changes, it's completely unpredictable if you don't know the secret key, even if you've observed previous codes.
So your token is probably secure...certainly none of the arguments in the linked article about RSA the algorithm apply. RSA the company using their own algorithm instead of the TOTP standard is annoying, and means the proprietary algorithm won't have had nearly as much external analysis as TOTP has.
Depends very much on whether the devs were hacks who had to roll their own crypto. If you're using one of the big libraries and stick to best practices and a good key length, RSA is perfectly fine imo. The trouble is making your own. It's also not very quantum-computer secure and we have alternatives for that, so we should phase it out, but that's happening only slowly.
But that's not nearly the cybersec risk as some of the bullshit you expose yourself to by using some bigger websites that should really do better. (Unsalted md5-hashed passwords anyone?)
I'm not a CyberSec guy, just a moderately security-aware code person.
I am not taking sides, it is just interesting that the author of the blog post is taking the extreme opposite opinion.
As I said, don't roll your own. That's extremely hard and risky. Leave that to the absolute pros. And yes, there might still be bugs to be had there, but if we have a very few crypto systems that implement RSA, the number of zero-day exploits we get out of that is limited.
Look, I can go "ssh-keygen -t RSA -b 4096" and get a reasonably secure RSA key. Is that NSA-proof? Probably not. Is it very good security? I think so. As a software engineer that just needs some generic crypto without tight performance constraints (key fob could be such a case...) I can use RSA without shooting myself in the foot by just using an established implementation.
That's not to say the article is wrong. I just think it might be addressed at a different group. The post is not about which crypto to use as the end-user. It's about which crypto to use as a developer, particularly if you have special requirements. I just fail to see as much of an urgency as the author portrays.
The thing is, why use RSA when there are other alternatives that just do better? For asymmetric, you have the ellipsoid based methods as well as el gamal, that don't suffer from the issues outlined in the article. Already the usage of RSA is decreasing. TLS, for instance, no longer supports the old RSA based handshake, because it suffered from replay attacks.
Granted. If you're doing crypto these days, might as well do it right. Though I think "Fuck RSA" and "it is flat out unacceptable to use RSA in 2019. No exceptions." are just statements that are a bit too... strong. I don't see them supported. There's no good reason to throw out a proven RSA-protected system. This post doesn't call for me to disable my RSA key on github. This calls for github to offer elliptic curve encryption as an alternative and for me to use it. It also calls for developers that interface with crypto directly to use the same over RSA - which imo aren't most software devs; they'll just rely on pre-rolled solutions that encrypt password DBs or web traffic. I can say for myself that I have yet to directly interface with a encryption algorithm with two exceptions: A) RSA keygen outlined above for SSH (both SSH servers as well as github) and B) classes about crypto. IMO this confirms that the article above is addressed at a different group: Those who actually interact with crypto directly.
Not the same thing, but the same company. the "RSA Token" is a two step authentication system. What is being described in the article is a "public-key cryptosystem".
With that said, back in 2011 RSA was compromised, most likely by a state actor and the RSA Token system was potentially exposed.
Sorry cannot answer this one for you.
The RSA token is a form of 2 Factor Authentication, I.e. I need 2 things to prove that I am the legitimate owner of X account. The RSA mentioned here is an algorithm for encrypting information, I.e. obscuring your password to X account.