huven

Lots of them, this is in production 😄 I attached the debugger (after the UI switched back to the hosting app) just to verify that the extension is still running...

One more vote for keeping Keccak around, I'm currently implementing compatibility support for [proxycrypt](https://sourceforge.net/projects/proxycrypt/) which uses Keccak.

Try setting SPACESHIP_SCREENSHOT_UPLOAD_TIMEOUT environment variable to 1, does that make a difference? https://github.com/fastlane/fastlane/blob/b61548cdd398a13aa7b99f915e57bebe54137d35/spaceship/lib/spaceship/connect_api/models/app_screenshot.rb#L112

Just for the record, as they are already listed under "kept for Botan4": +1 for CRC32 and also +1 for Streebog I need both for providing a VeraCrypt compatible implementation...

Here is a command line script to reproduce the decryption failure, output matches my other implementation (using Botan library). ``` export KEY=`echo -n 1234 | argon2 "$(head -c 64 test_argon2id.hc)"...

Here is third library producing the same derived key: ``` from argon2.low_level import hash_secret_raw, Type import sys password = b"1234" with open("test_argon2id.hc", "rb") as f: salt = f.read(64) key =...

I think I tracked down the cause of the issue. In Volumes.c there is this logic (in two locations): ``` derive_key_argon2(keyInfo->userKey, keyInfo->keyLength, keyInfo->salt, PKCS5_SALT_SIZE, keyInfo->noIterations, keyInfo->memoryCost, dk, GetMaxPkcs5OutSize(), &abortKeyDerivation); ```...

Just noticed that in `ReadVolumeHeader` the `derive_key_argon2` call is outside the ea-loop. I previously focused on `CreateVolumeHeaderInMemory` which knows the ea when deriving the key. So that would require refactoring...

Thanks @fzxx that's an interesting sourceforge post. I will reply to that post on sourceforge to keep this issue focussed.

That's exactly why I reported this in an early stage, it's now or never. Apart from a cascade of 4 ciphers, it already becomes relevant when just one 512-bit cipher...