4 ms·

The rationale mentioned here https://peps.python.org/pep-0594/#crypt https://peps.python.org/pep-0594/#crypt Highlight: > Only DES encryption is guaranteed to

The rationale mentioned here https://peps.python.org/pep-0594/#crypt https://peps.python.org/pep-0594/#crypt Highlight: > Only DES encryption is guaranteed to be available. DES has an extremely limited key space of 2*56.

frognumber 3y ago
It's a bad reaction to a real problem. A good solution would: * Puke warnings on the screen when using insecure algorithms * Guarantee secure algorithms everywhere These algorithms aren't hard to implement, and anything relying on DES will be faster in interpreted Python than in optimized code on the 80486 it was intended to run on. I'd rather have this removed than broken, but it makes sense to just fix it. As a footnote, a lot of code doesn't rely on this for anything high-stakes. If this is hashing passwords on my local machine, it's a backup to a backup for security. It should move to something modern, but it breaking in the meantime is a bigger failure than an obsolete crypto algorithm.
- criddell 3y ago
  > These algorithms aren't hard to implement As I understand it, they are difficult to implement securely. By that I mean avoid side channel (often timing) attacks.
  - miohtama 3y ago
    PyPi has robust cryptography libraries from likes of Google, others. You do not need to implement them yourself. You can just install a well-known library used by the best in the software development industry.
- maxbond 3y ago
  Cryptography should fail to operate rather than operate insecurely. There's also a lot of precedent for removing these security footguns from the stdlib that no one actually uses. From the top of my head, the `imgop` library and the `cgi.escape` function. (My personal bugbear is `csv.Sniffer` which, as far as I can see, has no correct use case, it's just broken.) I'm somewhat out of touch with Python, but as far as I know, it's been best practice to use `cryptography`[1] for a long, long time. ETA: Just to note - DES is super, super broken. It shouldn't even be an option. DES was published in 1975. 3DES was published in 1981 - DES has been considered too small a keyspace since 1981. That's older than Python. Exporting DES in your crypto API is a bug. (Apparently, according to Wikipedia, NIST has deprecated all use of DES [including legacy applications] as of 2023. But they only deprecated new applications in 2017, so perhaps I overstate.) [1] https://cryptography.io/en/latest/ https://cryptography.io/en/latest/
miohtama 3y ago
Better late than never
hedora 3y ago
"Guaranteed to be available" isn't the same as "available in practice". Linux's current crypt function provides yescrypt, gost-yescrypt, scrypt, bcrypt, sha512crypt, sha256crypt, sha1crypt, sunmd5, md5crypt, bsdicrypt, bigcrypt, descrypt and NT (ordered by decreasing strength). https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en... So, if you're on an ancient unix box (or a Mac, apparently), then you're stuck with the obsolete standard library your OS vendor packaged, but that's true of other things. Presumably, they'll remove SSL support soon too, since, when provided with a sufficiently old version of openssl support, it won't provide modern algorithms either. That means "only obsolete SSL modes are guaranteed to be available".

frognumber 3y ago

It's a bad reaction to a real problem. A good solution would: * Puke warnings on the screen when using insecure algorithms * Guarantee secure algorithms everywhere These algorithms aren't hard to implement, and anything relying on DES will be faster in interpreted Python than in optimized code on the 80486 it was intended to run on. I'd rather have this removed than broken, but it makes sense to just fix it. As a footnote, a lot of code doesn't rely on this for anything high-stakes. If this is hashing passwords on my local machine, it's a backup to a backup for security. It should move to something modern, but it breaking in the meantime is a bigger failure than an obsolete crypto algorithm.

criddell 3y ago
> These algorithms aren't hard to implement As I understand it, they are difficult to implement securely. By that I mean avoid side channel (often timing) attacks.
- miohtama 3y ago
  PyPi has robust cryptography libraries from likes of Google, others. You do not need to implement them yourself. You can just install a well-known library used by the best in the software development industry.
maxbond 3y ago
Cryptography should fail to operate rather than operate insecurely. There's also a lot of precedent for removing these security footguns from the stdlib that no one actually uses. From the top of my head, the `imgop` library and the `cgi.escape` function. (My personal bugbear is `csv.Sniffer` which, as far as I can see, has no correct use case, it's just broken.) I'm somewhat out of touch with Python, but as far as I know, it's been best practice to use `cryptography`[1] for a long, long time. ETA: Just to note - DES is super, super broken. It shouldn't even be an option. DES was published in 1975. 3DES was published in 1981 - DES has been considered too small a keyspace since 1981. That's older than Python. Exporting DES in your crypto API is a bug. (Apparently, according to Wikipedia, NIST has deprecated all use of DES [including legacy applications] as of 2023. But they only deprecated new applications in 2017, so perhaps I overstate.) [1] https://cryptography.io/en/latest/ https://cryptography.io/en/latest/

miohtama 3y ago

Better late than never

hedora 3y ago

"Guaranteed to be available" isn't the same as "available in practice". Linux's current crypt function provides yescrypt, gost-yescrypt, scrypt, bcrypt, sha512crypt, sha256crypt, sha1crypt, sunmd5, md5crypt, bsdicrypt, bigcrypt, descrypt and NT (ordered by decreasing strength). https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en.html https://manpages.debian.org/unstable/libcrypt-dev/crypt.5.en... So, if you're on an ancient unix box (or a Mac, apparently), then you're stuck with the obsolete standard library your OS vendor packaged, but that's true of other things. Presumably, they'll remove SSL support soon too, since, when provided with a sufficiently old version of openssl support, it won't provide modern algorithms either. That means "only obsolete SSL modes are guaranteed to be available".