README aes-gcm choice text is stale

[fingon]

• Mac doesn't have 0.9.* openssl anymore (for years, but I'm too lazy to check when this changed)

On 14 - Sonoma (= 2023 version):

mstenber@hana ~>uname -a
Darwin hana.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000 arm64
mstenber@hana ~>where openssl
/opt/homebrew/bin/openssl
/usr/bin/openssl
mstenber@hana ~>openssl --version
OpenSSL 3.3.2 3 Sep 2024 (Library: OpenSSL 3.3.2 3 Sep 2024)
mstenber@hana ~/temp>/usr/bin/openssl version  
LibreSSL 3.3.6

• The link to why aes-gcm is broken in OpenSSL is also broken. However, I can see why this might be bad idea as default, e.g. https://superuser.com/questions/1824093/command-line-decryption-of-aes-256-gcm-no-longer-working-after-openssl-updated

fwiw homebrew installation of current openssl doesn't support aes-gcm; system LibreSSL one does though:

mstenber@hana ~>echo foo | openssl enc -aes-128-gcm -pass pass:x
enc: AEAD ciphers not supported
enc: Use -help for summary.
mstenber@hana ~>echo foo | /usr/bin/openssl enc -aes-128-gcm -pass pass:x
bad decrypt
Salted__...

Having said that, I think having a default which just 'works most likely' is probably better than having the results authenticated (with caveats about where it works).

[jmurty]

For clarity, you're referring to the "Cipher Selection" portion of the README?

This is definitely stale, it dates back over 11 years to when transcrypt was first released. The world has moved on since then, though macOS compatibility somehow remains a pain. It's unfortunate that installing an up-to-date OpenSSL version with Homebrew would break use of that cipher.

No-one has expressed interest in – or problems with – using GCM mode in the years since I've been the maintainer of this project. I'm tempted to remove that section of the README altogether, although perhaps rewriting it to simply acknowledge that transcrypt does not avoid the malleability problem would be better. What do you think?

[fingon]

Yes, that is what I was referring to.

I think mentioning the malleability problem ( given default settings ) still would make sense. Usually describing security considerations of defaults helps users make educated choices.