Thread 105980088

Why isn't there a larger block cypher, one bigger and better than Rijndael (AES)?

A cypher with a 256 bit data block and a 256 or 512 bit key.

Everyone says you don't need one, "just use one with 128 bit data blocks, bro". I believe that's false, if all the hardware used to train AI is used to break AES instead, it could easily achieve practical results.

I suspect there's a conspiracy going around, to keep you using low bit cryptography, so they can break it some time in the future.

>>105980088 (OP)
Because the NSA (and friends) controls encryption routines and hires everyone that has the skill to make decent ones. Encryption for the public is kept breakable on purpose so they can monitor all communications.

you mean like chacha20?

>>105980088 (OP)
ChaCha20 operates on 512 bit blocks with a 256 bit key. Threefish supports key size and block size up to 1024 bits. There's also Lion.

>>105980197
Oh and SHACAL2 has 256-bit block with 512-bit key

Personally I just stick with ChaCha20 or AES cause they're standard and had the most analysis done on them.

>>105980197
Threefist
>In October 2010, an attack that combines rotational cryptanalysis with the rebound attack was published. The attack mounts a known-key distinguisher against 53 of 72 rounds in Threefish-256, and 57 of 72 rounds in Threefish-512. It also affects the Skein hash function.[2] This is a follow-up to the earlier attack published in February, which breaks 39 and 42 rounds respectively.[4] In response to this attack, the Skein team tweaked the rotation constants used in Threefish and thereby the key schedule constants for round 3 of the NIST hash function competition.
This looks quite bad.

Lion
It's based on combining other ciphers, it's not independent.

ChaCha20
>bernstein
>pushed by google, used by everyone
Maybe they know some of its weaknesses.
>a += b; d ^= a; d <<<= 16;
>c += d; b ^= c; b <<<= 12;
>a += b; d ^= a; d <<<= 8;
>c += d; b ^= c; b <<<= 7;
Why rotate by 7 instead of 4? Why these numbers (16 12 8 7) and not prime numbers (19 13 7 5)? Why are the numbers in descending order?
The complete addition operation assumes a carry input and a carry output to chain the addition over multiple numbers. That carry could be used, either original or negated or flipped based on the key, to carry more diffusion. By using simple addition without carry you're constantly introducing a 0 bias on each operation.

>>105980236
SHACAL2
Each round does barely any operations on the state, looks sparse, it mostly moves data around.

>>105980088 (OP)
>if all the hardware used to train AI is used to break AES instead, it could easily achieve practical results.
prove it

>>105980885
>>105980885
Those sort of academic attacks exist for AES and ChaCha20 and I think some other ciphres too. They break 10 out of 14 rounds or 8 out of 20 rounds, but at enormous impractical cost and that's still not the full cipher.

>Bernstein
>Google
I don't know why that's a bad thing necessarily. Is more obscure better in your opinion? Or what would be more trustworthy in your view? For what it's worth, Bernstein didn't come up with it whole cloth, he just tweaked Salsa20. You can tweak it again if you feel your design is better.

Here's a link where the rationale behind the numbers is discussed: https://cr.yp.to/chacha/chacha-20080128.pdf

>Sparse
Is that necessarily a bad thing? In the Argon2 paper the authors say that simpler functions are better because they're easier to analyze and harder to mess up and introduce vulnerabilities inadvertently.

>>105980120
>there is no autistic schizo that would spot something weird in open and public / common encryption ciphers
I think your take is attempting to sound smart but falls in the retarded category

>>105981358
>>105981243
I read it and it's basically
>salsa is doing something
>I change it so it looks simpler
>"difference in security appears to be negligible"
Bruh

>>105981438
ChaCha diffusion is better (12.5 bits difference in output per 1-bit change in input vs. Salsa's 8 bits) but changing the rotation distances had negligible impact, is what I got from that.

>>105980885
the common reason to not use carry results is that there are no SIMD instructions with them

>anime
cringe

>>105980197
Also ChaCha20 is not a block cipher but who's counting.

>>105981243
>You can tweak it again if you feel your design is better.
Also probably NOT a good idea to this lol. At least the standard advice is don't roll your own crypto.

>>105980088 (OP)
>he doesn't know about Threefish

>>105981358
If such a person came here to announce he'd broken some encryption widely used this is what would happen:
>you'd call him a schizo
>his thread would get instantly slid while demoralization shills paid for by the state would bully him
>he'd get a knock at the door
>glow niggers would offer him a job
>if he refused and posted online that the glow niggers visited him you'd call him a schizo
>he's publish post on multiple platforms announcing that if he's anhero'd he'd never do such a thing, isn't sad but is in fear of his life
>the state would black bag him
>the state would stage an anhero
>you'd all laugh and call him pathetic
>years later a handful of people would post about him now and again (RIP Ian)
>you'd call them schizos

Tell me I'm wrong.

>>105981243
Bernstein made Salsa20 too. He also came up with commonly used elliptic curves in public key cryptography.

>>105980885
>Why these numbers (16 12 8 7) and not prime numbers (19 13 7 5)?
524288, 8192, 128, and 32 arent prime numbers, anon...

>he doesnt know bitshift is defined in terms of mul/div 2^rhs

>>105983021
You rotate by a prime number of bits, not by half/quarter of the data type.

>>105983036
congrats, you have the reading comprehension of a brain damaged turtle

>>105980088 (OP)
Block size isn't very relevant to the security of a cipher.

>>105980088 (OP)
>He thinks AES 256 is realistically breakable

kek

>>105981640
>being this butt hurt
You silly boy! :3

>>105980088 (OP)
use case for strong cryptography????

>>105984595
use case for your existence?

>>105980088 (OP)
what a cutie pie

So, besides the algorithms listed above, are there really no other block ciphers with 256 bit blocks and 256 or 512 bit keys?
Also, looking at the way ciphers are internally designed, I firmly begin believing there's some kind of inherent undisclosed weakness in them.

>>105982339
>you'd all laugh and call him pathetic
There's two possible scenarios. Either he's right in which case he is a pathetic retard to making the same mistakes dozens have made before him or he's a larping nigger in which case he is also pathetic if for different reasons. Either way I do not give a shit and neither does anyone else.

>>105980088 (OP)
there are. normal ass TLS can go up to 2048 iirc, just no one uses it except for banks and FetLife.COM
"analog" encryptors are still around and use keys of arbitrary length that you can generate yourself. Picrel is a Network Object(tm) but outputs to serial if you want and also uses fuckhuge keys

>>105980088 (OP)
>block cipher
ngmi
Stream ciphers are where it's at.

>>105982339
if it was true he would provide proof (or the proof that he was able to benefit from his findings which would only be possible if what he claims is true) and the information would be widely known in all countries in all fields, private, public, maths forums, etc
retard

>>105985548
>Also, looking at the way ciphers are internally designed, I firmly begin believing there's some kind of inherent undisclosed weakness in them.
Why

Anyone thinking 512 bit keys is reasonable has no idea what they are talking about not how huge that is.
Even 256 bit AES is fine against quantum computing.

After looking at bouncycastle API which seems to be the most comprehensive crypto library in terms of including various ciphers, other ciphers that may match OP's wants are: Kalyna, RC4 (seems to have suspected weaknesses), HC-256, VMPC and ZUC.

If none of these are good enough for you you'll have to roll your own crypto which is heavily advised against from what I've seen.

https://javadoc.io/doc/org.bouncycastle/bcprov-jdk14/1.74/org/bouncycastle/jcajce/provider/symmetric/util/BaseBlockCipher.html

https://javadoc.io/static/org.bouncycastle/bcprov-jdk14/1.74/org/bouncycastle/jcajce/provider/symmetric/util/BaseStreamCipher.html