BRUH THEY'RE DEPRECATING DH https://defcon.social/@infosec/117516999211815499
0 Boosts
0 Likes
@hipsterelectron Hybrid is still allowed; this isn't the final implosion. I'm not keen on "post quantum only" schemes. Then again I have (unsubstantiated) bad feels about aes no matter how you keyed so.
@d_rift block size and the existence of blocks at all is a huge problem, i have a symmetric encryption scheme that does not do this
@d_rift you're correct that they are leaving some very small breathing room but practically speaking every TLS implementation is gonna do some fucking awful shit like just dropping the DH secret and i think this deprecation cycle is far more significant for what it portends which is that the US state has had quite enough of secure communications (see for example the signal move to a completely novel and untested "post-quantum ratchet" based upon an entirely new theory i still can't make heads or tails of)
@hipsterelectron Yeah I haven't wrapped my head fully around signal's new drippy ratchet either. I already don't trust them unrelatedly (and yet still have to recommend their app for most people and purposes because statistically more people get in trouble by not using it) so it hasn't been high on the priority list. Finding an alternative recommendation, otoh...
@hipsterelectron I'll be curious how you got around using blocks. They've always seemed like a half measure, but, I couldn't figure out halfway to what.
@d_rift well i'm putting compression out of the picture for now and sticking to invertible transforms of unstructured serial bit strings. a bit is a block that can't be transposed, only substituted (flipped). the problem with blocks is that they do not share information outside the fixed block—stream ciphers only share information left to right and not e.g. right to left. the answer i have for this is using a random bit stream to randomly split up the message into random sized blocks and invert some of them and then to reorder the random-sized blocks. invertibility is trivial but constructing it may require more information than merely reading the random bits of the key in reverse—not sure yet
> a bit is a block that can't be transposed, only substituted (flipped)
WAIT, can we add each bit to the bit of the same position in the key (we destroy the carries, like Mike Flanagan), repeating the key as maby times as needed (appending it to itself) so that we get a reversible encryption algorithm with arbitrary stream bitlength?
@mooooooo @hipsterelectron This would be a plain XOR and have issues including exact repeat of bit patterns if cleartext data recurred at the same offset relative to key length.
@d_rift @hipsterelectron oh dang, not me thinking I ate when I re-came up with one of the toy examples 
@d_rift @hipsterelectron Wait, sorry for wasting your time, but I had another idea and I would like reviews on it
1. Perform AES normally.
2. Shift the resulting data by N1 bits, treating it like a circular array. N1 is in [1, 128) and should not be a power of two.
3. Repeat steps 1 and 2 N2 times.
N1 and N2 are new secret numbers.
Is this bad?
@mooooooo @d_rift yes this is a valid way to address the aes block size issue. if you are familiar with AES though i just think the entire concept of the fixed box is totally wrong because fundamentally you can put whatever hot sauce you want in each S-box it's still only going to map 128 bits to another 128 bits and that's why AES attacks are always key recovery attacks. my approach here is super anarchist about it and decides instead of using AES as a basis at all to decide that making the boundaries between boxes hard to discern is the fundamental primitive of security, hence randomly splitting them up
@mooooooo @d_rift oh also relevant my screed upon compression and UTF-8 https://codeberg.org/cosmicexplorer/corporeal the boundaries between bytes must be shorn and making blocks a multiple of 8 means UTF-8 boundaries will always nicely align to the AES block boundary. that absolutely must be destroyed
@mooooooo @d_rift i believe the purpose of a CSPRNG is to generate arbitrary length output from a fixed length input and i would not accept ways to generate a keystream of arbitrary size that do not conform to the requirements of a CSPRNG. hence just making the key "however long you want", generated from a fixed-size key input
@mooooooo @d_rift note that this neatly also generalizes the concept of rounds into the concept of blocks along with merging the concepts of a CSPRNG and block cipher modes. all of these things have terribly informal definitions (yes you heard that right) that are not serious attempts to provide information theoretic security
@mooooooo @d_rift the theory of CSPRNGs suck too most of them just run AES on an input block repeatedly. this makes the security of AES dependent upon a "random" stream which is itself AES. preposterous! as it turns out lattices are actually a good CSPRNG (i discovered this independently from dwork) and i think we can use that. the only really new theory i have is this symmetric one
@hipsterelectron @mooooooo
> most of them just run AES on an input block repeatedly
:emits pained noise: yes let's not do that please
@hipsterelectron wish they'd deprecate DHH instead