17 ms·
That just isn't true. As an obvious counter example, asymmetric encryption (gpg,et. al) is very slow. Which means that if I need to encrypt a lot of data at re
by smanek 17y ago
That just isn't true.
As an obvious counter example, asymmetric encryption (gpg,et. al) is very slow. Which means that if I need to encrypt a lot of data at rest it sometimes makes sense to use a symmetric cipher.
Security (even just the subdomain of encryption) isn't that easy - there is no one-size-fits all solution.
- gustavo_duarte 17y agogpg can do symmetric encryption: http://www.gnupg.org/documentation/manuals/gnupg/Operational-GPG-Commands.html#Operational-GPG-Commands http://www.gnupg.org/documentation/manuals/gnupg/Operational... There are a few algorithms to choose from.
- deleted 17y ago[deleted]
- tptacek 17y agoGPG is a program. It isn't an algorithm. Consider reading it before you propose alternatives, which are likely to be broken. Like I posted upthread, there's a laundry list of things that program is going to give you besides picking a better algorithm than "Triple DES" and a better block cipher mode. But listing them is just begging for a bunch of people to propose wack-ass alternative solutions that other people will feel obliged to waste time knocking down.
- deleted 17y ago[deleted]
- mindslight 17y agoThe tiny exception to tptacek's rule is * you know specifically why SSL/GPG falls short of your requirements * you realize that algorithms are only a single part of crypto system design * you know the exact security ramifications of the details (not just "ecb is bad") * the encryption capabilities are the critical aspect of your whole system (like freenet) AND * you accept that your implementation will be broken (at least) several times But indeed if you know these things, you know that "use SSL/GPG" is good canonical advice.