# Tag Info

1

If you define $u$ as element of $G_1$, then you can't just use it in $G_2$ (in the first equation), like you did in your equation. Besides, you missed to state, if $u$ and $g$ are generators of those groups. The following holds: $$e(u^a,g^{\frac{b}{a}}) = e(u,g)^b = e(u^b,g)$$ Anyway, you didn't do that in the actual question, where I don't really see the ...

0

The paper also discusses linear characteristics for multiple rounds: We present several approaches to produce linear characteristics for SIMON32/64 and present the best known linear characteristic for 11-round SIMON 32/64 with the bias of $2^{-16}$. We then extend this characteristic to 13 rounds of the cipher. We present several approaches ...

1

Here $f_i$ is simply the number of times the character $i$ appears in the ciphertext of length $N$ and where $Z$ is the alphabet size. If you had ciphertext ADCXU ZMDYZ DXZUM and which was derived from English plaintext then $N=15$ and $f_A=1,f_B=0,f_C=1, f_D=3,\ldots, f_Z=2.$

2

Kasiski's test only considers repeated sequences of characters, under assumption that the text contains repeated words with distance between them being a multiple of key length. Autocorrelation analysis simply counts matching characters between shifted ciphertexts. Then you have to identify "maxima", which are shift distances with higher match counts than ...

5

As fgrieu notes in the comments, the protocol might not even work reliably in the absence of adversaries: if the tag fails to receive the reader's reply of "True", the keys will get out of sync. (If that happens, the tag will just retry the next exchange with the old key, so this could be fixed by having the reader remember one more "subkey". But the ...

1

The performance can be configuration specific, so beware that any outcome is specific to a machine. Take care that you test on the right configuration(s). The performance may also be specific to a certain input size. So test for specific amounts of data while keeping in mind that most hash methods operate on blocks (it doesn't make much sense to test 1 byte ...

1

Not much. All you need can be found in any "Intro. to cryptography" book such as Katz/Lindell. In particular, you don't need any of the fancy measure-theoretic stuff since in cryptography you only work with discrete distributions.

1

Of course, it is possible. It is possible to take a public key encryption algorithm which takes the private key and the known ciphertext into the known plaintext, convert that into a set of equations in $GF(2)$ with the private key as unknown variables, and solve for those unknown variables. Alternatively, you can take the key generation algorithm, which ...

3

If we signed a secret message $m$ by publishing its signature $σ$ computed as $m^d\bmod N$, at least two very bad things would happen: The message would not be so secret anymore That's because anyone knows the public key $(N,e)$, and thus from $σ$ can compute $σ^e\bmod N$, which is $m\bmod N$. This reveals a lot of information about $m$, which goes ...

1

Sometimes, rather than do cool math, the easiest approach is brute force! #include <stdio.h> #include <assert.h> int main() { enum { X0 = 3158, X1 = 1888, X2 = 1285, X3 = 1744, X4 = 253, X5 = 722, M_START = 3159 }; for (int m = M_START; m < 10*M_START; ++m) { for (int a = 2; a < m; ++a) { int c = X2 ...

3

From your picture I deduce that $A$ and $B$ are both 8 bits. So this construction can be seen as a $16 \times 8$ bit S-box (not bijective). The fact that it's not square is probably what is causing confusion. Usually, for SPNs, invertible S-boxes are used. Non-invertible S-boxes are less common, but they certainly have applications. One of the things we can ...

Top 50 recent answers are included