1

After looking at the Wikipedia page for the Fiestel cipher, I thought about making a variation of it that is very general.

I basically followed the diagram on Wikipedia in order to structure the algorithm. The way my algorithm encrypts messages follows this diagram (the decryption is just the reverse method as seen in Wikipedia):

General Fiestel Cipher Diagram

In case the diagram fails to let you know what is going on, I have made an implementation in python without a strong key scheduling method here.

The main question I have is what key schedule method should I create/use/adapt for this cipher? A side question is any general improvements that could be done. The key schedule needs to be able to generate an arbitrary amount of keys and be able to take an arbitrary length key.

Lasagnenator
  • 13
  • 5
  • 1
    Well the key schedule seems insecure, but a Feistel network using BLAKE2b as the F-function would be secure, in theory. Unfortunately though, "analyze this new scheme" questions are off-topic here. – forest Apr 24 '19 at 06:41
  • Is there a place where such a question is not off-topic? If so I'll repost it there. Also, with the key schedule, I could easily replace that. – Lasagnenator Apr 24 '19 at 06:42
  • 1
    I think there's a dedicated thread in some Reddit sub on cryptography? But I think their requirements are pretty strict. You have to provide a design document with design rational, etc. Anyway I wouldn't get your hopes up that a new scheme is secure if you don't have an extremely deep understanding of cryptography. – forest Apr 24 '19 at 06:45
  • 3
    You may want to read the answers to this meta question. Basically, your question is IMO close to being on-topic here, but it does need some clarification. In particular, we cannot really analyze the security of Blake2b here, but you could replace it with a black-box PRF and take its security as an assumption. Also, you should describe your construction clearly enough that we can understand what it does without reading your Python code. Math could be useful; a diagram could be even better. – Ilmari Karonen Apr 24 '19 at 08:22
  • 1
    What Ilmari says. Happy to reopen if you manage to describe just the part of the protocol that you are unsure about. If unsure about different parts, add questions instead of complicating this one. – Maarten Bodewes Apr 24 '19 at 11:12
  • 2
    I have updated the question to hopefully make it on-topic now. – Lasagnenator Apr 25 '19 at 07:21
  • Your question is still very broad - probably too broad. The Feistel network structure is well known and often used. We would expect questions about it to be specific. – Maarten Bodewes Apr 26 '19 at 02:50
  • 1
    Since your missing piece is the key schedule, I'd ask about that. I'd make a reference request for any work relating to a key schedule into a secure black box PRF based Feistel thingie. Given Blake's inherent security, might a simple rolled key expansion be sufficient? Maybe, but check out What is a related key? and decide if xoring totally random round constants might help. You can then have fun deciding the most outrageous/ridiculous/fun means of generating nothing up your sleeve numbers. – Paul Uszak Apr 26 '19 at 03:34
  • Can you concisely summarize what your algorithm is without reference to external code? – Squeamish Ossifrage Apr 26 '19 at 14:58
  • The reason I ask about the key schedule is that the key can be of arbitrary length so I need a scheduling method that works no matter the key length. – Lasagnenator Apr 26 '19 at 23:51
  • what key schedule should I create/use/adapt for this cipher seems like a question for academic researchers rather than crypto.se. We require questions that can be objectively answered without lots of back and forth between the asker and users that attempt to answer the question. There is clearly a lot of back and forth going on already. Besides that, the need for a key schedule that works no matter the key length is an XY-problem: There's no need/benefit for an encryption algorithm that works with an arbitrary key length, so the easiest solution is to change that part instead. – Ella Rose Apr 26 '19 at 23:57
  • Do you have a link to a place where I can ask these academic researchers? Also, the purpose of having arbitrary key lengths lets the user decide if they want to balance security vs performance seeing as the number of rounds is determined by the key length. – Lasagnenator Apr 27 '19 at 01:27
  • What do you need from the key schedule? And have you read https://crypto.stackexchange.com/q/33975/54184? – forest Apr 27 '19 at 06:30
  • After reading through that, I now understand what is needed of the key schedule but I still don't know how to go about it. – Lasagnenator Apr 28 '19 at 04:50
  • By the way, being able to take an arbitrarily sized key and output arbitrary round keys is not practical. After a while, you'll be limited by your block size, not the key size. – forest Apr 28 '19 at 06:27
  • https://crypto.stackexchange.com/q/33975/23115 clearly isn't all that relevant to your case here. It's predicated on weak relatively weak Fs. As your F = Blake, virtually all of those listed schedule requirements fall away. Low implementation cost - Pah! Only if you're fabricating your own ICs. That question begins "I used a CSPRNG to generate the round keys". That'll work. The cryptographic problem you've hit on is that there might not be any research on the security of a Feistel platted with existing strong primitives as it's kinda redundant/heresy. – Paul Uszak Apr 28 '19 at 13:07
  • @PaulUszak There's a lot of research on Feistel networks using ideal F-functions... – forest Apr 29 '19 at 02:49
  • @forest I'm not sure that theoretical/ideal = real world hash (a la Blake) but you probably know better. I believe that Blake's strength directly influences the key schedule design. Probably trivialises it. This would all be great in your answer though :-) – Paul Uszak Apr 29 '19 at 03:42
  • @PaulUszak I did put it in my answer. You could use a trivial linear key schedule and be totally fine even if you only use the round counter as a round constant, if the F-function is a strong PRF. With a big enough block size, you wouldn't need a key schedule at all (since the slide attack would become impractical). – forest Apr 29 '19 at 04:03

1 Answers1

2

It's not a good idea to assume that your F-function is strong by itself. With very few exceptions, it's not true even with professionally-designed Feistel networks. In fact, the reason Feistel networks are even needed is because they're used to build a secure PRP from an insecure PRP or PRF. Said insecure function must be designed so that it is extremely lightweight and is secure after sufficient iterations.

Without more information, no one can tell you how to design a key schedule. They're generally tightly integrated with the rest of the cipher. All we can do is give you possible designs that would be inefficient but would work, or which would only be secure assuming your F-function is a strong PRF (which is quite an assumption). You have to think about a few things when designing a key schedule:

  • Do you need key agility and if so, how light must the key schedule be?

  • How does it interact with the rest of the cipher (this is a very complex question)?

  • What is your maximum memory and ROM footprint?

  • Is side-channel resistance important to you?

  • What kinds of operations do you wish to implement it in?

If you are not making any assumptions about the F-function, then you could use an algorithm like HKDF to expand an input master key into an arbitrary number of subkeys. If you do assume that the F-function is a strong PRF, which it very likely will not be, then the key schedule could be as trivial as XORing a round counter (functioning as a round constant) with the key to derive each round key. That would be necessary to avoid the slide attack, but relies on assumptions about the F-function's security.

forest
  • 15,253
  • 2
  • 48
  • 103
  • So the balance between performance and security is based on a balance between the F-function and the key schedule. Also I don't really mind about not being side-channel resistant. Is implementing a hash function within the F-function considered secure? – Lasagnenator Apr 28 '19 at 07:26
  • @Lasagnenator A cryptographic hash function (like SHA-256 or BLAKE2) would make for a secure F-function, but it would be unnecessarily slow. You aren't using this construction for anything serious, are you? It's great to invent ciphers for fun, but never rely on them for anything. A "very general" secure but inefficient Feistel cipher could use, say, SHA-256/128 in HKDF for the key schedule, and directly for the F-function. There would be easier ways to create a cipher out of a hash, though. – forest Apr 28 '19 at 07:27
  • 1
    I'm planning on using this for personal use, it doesn't have to be efficient, I just want it to be secure. So a way to do the key scheduling would be to just hash the key and re-hash it for every round? Inefficient I know, but secure. Also, would the key length matter now as the key is hashed at every round? – Lasagnenator Apr 28 '19 at 07:39
  • 1
    @Lasagnenator If you want it to be secure, then don't roll your own crypto! I'm a random person on the internet who does not have an advanced degree in cryptography, so while my advice may be sufficient for an online Q&A site, it should not be taken as accurate enough for you to design your own cipher. Is there a reason you don't want to use an existing cipher like AES (or Twofish, if you really want a Feistel network)? And yes, key length and keyspace still matters greatly. It always matters. – forest Apr 28 '19 at 07:41
  • 1
    I want to have my own though. I also feel like having a cipher that can be modified easily whilst still being secure will make it harder for attackers to break it as the algorithm could change at any time. – Lasagnenator Apr 28 '19 at 07:44
  • Having your own and using your own are different things. If you really, truly want to be secure, use an existing cipher. It will be far more secure than anything you could put together. Plus – forest Apr 28 '19 at 07:45
  • Ok, I will think about it. – Lasagnenator Apr 28 '19 at 07:48
  • Function F = Blake – Paul Uszak Apr 28 '19 at 21:23