1
$\begingroup$

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.

Improve this question
$\endgroup$
19
  • 1
    $\begingroup$ 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. $\endgroup$
    – forest
    Commented Apr 24, 2019 at 6:41
  • 1
    $\begingroup$ 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. $\endgroup$
    – forest
    Commented Apr 24, 2019 at 6:45
  • 3
    $\begingroup$ 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. $\endgroup$
    – Ilmari Karonen
    Commented Apr 24, 2019 at 8:22
  • 1
    $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Commented Apr 24, 2019 at 11:12
  • 2
    $\begingroup$ I have updated the question to hopefully make it on-topic now. $\endgroup$
    – Lasagnenator
    Commented Apr 25, 2019 at 7:21

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
8
  • $\begingroup$ 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? $\endgroup$
    – Lasagnenator
    Commented Apr 28, 2019 at 7:26
  • $\begingroup$ @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. $\endgroup$
    – forest
    Commented Apr 28, 2019 at 7:27
  • 1
    $\begingroup$ 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? $\endgroup$
    – Lasagnenator
    Commented Apr 28, 2019 at 7:39
  • 1
    $\begingroup$ @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. $\endgroup$
    – forest
    Commented Apr 28, 2019 at 7:41
  • 1
    $\begingroup$ 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. $\endgroup$
    – Lasagnenator
    Commented Apr 28, 2019 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.