Today, we answer some reader questions about secure credential management, the benefits of ChaCha and BLAKE2 over AES and SHA2, and fault attacks on EdDSA.
Astute readers have noticed that our blog posts have decreased in frequency this year. We put a heavy emphasis on quality, not so much on quantity.
At the same time, we field a lot of questions on social media, where our answers (and, sometimes, the questions themselves) are difficult to locate, especially when people close or lock their accounts.
With both of these thoughts in mind, I asked my Twitter followers if they'd be interested in a Q&A-style blog series. I expected maybe a 55:45 split on yes/no responses, but the final tally was overwhelmingly "Yes".
So with that in mind, I'd like to introduce the pilot for our new series, Slice of PIE.
Earlier this year, the World Wide Web Consortium (W3C) and FIDO Alliance shared their latest drafts for a standard Web Authentication API called WebAuthn.
Our security team took an interest to this proposal since WebAuthn would be used in conjunction hardware two-factor authentication devices. Hardware 2FA has proven to be far more resilient against phishing attacks than HOTP or TOTP (meanwhile, SMS-based 2FA is essentially security theater; avoid like the plague).
Despite the importance of WebAuthn to web security for the years to come, our analysis of the standard reveals a lot of concerns that almost any cryptographer should have been able to identify and remedy earlier in the design phase.
Regardless of whether this was a failure of the W3C and/or FIDO Alliance to enlist the aid of cryptography engineers, or of the cryptography community to be more proactive in preventing the deployment of error-prone cryptographic designs, there is only one path forward; and that is to fix the design of WebAuthn before it's set in stone.
Asymmetric cryptography (also known as public-key cryptography) is widely misunderstood.
Most non-cryptographers don't understand asymmetric cryptography at all due to the lack of a relatable, real world analogy they can reference.
Conversely, most cryptographers don't seem to understand how and why developers use asymmetric cryptography in their own software.
I believe solving both problems (first, assisting developers understand what asymmetric cryptography is and how it works; but also, ensuring cryptographers understand the business needs that lead to the inclusion of asymmetric cryptography in software) will lead to all-around better cryptography designs and non-catastrophic asymmetric cryptography deployments.
The shortest answer to any question about securely using RSA is: Don't.
Because there are much better cryptography choices available today, if you can avoid using RSA, don't use RSA. Then everything else in this document becomes not your problem.
Throughout this post, we assume at least a casual understanding of what RSA is, and the role of asymmetric cryptography in general.
If you do not meet these prerequisites, or experience any difficulty understanding the rest of this post, this is a good introduction to RSA and this talk by Colin Percival (slides) is a good follow-up. If you're more of a book learner, you can't go wrong with a copy of Serious Cryptography by Dr. Jean-Philippe Aumasson.
Will tomorrow bring costly and embarrassing data breaches? Or will it bring growth, success, and peace of mind?
Our team of technology consultants have extensive knowledge and experience with application security and web/application development.
Want the latest from Paragon Initiative Enterprises delivered straight to your inbox? We have two newsletters to choose from.
The first mails quarterly and often showcases our behind-the-scenes projects.
The other is unscheduled and gives you a direct feed into the findings of our open source security research initiatives.