What's your favorite encryption algorithm?

I'm trying to find an encryption algorithm secure and suitable enough for a password manager.

>>30317 Ferguson, Schneier, and Kohno's Cryptography Engineering: Design Principles and Practical Applications claims Serpent is "built like a tank". It also claims that Serpent is more secure than Twofish, which is in turn more secure than AES. Do not use DES.

>>30317 AES should be fine. I don’t know about what the Lainon above said but it’s on a book so it must be true.

bcrypt with cost level 4. i'm not convinced anyone needs higher than 4 like many redditors/stackexchangers are suggesting, if a user is dumb enough to choose a password like "apple" or "password123" that's not my problem. bcrypt level 4 takes practically infinitely longer to brute force than what big corporations like yahoo and popular CMS's like wordpress are still using (md5, sha256) for password hashing

>>30322 >bcrypt with cost level 4. i'm not convinced anyone needs higher than 4 like many redditors/stackexchangers are suggesting, if a user is dumb enough to choose a password like "apple" or "password123" that's not my problem. It's not always the user's choice. There are still many services that require weak passwords. I've seen maximum password lengths of 8 with special characters forbidden in the wild multiple times.

>>30317 I would use Twofish.

Use 3DES. Well designed and battle tested.

At one point, there were a whole bunch of candidate block ciphers competing for the title of the new AES algorithm. The one that won is the one used widely today is Rijndael. As the other anons have mentioned there is Twofish and Serpent. If I recall correctly, I believe Rijndael barely beat Serpent on the grounds of shorter time to actually output the computed ciphertext since Rjindael uses fewer rounds than Serpent. https://www.cl.cam.ac.uk/~rja14/serpent.html But do not use DES. It's key size is way too small to be secure against modern hardware. I think even 3DES with its tripled key size is still considered weak by today's standards. I think AES is most likely fine for your purposes. You can always opt for more rounds, which could bump the key size up to 256 bits for 14 mixing rounds). Idk though. Talk to a competent cryptographer for a more informed opinion.

I am a fan of the ChaCha family of ciphers, just because they're so simple. Generally you should use some memory-hard hashing algorithm for creating a 'master key' from the password, then use a strong conventional cipher to encrypt the actual database.

>>30326 Ran into this while volunteering in-person recently. I was more confused than anything.

>>30329 i know this is probably satire, but still, this is a bad idea, do not do this.

>>30317 AES256 is my go-to for all encryption purposes. I built my own password manager and use 128 since it's faster, but if you have good enough hardware it won't make a difference.

>>33282 3DES is still secure, but is being phased out for better things. DES/2DES are deprecated.

If considering 3DES, make sure to know the limitations. https://sweet32.info/SWEET32_CCS16.pdf

aes-gcm or chacha20-poly1305 to encrypt the passwords argon2/scrypt for the hash of master password (so you can derive keys from it later on) but i advise you to research more about cryptography before jumping in to a complex project like a password manager there's lots of stuff to be careful about in cryptography

If it needs to be safe forever and you're very worried, don't use one algorithm. Use three.

>>33401 This isn't actually meme advice. Because of how security properties are defined for block ciphers (and generally for block cipher modes of operation), if you run two insecure ciphers and one secure cipher you'll still get security. But this doesn't excuse using known insecure ciphers since it's just a waste of cycles.

>>31216 ChaCha20 is incredibly simple to implement, and is very nice on platforms lacking native AES instructions, but the BLAKE family that's based on Salsa/ChaCha20 is a very good choice as well since it takes full advantage of 64bit CPUs https://github.com/BLAKE3-team/BLAKE3

Simon and speck because they're very simple and fun to implement generically. 12 bit words permits use of the n word as a 4 word key, so I use simon<12, 4> as a psuedorandom permutation to make human readable names from 3 byte database id's. Cryptographically useless, but fun.

>>30317 AES is going to be the most performant (though thats generally because of CPUs having builtin extensions to assist in execution.) There was some controversy about potentially diddled primes with it that seems to have been memoryholed so some people are concerned about it, but ignoring that cracking 256 bit AES with conventional PCs should be physically impossible. Really any of the algorithms VeraCrypt uses are a good choice

I don't care about symmetric algorithms. AES already solved the problem. Elliptic Curves are the soykaf. RSA is pretty stupid. Imagine needing a 2000+ byte key for adequate security

>>34101 2000+ bit, or 256 bytes not to dissimilar to ECC

I use sha3 in an 11-round Feistel network.

>>34102 ????? 3072 bit RSA for a security parameter of 128 vs 256 bit ECC for a security parameter of 128.

>>34101 AES is a decent compromise between security and speed when you have good software and hardware support, but it's not the best software-only cipher and not the best hardware-only cipher (pretty much any of the ESTREAM ciphers in either category beat it in terms of performance/security ratio) Block ciphers in general are kinda crap except for specific applications.