# practically verifying block ciphers strength [closed]

How do we verify practically the strength of a block ciphers? Most of the security analysis of block ciphers is usually around theoretical analysis and proofs in some random oracle model etc.

For example, for our recently designed FNR encryption scheme, we have only given results based on previously done theoretical work by Naor and Reingold. That is if $r$ is round count, $n$ is number of bits of input domain, $m$ is number of queries an attacker needs to make, then the security measure for FNR, is defined as below.

$$\begin{split} & ( r/2 * m^2 / 2^{(1- 1/r)* n }) \; \textit{ where r \geq 4 } \end{split}$$

But how do we practically verify this by experimental results? What about cryptanalysis tools?
I believe such tools would help any one who is designing block ciphers in general.

-

## closed as off-topic by e-sushi♦, Maarten Bodewes, otus, DrLecter, D.W.Aug 31 '14 at 6:32

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

Hint: GitHub readme says “FNR is a small domain block cipher to encrypt…” while line 2 of fnr.c says “FNR is a small domain block cipher mode to encrypt…” which is more correct since you’re using OpenSSL’s AES-128 in ECB mode as a cipher base, wrapping your "Flexible Naor and Reingold" mode (line 4) around that. Same for your question here: you don’t need tools to test the block cipher (which is AES), you actually need tools to analyze your “block cipher mode. Analyzing block ciphers is not really the same as analyzing cipher modes. –  e-sushi Aug 30 '14 at 1:43
it is a encryption scheme not mode, shall correct it thanks ! BTW , curious what those tools are for analyzing "modes" –  sashank Aug 30 '14 at 3:07
/* No need to thank me. */ As for tools, good question. Got no suggestions. ecrypt.eu.org/tools has “tools” but I’m not sure you can use any of it. Mostly I’ve seen people build their own stuff, but they rarely share it. And if they share things it’s a bunch of memory-leaking uselessness like picek sbox tool (SIDES) which is merely a thrown-together collection of code-snippets that doesn’t even match the description from the paper they published. :( –  e-sushi Aug 30 '14 at 3:26
yes the tools could be lot generic. Am imagining, machine learning based say "supervised learning" based techniques to identify non-randomness after some number of rounds etc. –  sashank Aug 30 '14 at 3:43
You could test non-randomness using a battery tester like DieHarder. But to gain some real cryptanalytic results, you should throw some checks for linear and for differential symptoms at it too (like analyzing correlation immunity, algebraic immunity, fixed points, propagation characteristics, etc.)! Since you’re using AES at FNR’s core, there shouldn’t be anything bad to show up on your radar… and that could provide a bit more confidence in the security of FNR. Yet, those are just ideas I’m throwing in here, meaning: there might be other ways to provide proof to FNR security as a scheme/mode. –  e-sushi Aug 30 '14 at 9:32