New encryption method idea

how about having an esoteric encryption system where the industry standard aes256 is used, but with an optional plugin system for people to add their own ciphers on top of it. Because the glowies won't have time to manually unravel EVERYONEs ciphers plus aes256. If aes256 is broken, they still need to figure out ciphers, one by one. I understand if glowies dedicate the resources to specific individuals, and you're one of those individuals, this is silly, but wouldn't this prevent mass surveillance? You could even do twofish (not just a diy cipher) over aes256 to demand more technical prowess and resources from investigators

>Because the glowies won't have time to manually unravel EVERYONEs ciphers plus aes256. If aes256 is broken, they still need to figure out ciphers, one by one. O flush

The real problem is how other would decypher your specific encryption, plus how to prevent glowies from having access to the plugin, when everyone here is a Lainon

>they still need to figure out ciphers, one by one. figuring out the cipher of someone with no understanding of cryptography is often very trivial. what you're proposing would be much worse than what we have now, i know this because its how encryption used to be. it turns out not only that most people making their own encryption algorithms had no idea what they were doing, but the grandiosity of letting developers without prior security background inflated their egos and gave them the illusion of competence and experience which they would take with them into future data breaches. as well as all of the insecure legacy systems they developed. security, as a field, pretty much developed in the wake of this

Even an expert like Schneier, who developed a blowfish program, now says not to use it. What chance would someone with no knowledge of encryption have of creating anything that couldn't be cracked in a few seconds on an average computer? It might be fun to do as a learning exercise, but I sure wouldn't trust it for practical use.

>>25462 >If aes256 is broken, they still need to figure out ciphers, one by one. .noitpyrcne TSOG esu laer gnihtemos tnaw uoy fi seiwolg eht yb detaerc saw SEA reggin bmud uoY

Where to start learning more about crypto? I found these links.,.. >https://cwe.mitre.org/data/definitions/327.html >http://www.faqs.org/faqs/cryptography-faq/snake-oil/ >http://www.faqs.org/faqs/cryptography-faq/part1/ >https://www.openssh.com/pq.html (what about a hybrid approach?) >https://mailing-list-archive.cryptoanarchy.wiki (Cypherpunk maling list)

>>25467 no one would be writing his own cipher, he would be slapping another verified cipher on top of it >>25471 >GOST hipster. Just use Curve25519 and xchacha20-poly1305 and shut up

>>25471 GOST is like kicking dead whales down the beach. Like, objectively. Kuznyechik is a better designed cipher, but still has suspicious S-box structure that Rijndael/AES lacks. ChaCha20 is the way to go if you're suspicious, as >>26895 said. To OP's point, this is a quite silly idea. One, you're introducing unnecessary perf overhead for the vast majority of threat models. A sudden break in AES (or any modern nation state's cipher) is highly unlikely, and given that Rijndael was developed independently, backdoors are highly unlikely. If your threat model presumes that nation-state crypto is backdoored, then just ChaCha20. If you presume that all modern crypto is boned, why do you think you can do better than the likes of Rijmen, DJB, etc.? If an actor can crack AES, then amateur attempts at crypto will be trivial to them. Even Bruce Schneier admits he doubts there will ever be a practical attack on AES - when he was the author of the leading competitor. This is just unnecessary and doesn't really add anything. If you're exceedingly, truly paranoid that *anything standardized* is backdoored, then swap to something like threefish and M-383 or M-511 (and their edwards equivalents for signatures). Hell, throw elligator 2 on top for extra sauce and Fortuna underneath all of it for seeding. But be forewarned - rolling your own crypto (and trusting it) is more likely to get you owned than just using well-known and validated schemes. >>26889 Katz and Lindell, Introduction to Modern Cryptography cryptohack (dot) org Cryptography For Everybody (YouTube) IACR ePrint There are a lot of resources out there, but be ready for a very, very deep dive or it's not going to be worth your time. glhf fren

>>25466 this post addresses the first philosophical issue. others touched upon the fact that you're trying to recreate the wheel. All i could recommend are one time pads. But they have a limited logical use-case. You have to be able to exchange them in person, face to face, under circumstances where you can guarantee there will be no interception of the OTP. You have to use them with airgapped machines in secure environments in order to encrypt messages. You have to ensure that the airgapped machines and OTPs are never meddled with. This is virtually impossible for most people. Exchanging OTPs via dead drops arranged via remote communications is illogical since you trust remote communications methods encryption to protect the locations of dead drops.

>>25462 https://en.wikipedia.org/wiki/Product_cipher

This makes me think that the way to best government encryption backdoors is to use ciphers backdoored by enemy nations in layers so that they each will be thwarted by the lack of the other's backdoor.

Try aes-256-cbc nested inside aria-256-ecb nested inside camellia-256-cbc nested inside kuznyechik-256-xts nested inside aria-256-ctr nested inside rc4 nested inside tea-64. Key derivation ceremony: generate a 256-bit key with diceware, hash with 200000 rounds of sha256, followed by 200000 rounds of sha3-256, feed the result into argon-2id, rotate with vigenere cipher, append the last 6 digits of the barcode of your favorite soda, feed the result back again into sha256 with 200000 rounds, and then use that to unlock the Tea encrypted file. Perform the key derivation ceremony repeatedly for each step in your Matryoshka encryption scheme, the previous decryption key is the first input into the key derivation ceremony.

Many encryption algorithms! (If country of origin isn't specified, it's USA) Public-key cryptography (classical) >Curve25519: ~128-bit security, Elliptic Curve >Curve448: ~224-bit security, Elliptic Curve >SM2/SM9: ~?-bit security, Elliptic Curve, China >RSA: variable security, Factoring Problem Public-key cryptography (post-quantum) >ML-KEM-1024, based on CRYSTALS-Kyber, module learning with errors >Streamlined NTRU Prime, based on NTRU cryptosystem, lattice based cryptography Hash functions >SHA2 (Merkle-Damgard construction) >SHA3 (Sponge construction) >BLAKE3 (HAIFA construction) >SM3 (Merkle-Damgard construction), China >Streebog (Merkle-Damgard construction), Russia Key derivation algorithms >argon2 (based on BLAKE2b function) >bcrypt (based on Blowfish, which has a Feistel network structure) >scrypt (PBKDF2 but memory hard) >PBKDF2 (applies a psedurandom function like SHA2 to an input along with salt) Authentication codes >Poly1305-AES >HMAC (any hash function like SHA2 or SHA3) >AEAD constructions (AES-SHA, ChaCha-Poly1305) Symmetric cryptography ciphers >AES-256 (256-bit security, substitution-permutation network) >ChaCha20 (256-bit security, psedurandom function based on XOR operations) >Kuznyechik (256-bit security, substitution-permutation network), Russia >Serpent (AES finalist, substitution permutation network) >Twofish (AES finalist, Feistel network) >SM4 (256-bit security, unbalanced Feistel network), China >Camellia (256-bit security, Feistel network), Japan

I personally know someone who wrote a Rust library that encrypts data with AES, breaks the encrypted data into shards and then performs additional layers of encryption with Camellia and another cipher (I forget which). I would share the URL for this thread with her to have her post her input about this topic but the autism-toons preempt considering that. She would call me an "eff ayy G" for even viewing this thread. I know there are others like me lurking on this board that like the topics but are reluctant to participate as much due to the autism toons.

>>26889 "Serious Cryptography" is a good start >>27611 be the change you want to see in the world. make good posts and report rule 3 and rule 4 violations.

That sounds like a disaster, but you can do cascading encryption instead, like so. Generate a dummy file for testing dd if=/dev/urandom of=dummy count=1000 Encrypt with age (ChaCha20-Poly1305) age -p dummy > dummy.age Decrypt with age age -d dummy.age > dummy.dec Encrypt with gpg (AES-256) gpg -c dummy > dummy.gpg Decrypt with gpg gpg -d dummy.gpg > dummy.dec Now you can combine the two Cascading encryption (encrypt with age, then encrypt with gpg) age -p dummy | gpg -c > dummy.age.gpg Cascading decryption (decrypt with gpg, then decrypt with age) gpg -d dummy.age.gpg | age -d > dummy.dec Contents of dummy and dummy.dec files should match. Optionally you can record the hashes for integrity verification. sha256sum dummy.age.gpg openssl dgst -sha3-256 dummy.age.gpg

>>27611 >Rust library that encrypts data with AES, breaks the encrypted data into shards and then performs additional layers of encryption Why? This is literally useless, AES alone is uncrackable. Failure almost always comes from key management and system integration. If you do one (1) pass with AES-256 and destroy the key, that data is gone permanently forever till the end of time.

>>27745 I mean until it's cracked or bruteforcable, right. But it smells like theatre. >>27611 >I personally know someone who wrote a Rust library that encrypts data with AES, breaks the encrypted data into shards and then performs additional layers of encryption with Camellia and another cipher (I forget which). I would share the URL for this thread with her to have her post her input about this topic but the autism-toons preempt considering that. She would call me an "eff ayy G" for even viewing this thread. I know there are others like me lurking on this board that like the topics but are reluctant to participate as much due to the autism toons. Hi! This is actually my wheel house, both in academia (Math->cryptologist PhD path) AND in application: Your friend is (probably) larping and, unfortunately, this can have some very, very terrible ramifications if their code gets used in the real world. You said "library" so I'm going to take all that entails that, there is ZERO reason to chunk ciphertext for generic usage. Compartmentalization is fantastic, but it's a very specific set of use cases for what you are specifically talking about... and if they were trying to mitigate against "AES Breaking" then they should not be using AES as part of their solution, that's just a weakened component... Nevermind that if AES breaks, it will crack civilization in half at this point. Pun intended. The last potentialy reasoning I can come up with is a defense against implmentation failure, but... That kind of complexity makes no sense for a generic library. And I mean no sense. Laying is fantastic for a robust library, but it's not a cryptographic library, the cryptographic function is a component OF the library and there is also no reason to write such a thing in the first place. And when I say no reason, I mean: DO NOT ROLL YOUR OWN CRYPTO. tl;dr: Cascading block ciphers and chunking ciphertext, in this case, is a complexity multiplier not a security multiplier. Note: I'm down to be given more information to change my tune here, but in my experience people doing what your friend is doing is usually not great. Now, if it's a way for them to learn and all that - That's actually a good thing and I take all of that back, except the cascading block chipers and chunking ciphertext -- Mostly because I want to know what their threat model is before I blindly say "YES DO IT GO GO GO"

>>27746 >I mean until it's cracked or bruteforcable, right. Im relatively confident AES will outlive me. High chance the storage medium will fail before the crypto does. If it does get cracked Im not sure I'd care about my data anymore, what with the collapse of civilization being upon us and whatnot. Regardless if someone's paranoid about it it would be as simple as putting chacha or something directly on top of the AES, no need for all those moving parts.

>>27747 >Im relatively confident AES will outlive me. This is a REALLY, REALLY safe bet honestly. >the collapse of civilization being upon us and whatnot. Another safe bet. >Regardless if someone's paranoid about it it would be as simple as putting chacha or something directly on top of the AES, no need for all those moving parts. I somewhat agree. If you need more than AES, use OTP.... and really, if you need more than AES and understand that OTP isn't perfect... Use AES-256-GCM or ChaCha20-Poly1305, because your threat model isn't god. If your thread model is just short of god,, all things perfect: OTP + Wegman-Carter for auth....Also, enjoy the fuarrrken key size. But really just AES-256-GCM is fine for the majority of use cases.