@EllaRose speccccc I am writing spec stuff I neeeeedddd speeeeccccccccssss

@Biv I tend to prefer to focus on actually building things. I barely find the patience to transcribe my notes into a computer algebra program, and every single time I do (possibly after correcting the transcription, but not the formula) it just confirms my result I got by hand

I pretty much can only be bothered to give proof if I'm being paid to lol

@EllaRose suggested round count? de-correlation layer? padding strategy?

@MickLH Sorry, been a hectic day. Ok, let me see

this latest design eliminates the question of round count: github.com/erose1337/crypto/blob/master/streamcipher2.c

but let me think

about padding and stuff

I don't think the stream cipher design requires padding

the block cipher one does

if you want to use that one

I would feel bad giving you a number for a round count as I haven't done the math with the branch numbers and whatnot to calculate how many rounds are required to guarantee immunity to linear/differential attacks

How about key reuse and IV guidelines?

Implementors don't want to have to figure these details out! it's engineering type of thinking.

well, the good news is a 128 bit prp should be able to produce plenty of output to not be of a concern, and that's the smallest size (16 x 1).

How about message authentication, is there a cool tricked out place I can stash the MAC?

and can I use PCBC chaining mode?

I apologize, I'm not sure if you're aware, but this stuff is all basically scratch paper to me, most of them anyways. They're just designs I'm eliminating on my road the simplest, most obviously correct solutions. I have over a dozen of them that have no name, let alone formal description or anyone using them. I'm thinking the later stream cipher design may have nonce misue resistance properties, but I certainly haven't evaluated them.

but that's why there's no comments, no documentation, and certainly no formal spec

lol don't worry I'm bombarding you with questions :P

it's ok

I was thinking about authentication but I haven't found an appropriate solution besides xor macs maybe. They require a prf, which normally is a fully fledged hash function or truncated block cipher. I'm not sure if an application of the prf in that cipher would be "good enough" for this purpose, as I conjecture it's not that hard to produce a second preimage

so til such a time, I'd recommend a tried and true solution: Either break the messages into blocks and use GCM, or use good ol' fashioned HMAC

obviously I'll use HMAC! lol

GCM you crazy? tortureeee

I could make a sponge construction which would provide you with authentication with 1.5 primitive invocations, but the efficiency of the primitive would be modified also and idk if the additional complexity would save you time

I just feel warm and fuzzy with standalone authenticated encryption, instead of authenticating an encrypted datagram

me too MickLH, me too

<3

Oh, the decorrelation layer was merged into the prp

I'm curious if the latest design can achieve higher throughput then the old one... did you say something about GPU implementation?...

yes

since it's a stream cipher and the keys are seeded, we can't cache them this time :x

If you structure it in a way where I can start computing stuff for the first and last byte both in parallel, you'll have a blazing fast GPU implementation

but like I said, it should be less function invocations and just longer loops

I don't know how possible that will be

it was designed with the goal of inability to isolate any of the steps and work on them separately

One thing I've thought about is an "interleaved key schedule"

enlighten me?

The idea would be to expand one key into say 10 keys, and then use them for groups of 10 blocks

So that you can run even the least parallel algorithm at 10x wide

Well, you could always run 10 separate instances of any algorithm with different keys though. That sounds like something more at the key management level then inside a cipher?

Re-interleave the 10 streams after decryption

Oh I see

It seems superficially similar to counter mode

yes it does

I need to get over my fear of counter mode, I'm afraid if I touch it then everything will fall apart

And ECB... pretty sure if I encrypted "Hello, World!" in ECB mode it would leak my unrelated private keys somehow

Well, I thought it would be cool to have a cipher that was both tweakable and authenticated

cause then, even if the only option was ECB mode, you'd still be secure

@EllaRose there are blockciphers which are tweakable (there is a paper on how to build modes on this) and there are constructions to make any cipher tweakable

as for the cipher Threefish would be the obvious choice I guess

Holy cow the terminology in that paper is so dense

so many acronyms for exotic modes that I have never even heard of

@EllaRose Why can't I just use a propagating block chaining mode, and put a shared secret in the last block, and feel authenticated?

FYI everyone here: RFC7905 finally standardizes the ChaCha20-Poly1305 cipher suites.

@MickLH I made up a mode that worked kinda like that (judging by the sound of it), but the secret went into the first block initially, and every block after that. Unfortunately I didn't think it through thoroughly enough with the IV, and for a decent sized mac tag and a "normal" sized block cipher, it isn't much more efficient then just using HMAC.

has 777 rep

let's get lucky :o

The way I see it, because of the overhead of setting up a different algorithm, just having a built in HMAC provided by the block cipher is already a benefit

that's something I didn't think about, but is true

I have wondered sometimes

about the difference between crypto in theory and crypto in practice

like, I don't use CTR mode because in practice, storing the state for the counter is a bitch

it's so much more convenient to just say iv = os.urandom(16)

or better, iv = os.urandom(32)

especially when it comes to constrained resource devices

I was also wondering about getting associated data in there by running the cleartext part through as if it were encrypted, but then sending the cleartext instead of the ciphertext, and using a chaining mode that will screw up the rest of the blocks if the cleartext data is tampered

Would be convenient to basically just ram the (packet || shared secret) into the block cipher and get everything or nothing at the end

Maybe it could be formalized as some notion like using the block cipher as a hash function?

@MickLH was there anything else you needed me to answer about the algorithm?

that sounds like CMAC, kinda

@EllaRose Everything! I'm scared to implement, should I just copy paste the latest version from your GitHub and ship it lol?

Hrmm, well on the upside you'd be sure you'd have the right implementation. But I haven't done things like secure memory management or anything, and in the case of the block cipher it is only the cipher, it does not provide any modes of operation

so if you were going to use the blockcipher, you would have to have another library for that

I'd just add a helper function for calling the permutation in whichever mode

it's just more code to write is all

the stream cipher is arguably safer for that reason

less code

which one were you going to use

I guess I can't really advise you further til I know that

I'm actually still debating, let me give some insight into the use case I'm after

I personally favor the more recent design

it's very similar to the block cipher one, but I feel organized more efficiently (and I think securely)

I'd like to share an ephemeral key at the beginning of the session just once, and re-use that key with only the IV changing for the rest of that session

I will receive chunks out of order, and some will disappear

either or would be appropriate, but again, the earlier version will require modes of operation, so I'd recommend the stream cipher variant for that reason

I do know what order they were sent in, so I can re-arrange them into correct order, but each packet needs to be decryptable by itself

(Assuming all other packets were lost)

I can bound the "out of order-ness" such that if they were globally indexed, there would never be a "blip" in the stream of indices larger than 128

I feel the stream cipher is a better fit for lots of small packets

How would you suggest I synchronize it?

I could just use a new IV and new stream for every packet, but it's a big benefit if I can get several messages across per IV

I had an idea to transfer 128 IVs up front with the session key handshake, and have 128 independent cipher streams

the stream cipher supports effectively arbitrary length messages, the problem is reliability

you can't encrypt 10 packets, receive 9 of them, then decrypt them successfully with this design

because it doesn't just xor the data with the key, but does xor-permute-xor

so if a block is missing, the permute step will get messed up

It feels like a kind of hybrid to me, some block cipher behavior

it is, xor-permute-xor is definitely a block cipher construction

I figured that

if xor-permute-xor basically makes the key unrecoverable, and a new keystream is generated any time, idk how people would attack it at least going backwards

and if the keystream is different every time because of the seed, well as they say, idk how someone would break it

(doesn't mean they can't, I just don't know how!)

Maybe you'll see a clearly "best" option, because I can bound each messages to at most 1200 bytes which seems like it should open up some option somewhere