オタクによる反戦デモの主催者が自称オタクなんで そろそろ正体を明かす時が来たようだな 自分がオタクの証拠はこれです これくらいでどうっすかね？ #オタクによる反戦デモ #オタクを政治利用するな #高橋裕行

YouTube video by ThreeFishVEVO

オタクによる反戦デモの主催者が自称オタクなんで そろそろ正体を明かす時が来たようだな 自分がオタクの証拠はこれです これくらいでどうっすかね？ #オタクによる反戦デモ #オタクを政治利用するな #高橋裕行 https://t.co/AXD3asDQwL

JohnDose: > FYI, the software supports the following algorithms for file and text encryption: AES(256), RC6(256), Serpent(256), Twofish(256), GOST28147(256), Blowfish(448), Threefish(1024), SHACAL-2(512), and the Paranoia C4(cascade of 4 algorithms). The algorithm choice is not job of the user. Any modern tool needs opinionated cryptography, i.e. the author shows their expertise and pick the most secure option Serpent and Rijndael I.e. AES are both SP-network ciphers. While Serpent was slightly stronger than Rijndael on paper, the latter has seen MUCH more cryptanalysis over the past two decades. That’s why you’d want to trust AES instead. What matters more is how you deploy your AES, e.g. ECB is broken, and GCM is best practice. But AES requires hardware acceleration / native instructions to protect from cache timing attacks. Serpent also has its own S-box but no CPU can run it efficiently (if at all) in constant time. So if the platform support includes devices without AES-NI, using ciphers that don’t require native instructions, like ChaCha20-poly1305 make much more sense. Threefish uses 512 bit keys but unless you deploy pre-shared keys, the key exchange like ML-KEM1024 will set the security margin as the weakest link. It actually gets worse, more about that below. Plus we don’t really need 256-bit security margin against Grover, AES-256 has more than 128 bits of security against Grover in practice (see Valsorda’s recent blog posts). Also with it’s minimal cryptanalysis, it makes less sense to use threefish even when I trust Schneier and his expertise. It’s unfortunately not up for him at this point. RC6, Twofish, Blowfish and SHACAL are also much more obscure and less reviewed. GOST is a Russian cipher, you don’t want to even offer it. The cascading ciphers make no sense, as all ciphers will use a key that in the best case come from your OS kernel CSPRNG. For Windows that’s AES, for Linux that’s Chacha20. Since both are 256-bit algorithms, that will cap the security of bigger keys like Threefish, where you need to force user to wait 301 seconds on Linux for the OS to reseed the CSPRNG, to generate second half of the key from independent entropy. If the cipher used in the random number generator has a vulnerability, that’s enough to break all four distinct ciphers. Even if the RNG is fine, and you use different cipher from the CSPRNG, you now have second point of failure that can fail independently. This is why I prefer to minimize trust in primitives: Linux RNG is ChaCha20 based, so I need to use and trust ChaCha anyway. So I use XChaCha20-poly1305 as cipher, and ChaCha based hash function (BLAKE2b) and BLAKE2-based PHF (Argon2id). These are considered high end primitives and due to their popularity they receive majority of the attention. Also, poly1305 is a Wegman-Carter MAC so it’s probably secure if ChaCha20 is secure, which is much better than AES-GCM’s GMAC that has a paper about it’s fragility which means trouble when implementing. Dont get me wrong, I’ve also been where you stand, unable to decide, implementing cascading encryption and robust combiners for hash functions, but none of that is needed. Your main problem will be key management, correctness of implementation, and software security in general. Cipher choice is best left as “boring but best practice” because they already provide an abstraction to the “super duper extra ultra high security”, it’s just not called that by reserved academics who prefer to use the term “computationally secure”. Also like Snowden said, NSA won’t break ciphertexts. They will hack your computer and bypass the encryption.

Thanks for sharing your insight. In case you haven’t read, detailed specifications of file encryption can be found here: S.S.E. File Encryptor - Format Specifications According to that page, all ciphers operate in CTR mode. (which is probably less desirable than GCM? Idk) maqp: > Threefish uses 512 bit keys but unless you deploy pre-shared keys, the key exchange > like ML-KEM1024 will set the security margin as the weakest link. It actually gets worse, more about that below. Threefish can use key size of 256, 512, or 1024 bit (which are equal to block size). This software in particular, uses the 1024-bit version (as written in the bottom of my post)