The AES and the distinguisher of [GRR17] The AES

The AES NIST standard since 2001, SPN on 10 rounds, 128-bit blocks [DR02].

x =    
x 0 x 4 x 8 x 12 x 1 x 5 x 9 x 13 x 2 x 6 x 10 x 14 x 3 x 7 x 11 x 15

    ∈ F 16 2 8 S-box F 2 8 → F 2 8 x i → y i SR(y ) =    
y 0 y 4 y 8 y 12 y 5 y 9 y 13 y 1 y 10 y 14 y 2 y 6 y 15 y 3 y 7 y 11

    ShiftRows SR MC(z) =     2 3 1 1 1 2 3 1 1 1 2 3 3 1 1 2     × z MixColumns MC
The AES and the distinguisher of [GRR17] The AES The distinguisher of Grassi, Rechberger and Rønjom

Proof for the distinguisher Conclusion

5/ 30

The AES and the distinguisher of [GRR17]

The distinguisher of Grassi, Rechberger and Rønjom What is a distinguisher ?

Let C k be a cipher with key k,

Distinguisher P : C k , k $ ← -F n 2 or random permutation C /random m P(m)
Distinguisher → attack (on more rounds).

Grassi, Rechberger and Rønjom at Eurocrypt 2017 [GRR17] → C = 5 AES rounds.

6/ 30

The AES and the distinguisher of [GRR17] The distinguisher of Grassi, Rechberger and Rønjom Some definitions...

K = F 2 8    
x 0 x 4 x 8 x 12 x 1 x 5 x 9 x 13 x 2 x 6 x 10 x 14 x 3 x 7 x 11 x 15

    ∈ M 4 (K) x i ∈ K    
x 0 0 0 0 x 1 0 0 0 x 2 0 0 0

x 3 0 0 0     ∈ C 0
Columns C i = vect K (e 0,i , e 1,i , e 2,i , e 3,i )

    0 x 0 0 y 0 0 x 1 0 y 1 0 x 2 0 y 2 0 x 3 0 y 3     ∈ C {1,3} I ⊆ 0, 3 : C I = i∈I C i .    
x 0 0 0 0 x 1 0 0 0 0 x 2 0 0 0 0 x 3     ∈ D 0 , Diagonals:

D i = SR -1 (C i )     x 0 0 0 0 0 x 1 0 x 2 0 x 3 0 0     ∈ ID 0 ,
Anti-diagonals:

ID i = SR(C i )     2 • x 0 x 1 x 2 3 • x 3 x 0 x 1 3 • x 2 2 • x 3 x 0 • x 1 2 • x 2 x 3 3 • x 0 • x 1 x 2 x 3     ∈ M 0 .
Mixed:

M i = MC (ID i ) D I R S -→ D I SR -→ C I MC --→ C I R S -→ C I SR -→ ID I MC --→ M I
The AES is a key-alternating blockcipher

m k 0 R 1 k 1 R 2 k 2 • • • R r k r c key schedule k master key

Subspace trails

Definition ([LTW18])

We have

U F ⇒ V if ∀a ∈ K N , ∃b ∈ K N : F(U + a) ⊆ V + b. F F F Examples: {0} F ⇒ {0} U F ⇒ K N D I R ⇒ C I C I R ⇒ M I 10/ 30 D 0 R ⇒ C 0 ∀a, ∀x,     x 0 0 0 0 0 x 1 0 0 0 0 x 2 0 0 0 0 x 3     +a --→     x 0 + a 0 * * * * x 1 + a 1 * * * * x 2 + a 2 * * * * x 3 + a 3     S -→     y 0 * * * * y 1 * * * * y 2 * * * * y 3     SR -→     y 0 * * * y 1 * * * y 2 * * * y 3 * * *     MC --→       . . . * * * . . . * * * MC(y ) * * * . . . * * *       11/ 30
The AES and the distinguisher of [GRR17]

The distinguisher of Grassi, Rechberger and Rønjom

The distinguisher

Theorem ([GRR17])

Let a ∈ M 4 (K), i ∈ 0, 3 , J ⊆ 0, 3 . We define

n = #{ {p 0 , p 1 } ∈ P 2 (D i + a) | R 5 (p 0 ) + R 5 (p 1 ) ∈ M J }.
Then n ≡ 0 mod 8.

Distinguisher: compute n P : AES A key lemma

Lemma ([GRR17])

Let a ∈ M 4 (K), I ⊂ 0, 3 , J ⊆ 0, 3 . We define

n = #{ {p 0 , p 1 } ∈ P 2 (M I + a) | R(p 0 ) + R(p 1 ) ∈ D J }.
Then n ≡ 0 mod 8.

2 D I R ⇒ C I R ⇒ M I 1 Lemma R 2 D J R ⇒ C J R ⇒ M J

Proof

In the original paper [GRR17]:

First case. First, we consider the case in which three variables are equal. W.l.o.g. we assume for example that y = y�, z = z�, w = w� and x � = x� (the other cases are analogous). In other words, we suppose that the two texts p1 and p2 belong to the same coset of M0 ∩ C0 ⊕ a, where a ∈ (M0 ∩ C0)⊥.

Since M0 ∩ C0 ⊆ C0, it follows that if p1 ⊕ p2 ∈ C0, then R(p1) ⊕ R(p2) ∈ M0. Since MI ∩ DJ = {0} for each I and J with |I| + |J| ≤ 4 (see (3)), it follows that R(p1) ⊕ R(p2) /
∈ DJ for each J ⊆ {0, 1, 2, 3} with |J| ≤ 3. In other words, with the given hypothesis for this case, it is not possible that the two texts belong to the same coset of a diagonal space DJ for each |J| ≤ 3 after one round.

For completeness, it is also possible to show the same result in a different way. By definition, R(p1) ⊕ R(p2) ∈ DJ for a certain J with |J| = 3 if and only if (R(p1) ⊕ R(p2))i,j+i = 0 for each i = 0, ..., 3 (i.e. the four bytes of the j-th diagonal of R(p1)⊕R(p2) are equal to zero), where the indexes are taken modulo 4 and j = {0, 1, 2, 3} \ J. As we are going to show, due to the given hypothesis of this case and since the branch number of the MixColumns operation is equal to five, it follows that R(p1) ⊕ R(p2) /

∈ DJ for all J with |J| = 3. In other words, R(p1) ⊕ R(p2) ∈ DJ for |J| = 3 if and only if x = x�, that is p1 = p2.

In more details, by simple computation the first column (analogues for the other ones) of SR• S-Box(p1) ⊕ SR• S-Box(p2) -denoted by (SR• S-Box(p1) ⊕ SR• S-Box(p2))•,0 -is equal to:

(SR• S-Box(p1)⊕SR• S-Box(p2))•,0 =     S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) 0 0 0     .
After the MixColumns operation (note R(p1

) ⊕ R(p2) = M C(SR • S-Box(p1) ⊕ SR • S-Box(p2)) = M C • SR • S-Box(p1) ⊕ M C • SR • S-Box(p2)
), since only one input byte10 is different from zero, it follows that at least four output bytes must be different from zero, that is all the output bytes are different from zero. This simply implies that it is not possible that R(p1) ⊕ R(p2) ∈ DJ for |J| ≤ 3.

Second case. Secondly, we consider the case in which two variables are equal, that is w.l.o.g. we assume for example that z = z� and w = w�, while x � = x� and y � = y� (the other cases are analogous). That is, we suppose that the two texts p1 and p2 belong to the same coset of M0 ∩ C0,1 ⊕ a, where a ∈ (M0 ∩ C0,1)⊥.

Assume that -for certain z = z� and w = w� -there exist two elements p1 (generated by �x, y�) and p2 (generated by �x�, y��) defined as before in the same coset of M0 that belong to the same coset of DJ for a certain J with |J| = 3 after one round. In other words, let j = {0, 1, 2, 3} \ J and assume that there exist x, y and x�, y� and j such that the generated elements p1 and p2 satisfy (R(p1) ⊕ R(p2))i,i+j = 0 for each i = 0, 1, 2, 3, where the indexes are taken modulo 4.

10 Note that S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) = 0 if and only if x = x�, which
can never happen for hypothesis.

21

This implies that the two elements p1 (generated by �x, y��) and p2 (generated by �x, y��)

p1 = a ⊕     2 • x� y 0 0 x� y 0 0 x� 3 • y 0 0 3 • x� 2 • y 0 0     , p2 = a ⊕     2 • x y� 0 0 x y� 0 0 x 3 • y� 0 0 3 • x 2 • y� 0 0    
belong to the same coset of DJ after one round. To prove this fact, it is sufficient to compute R(p1) ⊕ R(p2) and R(p1) ⊕ R(p2), and to prove that they are equal, i.e.

R(p1) ⊕ R(p2) = R(p1) ⊕ R(p2).
Since R(p1) ⊕ R(p2) ∈ DJ , it also follows that R(p1) ⊕ R(p2) ∈ DJ . In particular, by simple computation the first column of R(p1) ⊕ R(p2) is given by:

(R(p1) ⊕ R(p2))0,0 = 2 • (S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0))⊕ ⊕ 3 • (S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1)), (R(p1) ⊕ R(p2))1,0 = S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0)⊕ ⊕ 2 • (S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1)), (R(p1) ⊕ R(p2))2,0 = S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0)⊕ ⊕ S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1), (R(p1) ⊕ R(p2))3,0 = 3 • (S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0))⊕ ⊕ S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1).
Due to the definition of p1 and p2, it follows immediately that (R(p1)⊕R(p2))•,0 = (R(p1)⊕R(p2))•,0. The same holds for the other columns. Note that the existence of the two elements p1 and p2 is guaranteed by the fact that we are working with the entire coset of M0. This implies that the number of collisions must be even, that is a multiple of 2. Question: given p1 and p2 as before, is it possible that x, y, x�, y� exist such that R(p1) ⊕ R(p2) ∈ DJ for |J| = 3? Yes, again because the branch number of the MixColumns operation is five. Indeed, compute SR• S-Box(p1) ⊕ SR• S-Box(p2) and analyze the first column (the others are analogous):

(SR• S-Box(p1)⊕SR• S-Box(p2))•,0 =     S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1) 0 0     .
After the MixColumns operation (note

R(p1) ⊕ R(p2) = M C(SR • S-Box(p1) ⊕ SR • S-Box(p2))), since two input bytes11 are different from zero, it follows that 11 Note that S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) = 0 if and only if x = x�,
which can never happen for hypothesis. In the same way, S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1) = 0 if and only if y = y�, which can never happen for hypothesis.

22

at least three output bytes must be different from zero, or at most one output byte could be equal to zero (similar for the other columns). In other words, it is possible that p1 and p2 exist such that R(p1)⊕R(p2) ∈ DJ for |J| = 3. Moreover, this also implies that it is not possible that two or more output bytes in the same column are equal to zero, or in other words that R(p1) ⊕ R(p2) ∈ DJ for |J| ≤ 2, with the previous conditions. Moreover, observe that R(p1) ⊕ R(p2) ∈ DJ for |J| = 3 if and only if four bytes (one per column) of R(p1) ⊕ R(p2) are equal to zero. Since there are four "free" variables (i.e. x, y, x�, y�) and a system of four equations, such a system can have a non-negligible solution.

Finally, since the previous result is independent of the values of z = z� and w = w�, it follows that the number of collisions for this case must be a multiple of 217. Indeed, assume that for certain ẑ and ŵ there exist x, y, x�, y� such that the two elements p1 and p2 in M0 ∩ C0,1 ⊕ a generated respectively by �x, y� and by �x�, y�� satisfy the condition R(p1) ⊕ R(p2) ∈ DJ for a certain J. By simple computation, the difference R(p1) ⊕ R(p2) doesn't depend on z = z� and on w = w�, that is for each byte of (R(p1) ⊕ R(p2))k,l for k, l = 0, 1, 2, 3 there exist constant Ai, Bi, Ci for i = 0, 1, 2, 3 -that depend only on the coefficients of the MixColumns matrix or/and of the secret-key -such that

(R(p1) ⊕ R(p2))i,j =A0 • (S-Box(B0 • x ⊕ C0) ⊕ S-Box(B0 • x� ⊕ C0))⊕ ⊕ A1 • (S-Box(B1 • y ⊕ C1) ⊕ S-Box(B1 • y� ⊕ C1))⊕ ⊕ A2 • (S-Box(B2 • z ⊕ C2) ⊕ S-Box(B2 • z� ⊕ C2))⊕ ⊕ A3 • (S-Box(B3 • w ⊕ C3) ⊕ S-Box(B3 • w� ⊕ C3)) = =A0 • (S-Box(B0 • x ⊕ C0) ⊕ S-Box(B0 • x� ⊕ C0))⊕ ⊕ A1 • (S-Box(B1 • y ⊕ C1) ⊕ S-Box(B1 • y� ⊕ C1)).
It follows that -under the previous hypothesis -each pair of elements p1 and p2 respectively generated by (1) �x, y, z, w� and by �x�, y�, z, w� or (2) �x, y�, z, w� and by �x�, y, z, w� for each possible value of z and w satisfy the condition R(p1)⊕ R(p2) ∈ DJ . Thus, the number of collisions for this case must be a multiple of 2 • (28)2 = 217. As before, the existence of all these elements is guaranteed by the fact that we are working with the entire coset of M0.

Third case. Thirdly, we consider the case in which only one variable is equal, that is w.l.o.g. we assume for example w = w�, while x � = x�, y � = y� and z � = z� (the other cases are analogous). That is, we suppose that the two texts p1 and p2 belong to the same coset of M0 ∩ C0,1,2 ⊕ a, where a ∈ (M0 ∩ C0,1,2)⊥.

Assume there exist two elements p1 (generated by �x, y, z�) and p2 (generated by �x�, y�, z��) defined as before in the same coset of M0 that belong to the same coset of DJ for a certain J with |J| ≥ 2 after one round. In other words, assume there exist x, y, z and x�, y�, z� such that the generated elements p1 and p2 satisfy R(p1) ⊕ R(p2) ∈ DJ for a certain J with |J| ≥ 2 Similar to before, it follows that also the following three pairs of elements in the same coset of M0 generated by: 23 -�x�, y, z� and �x, y�, z�� -�x, y�, z� and �x�, y, z�� -�x, y, z�� and �x�, y�, z� belong after one round in the same coset of DJ for the same J of p1 and p2, for a total of four different pairs. As before, in order to prove this fact it is sufficient to show that R(p1) ⊕ R(p2) = R(p1) ⊕ R(p2), where p1 and p2 are generated by the previous combinations of variables. Note that the existence of these elements is guaranteed by the fact that we are working with the entire coset of M0. This implies that the number of collisions must be a multiple of 4.

Finally, we have only to prove that such x, y, z and x�, y�, z� can exist. As before, we compute SR• S-Box(p1)⊕SR• S-Box( p2) and analyze the first column (the others are analogous):

(SR• S-Box(p1)⊕SR• S-Box(p2))•,0 =     S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1) S-Box(2 • z ⊕ a2,2) ⊕ S-Box(2 • z� ⊕ a2,2) 0     .
After the MixColumns operation, since three input bytes12 are different from zero, it follows that at least two output bytes must be different from zero, or at most two output bytes could be equal to zero. This implies that the event R(p1) ⊕ R(p2) ∈ DJ for |J| ≥ 2 is possible. Moreover, this also implies that it is not possible that three output bytes (of the same column) are equal to zero, or in other words that R(p1) ⊕ R(p2) ∈ DJ for |J| = 1, with the previous hypothesis. Also in this case, variables x, y, z and x�, y�, z� can exist since the number of equations is less or equal than the number of variables. Finally, since the previous result is independent of the values of w = w�, it follows that the number of collisions for this case must be a multiple of 4•28 = 210. As before, assume that for a certain ŵ there exist x, y, z, x�, y�, z� such that the two elements p1 and p2 in M0 ∩ C0,1,2 ⊕ a generated respectively by �x, y, z� and by �x�, y�, z�� satisfy the condition R(p1) ⊕ R(p2) ∈ DJ for a certain J. Also in this case, the idea is to show that the difference R(p1)⊕R(p2) doesn't depend on w = w�, that is for each byte of (R(p1) ⊕ R(p2))i,j there exist constant Ai, Bi, Ci for i = 0, 1, 2 -that depend only on the coefficients of the MixColumns matrix or/and of the secret-key -such that

(R(p1) ⊕ R(p2))i,j = A0 • (S-Box(B0 • x ⊕ C0) ⊕ S-Box(B0 • x� ⊕ C0))⊕ ⊕ A1 • (S-Box(B1 • y ⊕ C1) ⊕ S-Box(B1 • y� ⊕ C1))⊕ ⊕ A2 • (S-Box(B2 • z ⊕ C2) ⊕ S-Box(B2 • z� ⊕ C2)).
It follows that -under the previous hypothesis -each pair of elements p1 and p2 respectively generated by one of the four different combinations of the variables �x, y, z, w� and �x�, y�, z�, w� for each possible value of w satisfy the condition R(p1) ⊕ R(p2) ∈ DJ . As before, the existence of all these elements is guaranteed by the fact that we are working with the entire coset of M0.

Fourth case. Fourthly, we consider the case in which all the variables are different, that is w.l.o.g. we assume that x � = x�, y � = y�, z � = z� and w � = w�.

That is, we suppose that the two texts p1 and p2 belong to the same coset of M0 ⊕ a, where a ∈ M⊥ 0 and where p1 ⊕ p2 / ∈ CJ for each |J| ≤ 3. Assume there exist two elements p1 (generated by �x, y, z, w�) and p2 (generated by �x�, y�, z�, w��) defined as before in the same coset of M0 that belong to the same coset of DJ for a certain J with |J| ≥ 1 after one round. In other words, assume there exist x, y, z, w and x�, y�, z�, w� such that the generated elements p1 and p2 satisfy R(p1) ⊕ R(p2) ∈ DJ for a certain J with |J| ≥ 1. Similar to before, it follows that also the following seven pairs of elements in the same coset of M0 generated by: -�x�, y, z, w� and �x, y�, z�, w�� -�x, y�, z, w� and �x�, y, z�, w�� -�x, y, z�, w� and �x�, y�, z, w�� -�x, y, z, w�� and �x�, y�, z�, w� -�x�, y�, z, w� and �x, y, z�, w�� -�x�, y, z�, w� and �x, y�, z, w�� -�x�, y, z, w�� and �x, y�, z�, w� belong after one round in the same coset of DJ for the same J of p1 and p2, for a total of eight different pairs. As before, in order to prove this fact it is sufficient to show that R(p1) ⊕ R(p2) = R(p1) ⊕ R(p2). Moreover, as before note that existence of these elements is guaranteed by the fact that we are working with all the coset of M0. This implies that the number of collisions must be a multiple of 8.

Finally, we have only to prove that such x, y, z, w and x�, y�, z�, w� can exist. As before, we compute SR• S-Box(p1) ⊕ SR• S-Box(p2) and analyze the first column (the others are analogous):

(SR• S-Box(p1)⊕SR• S-Box(p2))•,0 =     S-Box(2 • x ⊕ a0,0) ⊕ S-Box(2 • x� ⊕ a0,0) S-Box(y ⊕ a1,1) ⊕ S-Box(y� ⊕ a1,1) S-Box(2 • z ⊕ a2,2) ⊕ S-Box(2 • z� ⊕ a2,2) S-Box(w ⊕ a3,3) ⊕ S-Box(w� ⊕ a3,3)     .
After the MixColumns operation, since four input bytes13 are different from zero, it follows that at least one output byte must be different from zero, or at most three output bytes could be equal to zero. This implies that the event R(p1) ⊕ R(p2) ∈ DJ for |J| ≥ 1 is possible. Also in this case, variables x, y, z, w and x�, y�, z�, w� can exist since the number of equations is less or equal than the number of variables.

Our contribution starts here

Search for the underlying property ; write a better proof for it to come out; generalize ?

Step 1: equivalence relation between pairs

In M 0 ,            2 • x 0 x 1 z 2 3 • z 3 x 0 x 1 3 • z 2 2 • z 3 x 0 3 • x 1 2 • z 2 z 3 3 • x 0 2 • x 1 z 2 z 3     ,     2 • y 0 y 1 z 2 3 • z 3 y 0 y 1 3 • z 2 2 • z 3 y 0 3 • y 1 2 • z 2 z 3 3 • y 0 2 • y 1 z 2 z 3            ∼            2 • x 0 y 1 w 2 3 • w 3 x 0 y 1 3 • w 2 2 • w 3 x 0 3 • y 1 2 • w 2 w 3 3 • x 0 2 • y 1 w 2 w 3     ,     2 • y 0 x 1 w 2 3 • w 3 y 0 x 1 3 • w 2 2 • w 3 y 0 3 • x 1 2 • w 2 w 3 3 • y 0 2 • x 1 w 2 w 3                       2 • x 0 x 1 z 2 3 • z 3 x 0 x 1 3 • z 2 2 • z 3 x 0 3 • x 1 2 • z 2 z 3 3 • x 0 2 • x 1 z 2 z 3     ,     2 • y 0 y 1 z 2 3 • z 3 y 0 y 1 3 • z 2 2 • z 3 y 0 3 • y 1 2 • z 2 z 3 3 • y 0 2 • y 1 z 2 z 3            ∼            2 • x 0 y 1 w 2 3 • w 3 x 0 y 1 3 • w 2 2 • w 3 x 0 3 • y 1 2 • w 2 w 3 3 • x 0 2 • y 1 w 2 w 3     ,     2 • y 0 x 1 w 2 3 • w 3 y 0 x 1 3 • w 2 2 • w 3 y 0 3 • x 1 2 • w 2 w 3 3 • y 0 2 • x 1 w 2 w 3            Definition Let {p 0 , p 1 } a pair of states from M I + a. The information set K of the pair {p 0 , p 1 } is {k ∈ 0, 3 | ∃i ∈ I : x i,k = y i,k }. It is K = {0, 1} in the example.            2 • x 0 x 1 z 2 3 • z 3 x 0 x 1 3 • z 2 2 • z 3 x 0 3 • x 1 2 • z 2 z 3 3 • x 0 2 • x 1 z 2 z 3     ,     2 • y 0 y 1 z 2 3 • z 3 y 0 y 1 3 • z 2 2 • z 3 y 0 3 • y 1 2 • z 2 z 3 3 • y 0 2 • y 1 z 2 z 3            ∼            2 • x 0 y 1 w 2 3 • w 3 x 0 y 1 3 • w 2 2 • w 3 x 0 3 • y 1 2 • w 2 w 3 3 • x 0 2 • y 1 w 2 w 3     ,     2 • y 0 x 1 w 2 3 • w 3 y 0 x 1 3 • w 2 2 • w 3 y 0 3 • x 1 2 • w 2 w 3 3 • y 0 2 • x 1 w 2 w 3            Definition Let P = {p 0 , p 1 }, Q = {q 0 , q 1 } ∈ P 2 (M I + a). We have P ∼ Q if: K is the information set of P ⇒ K is the information set of Q. ∀k ∈ K , ∃b ∈ {0, 1} : ∀i ∈ I , q 0 i,k = p b i,k et q 1 i,k = p 1-b i,k . ∼ is an equivalence relation on P 2 (M I + a). Lemma If n = #{ {p 0 , p 1 } ∈ P 2 (M I + a) | R(p 0 ) + R(p 1 ) ∈ D J },
then n ≡ 0 mod 8.

Proof.

n = #f -1 (D J ) = C∈P 2 (M I +a) ∼ #(f -1 (D J ) ∩ C) = C∈P 2 (M I +a) ∼ 1 f (C)∈D J #C ≡ 0 mod 8 Lemma If n = #{ {p 0 , p 1 } ∈ P 2 (M I + a) | R(p 0 ) + R(p 1 ) ∈ D J },
then n ≡ 0 mod 8.

Proof.

Definition

Let V ⊆ K N be a K-subspace. We say V is compatible with S if it has a basis g such that its matrix in basis f is of the form: The generalization can be useful (the distinguisher can be easily transposed) but cannot give better results! Working on subspace trails [LTW18].

                   * •
M MC =     0 1 1 1 1 0 1 1 1 1 0 1 1 1 1 0     2 D I R ⇒ C I R ⇒ M I 1 Genaralized Lemma R 2 D J R ⇒ C J R ⇒ M J
2 D I R ⇒ C I R ⇒ M I 1 Genaralized Lemma R 2 D J R ⇒ C J R ⇒ M J 30/ 30

Note that S-Box(2•x⊕a0,0)⊕S-Box(2•x�⊕a0,0) = S-Box(y⊕a1,1)⊕S-Box(y�⊕a1,1) = S-Box(2 • z ⊕ a2,2) ⊕ S-Box(2 • z� ⊕ a2,2) = 0 ifand only if x = x�, y = y� and z = z�, which can never happen for hypothesis.

Note that S-Box(2•x⊕a0,0)⊕S-Box(2•x�⊕a0,0) = S-Box(y⊕a1,1)⊕S-Box(y�⊕a1,1) = S-Box(2•z ⊕a2,2)⊕S-Box(2•z� ⊕a2,2) = S-Box(w ⊕a3,3)⊕S-Box(w� ⊕a3,3) = 0 if and only if x = x�, y = y�, z = z� and w = w�, which can never happen for hypothesis.

Lemma

The function

is constant on the equivalence classes of ∼.

Proposition

Let C be an equivalence class K . Then

What about the branch number ?

In [GRR17], the proof needs maximal branch number. But...

Proposition ([GRR16])

Let I , J ⊆ 0, 3 and b be the differential branch number of MC. Then

IACR Trans. Symmetric Cryptol., 2018(1):74-100, 2018.

30/ 30


Emmanuel Baccelli

Joerg Doerr

Ons Jallouli

Shinji Kikuchi

Andreas Morgenstern

Francisco Acosta Padilla

Kaspar Schleiser

Ian Thomas

Reprogramming Low-end IoT Devices from the Cloud

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

The Internet of Things has been the subject of much research and development with respect to networks, protocols, gateways and devices. This research has focused on making it easy to connect sensors to the Internet using IP-based protocols and on collecting the raw data made available by such sensors for analysis and onward processing. But this means that most of today's research treats connected things as 'dumb' objects with little intelligence or configurability, limiting their ability to adapt and wasting their potential to create faster, more intelligent and more efficiently networked digital ecosystems. Despite very small memory capacity (a few kBytes [START_REF] Bormann | RFC 7228: Terminology for constrained node networks[END_REF]) and limited energy consumption (1000 times less than a RaspberryPi), low-end IoT devices can indeed execute quite complex logic, and interact with the rest of the network -just like other computers on the Internet.

In this paper we therefore investigated opportunities to model and deploy functionality directly to devices, making them more intelligent and reactive in pursuit of distributed, hyperconnected and autonomous systems. Our goal was to bring speed and agility of web-and cloud-based development to low-end IoT devices. To this end we created and tested a platform articulating of a suite of components: a generic IoT device operating system (RIOT), communicating via standard IoT application protocols with a cloud-based development tool enabling quick business-logic deployment, from the cloud to a fleet of managed IoT devices. The cloud component automatically translates graphically-programmed BPMN business logic into standard Javascript which can be deployed and executed on managed IoT devices. While some recent solutions such as NodeRED [START_REF] Nodered | [END_REF] provide a subset of these functionalities, we are not aware of a platform which bundles the full set of features described above.

The remainder of this paper is organized as such: first, we overview the architecture of the platform, from cloud-based IoT device behavior modeling to JavaScript logic deployment on the IoT devices. We then describe a specific use-case for which we build a prototype and describe aspects of hosting and deploying Javascript runtime logic on heterogeneous lowend IoT devices. Next, we evaluate memory and throughput requirements of our prototype on the IoT device side, which is the bottleneck. We finally review related work before we conclude.

II. ARCHITECTURE

The functional architecture we consider is the interplay of three major domains, as depicted in Fig. 1: • Model concepts : the modelling domain focuses on graphical modelling concepts and corresponding domain specific languages (DSL); • Cloud aspects : the cloud platform domain focuses on the development and deployment of tools necessary to concretize and use the models; and • IoT device aspects : the device platform domain focuses on device registration, business-logic deployment and execution.

Note that including IoT device aspects in the architecture differs from typical cloud-based or fog-based approaches, in which low-end IoT devices are not reprogrammable on the fly, and are not delegate any significant intelligence to pre-process data etc.

A. Sequential Overview

The approach we propose articulates the following building blocks, sequentially.

Automatic IoT Device Registration -Upon booting, each device from the managed fleet of IoT devices registers to a server, which feeds registered device information to the cloud platform providing an Integrated Development Environment (IDE) as described below.

Cloud-based IDE -Using the online IDE, a user can graphically program the business-logic to be deployed and executed on any IoT device managed by the platform. The IDE provides a code-free environment to define smart device behavior. In our prototype, we used the BPMN 2.0 (Business Process Model and Notation) modelling standard. From diagrams in cloud to code -The platform feeds the logic defined graphically in the IDE to a Domain Specific Language (DSL) server, using an XML-based format describing the interaction specified by the BPMN diagrams, including a description for the execution of its elements (graphical notation, process elements organization, interchange format etc.).

From code to embedded code -The engine running on the DSL server automates the translation of the provided XML into standard JavaScript, leveraging an API provided by RIOT, described further in Section V.

Embedded code deployment -The JavaScript file produced is transferred through an inbound gateway which can proxy HTTP and CoAP on one hand, and on the other hand IPv6 and IPv4, in order to cover most connectivity scenarios. The whole sequence from cloud IDE graphical programming, to JavaScript generation and deployment is described in Fig. 3.

Embedded code execution -The JavaScript logic is then executed on the IoT device and can (i) interact locally with the sensors/actuators, (ii) pre-process data extracted from sensors, and (iii) interact remotely with the cloud component to signal alarms or receive messages. More details on a specific interaction use-case are given on Section III.

III. BUILDING AUTOMATION IOT SCENARIO

In the following, we focus on a concrete building automation use-case, for which we built a prototype described in the remainder of this paper. Note that we chose this use-case only for practical, proof-of-concept purposes. The approach we present is generic in that it applies to a wide variety of other IoT use cases.

Low-end IoT devices are managed from a remote "cloudbased" component, to which they connect via a gateway and register to at boot time. IoT devices monitor light and sound level in their physical vicinity, for surveillance purposes. Specifically, if a device detects an abnormal level of light, it monitors the sound level. If the device detects an abnormal sound level in addition to abnormal light, it both triggers an audible alarm and signals the incident via the network, to the cloud component. Upon such signaling, a security guard is alerted on his mobile phone. After dealing on-site with the alarm, the guard confirms the incident is resolved, upon which the cloud component triggers the IoT device to switch off the alarm. The process modelling this scenario is depicted in Fig. 2.

Note how, in such scenarios, the logic on the IoT devices cannot be entirely determined in advance. On one hand, the fine-tuning of the light and sound level thresholds on each device typically need to be calibrated after the deployment, at commissioning time. On the other hand, the processing of raw sensor data may need to be moved from the devices to the gateway, or to the cloud component. Furthermore, devices may need to be removed/added to an existing system, and logic on legacy devices must be updated accordingly.

IV. DYNAMICALLY SCRIPTING IOT DEVICES

We assume that each IoT device runs a small operating system (see survey [START_REF] Hahm | Operating Systems for Low-End Devices in the Internet of Things: a Survey[END_REF]) providing basic services such as scheduling, hardware abstraction to access sensors/actuators peripherals, basic crypto and network connectivity up to an equivalent of BSD socket.

Middleware -We first provide glue code binding a lightweight script engine (such as [START_REF] Gavrin | Ultra lightweight javascript engine for internet of things[END_REF] [6]) supporting a standard script language. This middleware binds the key APIs of the OS with the script interpreter via a simple library added to the script engine. Based on this middleware, IoT device can execute scripts in standard language interacting with the IoT hardware, e.g. setting timers, reading sensor values, setting actuators values, and communicating over the network.

Container & Over-The-Air Scripting -Simultaneously we configure the OS to provision memory for a Web resource (a CoAP resource [START_REF] Shelby | RFC 7252: Constrained Application Protocol (CoAP)[END_REF]) which hosts and exposes a placeholder for text, on which typical RESTful operations are possible.

Locally, on the IoT device, this Web resource contains the scripted logic of the application to be executed. Per construction, the script engine offers sandboxing properties for the application logic, thus providing some equivalent of a runtime software container.

Remotely, from the cloud component point of view (see Section III), this Web resource is then viewed as a container for the application logic to be deployed on the IoT device, with read/write access through standard CoAP messaging (PUT and GET requests).

Security -On one hand, the communication channel between the cloud component and the device (used to discover, read or write the container Web resource) is secured with transport layer security and standard DTLS, which prevent eavesdropping, tampering, or message forgery.

On the other hand, the boiler-plate of the script includes a comment with the hash and cryptographic signature on the whole script (excluding this hash/signature comment). This hash/signature tuple is used to authenticate and authorize overwriting the current script with the new script.

Bootstrap & Device Registration -To bootstrap, we assume the simplest case of pre-shared keys. More advanced bootstrap alternatives beyond pre-shared keys are possible.

At commissioning time, basic registration of a container Web resource can be achieved via standard CoAP resource discovery at the cloud component. Optionally, advanced registration (e.g. detailed description of the capabilities of the device) is possible on top of CoAP signaling. For example, LWM2M registration [START_REF] Rao | Implementing LWM2M in constrained IoT devices[END_REF] is a natural extension of the basic CoAP registration. Note however that alternatives for advanced registration are not limited to LWM2M.

A. Applicability & Trade-off

With the above architecture, from the vantage point provided by the cloud component, an operator can (i) discover the IoT devices which have registered and are currently available, (ii) access their container via the standard Web protocols, and (iii) push arbitrary scripts to containers, which are then start executing on the IoT device(s) which host these containers.

Generally, the architecture we described applies to most cases of remotely-managed fleets of low-end IoT devices -which include our target scenario (see Section III).The approach is agnostic w.r.t. communication technology used below IPv6 (6LoWPAN). Moreover, the approach is agnostic w.r.t. IoT device hardware, beyond basic support provided by the OS. Finally, the approach can achieve sandboxing of application logic on the IoT device, independently of the memory protection capabilities of the IoT hardware. For instance, we demonstrate in Section V this approach running on a CPU which does not have a Memory Protection Unit (MPU).

The key trade-off with this approach is the memory penalty incurred by the script engine, which is significant relatively to the total memory available on typical low-end IoT devices. One can however afford this penalty on many low-end IoT devices, as we show next in Section V. Moreover, for the smallest IoT devices that cannot afford this penalty, the advantage of this approach is that an OS aiming at very low memory footprint could freely (and happily) co-evolve with the middleware bundling we proposed, without compromising on memory overhead for these devices.

V. PROTOTYPE IMPLEMENTATION

In this section we present a prototype implementation of the architecture described in Section II. The components and their articulation are shown in Fig. 4.

A. Cloud Component

In the first phase, we emulated the cloud-based IDE with Copper [START_REF] Kovatsch | Demo abstract: Human-coap interaction with copper[END_REF], an add-on to the Firefox browser providing a CoAP client, from which we could conveniently push JavaScript logic to containers, as described below. In a second phase we used the cloud-based IDE provided by RunMyProcess [10], which we used to automatically generate JavaScript based on simple graphical programming, as described in Section II.

B. Connectivity Setup

We connected low-end IoT devices to the Internet via a RaspberryPi with a IEEE 802.15.4 radio module, configured in a standard fashion to act as a border router between plain IPv6 and the LoWPAN. The set up is shown in Fig. 5.

To register IoT devices to the cloud component, minimalistic LWM2M client functionality was implemented on top of the CoAP API provided by RIOT. The LWM2M client then registers to the LWM2M server (the latter was based on the Leshan implementation [1]). To implement the targeted scenario (see Section III) the LWM2M client function in RIOT just registers at bootstrap phase the resources 3/0, 9/0, 3303/0, and 3315/0, which map respectively to the IoT device, the .js container, the light sensor and the sound-level sensor, as per the OMA standard [START_REF] Rao | Implementing LWM2M in constrained IoT devices[END_REF].

C. Low-end IoT Hardware Aspects

We assembled a low-end IoT device fulfilling the sensors/actuators requirements for the scenario targeted in Section III. From the hardware perspective, based the prototype on a commercially available kit from Microchip, the SAMR21xpro [START_REF]Microchip Atmel ATSAMR21-xpro Board[END_REF], which features a micro-controller, 32kBytes of RAM and 256 kBytes of Flash memory, and a IEEE 802.15.4 radio transceiver. Note that the SAMR21 has no memory protection unit (MPU) in hardware. We extended the SAMR21 with a custom break-out board shown in Fig. 6, connecting via GPIO a light sensor, a sound level sensor, and a revolving light (total cost was about $5 using cheap components).

D. Embedded IoT Software Aspects

From the software perspective, we based our prototype on the open source operating system RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the Internet of Things[END_REF], because of its low memory footprint, its modularity and its matching with the prerequisites identified in Section IV. For the script engine, we chose to use JerryScript, a lightweight Javascript interpreter [START_REF]JerryScript RIOT Package[END_REF]. We then developed the middleware necessary to map JerryScript with the APIs offered by RIOT providing timers, sensor/actuator interaction, event callbacks and highlevel networking (CoAP messaging). The resulting prototype RIOT Javascript API provided by this library is shown below in Listing 1.

Following the approach depicted in Section IV, we then configured RIOT to expose a container CoAP resource, that can be discovered and accessed remotely over the Internet (using the standard IPv6 protocol suite). When hosted in a container on a low-end IoT device with the necessary sensors/actuators, the code shown in Listing 2 (see Appendix) implements the behavior necessary to realize the alarm scenario described in Section III.

E. Evaluation & Discussion

First we verified the basic functionalities of our middleware on an M3 Open Node [START_REF] Adjih | FIT IoT-LAB: A Large Scale Open Experimental IoT Testbed[END_REF] available remotely on the IoT-lab testbed. Then, we verified the full functionalities of the alarm scenario defined in Section III on a SAMR21 in our office, using JavaScript code written by hand, pushed via Copper [START_REF] Kovatsch | Demo abstract: Human-coap interaction with copper[END_REF]. Finally, we pushed and generated JavaScript automatically from the cloud-based graphical programming IDE described in Section II. At runtime, from the cloud component interface, we pushed variations of the Javascript logic shown in Listing 2 (see Appendix), adapting the light and sound threshold parameters appropriately, so as to calibrate the sensitivity of the intrusion detection to the environment it was deployed into. We could verify that updates of the container logic were indeed received, installed and correctly executed on the IoT device.

We then coarsely measured both the memory necessary on the IoT device and the network traffic load incurred on the LoWPAN with this approach. On the SAMR21, the RAM usage was ≈27kB, split as follows: 8kB of heap and 4kB of stack for the Javascript engine, and 15kB for the rest of the OS including the network stack with CoAP and 6LoWPAN. The Flash usage was ≈220kB, roughly split as follows: 160kB for the Javascript engine, 60kB for the rest of the OS including the network stack.

We then assessed the generality of the approach: the code we developed for this prototype is not restricted to the SAMR21 board, but can be readily compiled and run on more than 84 different types of IoT devices, which corresponds to more than 80% of all the IoT hardware supported by RIOT.

Based on the above numbers, and compared to implementing in C similar functionality for the application logic, the memory overhead caused by JavaScript is thus ≈12kB of RAM and ≈160kB of Flash memory. However, in order to update the functionality dynamically on the device, a firmware update mechanism is necessary on top of the basic OS and the application logic. Taking the case of full firmware update, the RAM requirement would not be significantly impacted, but the required Flash memory increases significantly: typically twice the image size is needed (in our case 120kB for the OS including the network stack), with a small additional space for the bootloader (≈4kB is a conservative estimation). Hence, the total overhead is in fact ≈12kB of RAM and ≈96kB of Flash memory, which is thus a significant penalty compared to an optimized C implementation. this is affordable if the IoT device has enough available memory: typical memory resources for such devices (e.g. 32kB of RAM and 256kB of Flash) are more than enough, as we have demonstrated.

On the other hand, in the case of the scenario defined in Section III, the number of bytes transmitted over-the-air to update the device with our container is 1kB (the size of the script shown in Listing 2 shown in Appendix). Compared to this, a full firmware update approach requires the transmission of an entire image, thus ≈60kB, which is significant penalty in comparison. However, with a partial firmware update technique, this penalty could be reduced.

F. Prototype Reproducibility

The simplest way to play with a prototype similar to the one described in the previous section is to remotely use the IoT-Lab testbed [START_REF] Adjih | FIT IoT-LAB: A Large Scale Open Experimental IoT Testbed[END_REF] as described in this guide [START_REF]Guide to RIOT[END_REF]. To reproduce exactly the prototype including the hardware, three main components are needed (i) one or more IoT device(s), (ii) a border router, (iii) global IPv6 connectivity from the border router to the rest of the Internet, and (iv) the online IdDE.

IoT device -The IoT device hardware can be reproduced by assembling a SAMR21-xpro board (commercialized by Microchip [START_REF]Microchip Atmel ATSAMR21-xpro Board[END_REF]) and a breakout board connected via GPIO with the elements listed in Fig. 7. The IoT device software can be reproduced by using RIOT configured as in [START_REF] Riot | SAMR21[END_REF], and specifying the custom target LwM2M server address and port. This software provides local IPv6 connectivity to the IoT device and hosts the JavaScript container, accessible via CoAP on top of IPv6.

Border router -The border router hardware can be reproduced with a Raspberry Pi on which is plugged an IEEE 802.15.4 wireless communication module from Openlabs [START_REF][END_REF]. The border router software can be reproduced by using Linux (Raspbian with a Linux Kernel 4.9 or newer) which supports IEEE802.15.4 and 6LoWPAN. This software enables the border router to route IPv6 (and thus CoAP) traffic from the LoWPAN to the IPv6 backbone (the Internet) via its other network interfaces (typically Ethernet or Wifi).

Global IPv6 connectivity -In most networks, IPv4 connectivity is provided natively, but not IPv6. If IPv6 is not natively supported, the Raspberry Pi must somehow provide IPv6 tunneling through IPv4. This can be configured using a free tunnel broker such as Hurricane Electric [START_REF]Hurricane Electric Tunnel Broker[END_REF].

Online IDE -The cloud-based IDE we used to enable graphical programming and automatic Javascript code generation is provided by RunMyProcess [10]. A simplified version of the prototype (not using graphical programming) can be based on a simple browser client such as Copper [START_REF] Kovatsch | Demo abstract: Human-coap interaction with copper[END_REF].

VI. RELATED WORK

Updating software on a deployed IoT device is typically done via over-the-air firmware update. With this approach, Fig. 7: Break-out board hardware elements. logic is updated and recompiled remotely, to produce a whole new firmware image, which is then downloaded and booted by the device [START_REF] Acosta Padilla | The Future of IoT Software Must be Updated[END_REF]. Another category of solution is partial firmware update, which include approaches such as dynamic loading of binary modules [START_REF] Dunkels | Run-time Dynamic Linking for Reprogramming Wireless Sensor Networks[END_REF], or differential binary patching [START_REF] Jeong | Incremental network programming for wireless sensors[END_REF]. If the difference in the binary is small, such approaches bring significant savings can be achieved in terms of bits-over-the-air (desirable on low-power, low-throughput networks).

Modelling and Orchestration of IoT logic is evolving from early approaches based on static, centralized schemes, to more dynamic and more distributed techniques. Early static, centralized approaches include trigger-action programming service IFTTT ("If This, Then That" [START_REF] Ur | Trigger-action programming in the wild: An analysis of 200,000 ifttt recipes[END_REF]). NodeRED [START_REF] Nodered | [END_REF] extends the concept of IFTTT with more advanced modelling and graphical programming, but still does so in a centralized fashion. Examples of more dynamic and more distributed approaches are swarmlets using actors programming for IoT scenarios [START_REF] Hiesgen | Embedded Actors-Towards distributed programming in the IoT[END_REF] [START_REF] Latronico | A vision of swarmlets[END_REF], tasklets distributed at compile-time across nodes running TinyOS [START_REF] Gnawali | The tenet architecture for tiered sensor networks[END_REF], or techniques leveraging an information-centric paradigm to dynamically distribute IoT logic via named function networking [START_REF] Król | NFaaS: Named function as a service[END_REF]. Recent prior work in this domain also proposed Actinium [START_REF] Kovatsch | Actinium: A restful runtime container for scriptable internet of things applications[END_REF], an approach using small, distributed runtime containers on computers proxying for low-end IoT devices, accessible as Web resources, and hosting JavaScript logic.

Small memory-footprint embedded programming with bytecode interpreters was explored in early work such as Maté capsules [START_REF] Levis | Maté: A tiny virtual machine for sensor networks[END_REF] on TinyOS. Recent advances have brought the availability of very small script interpreter engines such as JerryScript [START_REF] Gavrin | Ultra lightweight javascript engine for internet of things[END_REF], or MicroPython [START_REF]MicroPython[END_REF]. In this paper, we thus explore the potential of orchestrating runtime containers of scripted logic on low-end IoT devices. To the best of our knowledge, the closest prior work is Actinium. Compared to Actinium, we eliminate the need for Web resource proxying, as runtime containers are running directly on the low-end IoT devices. From the modelling tools perspective, the closest work is NodeRED. Compared to NodeRED our platform is more holistic in the sense that it encompasses both embedded containers, deployment and modelling in the cloud. The javascript container described in this paper was previously presented in [START_REF] Baccelli | Scripting Over-The-Air: Towards Containers on Lowend Devices in the Internet of Things[END_REF]. Contrary to [START_REF] Baccelli | Scripting Over-The-Air: Towards Containers on Lowend Devices in the Internet of Things[END_REF], this paper (i) encompasses the description of the full architecture also encompassing IoT device behavior modelling, the cloud-based IDE and automatic JavaScript code generation, and (ii) includes full details on how to reproduce the prototype.

VII. CONCLUSION

In this paper, we have how the combination cloud-based IDE and scripting-over-the-air with runtime containers hosted on low-end IoT devices (i) provides a generic solution for dynamic deployment of application logic on such devices, (ii) requires less than 32kB of memory on the devices, and (ii) saves bits-over-the-air compared to firmware updates. On one hand, such an approach can bring DevOps to low-end IoT devices. On the other hand, IoT system designers can decide after deployment which part of the intelligence should remain in the cloud, and which part should be embedded in the low-end IoT devices themselves. Last but not least, programming low-end IoT devices with an online graphical IDE significantly lowers the bar for programmers without strong embedded skills.

Fig. 1 :

 1 Fig. 1: Interplay of domains.

Fig. 2 :

 2 Fig. 2: Overall intrusion detection process.

Fig. 3 :

 3 Fig. 3: Sequence towards automatic deployment of IoT business logic.

LwM2M

Fig. 4 :

 4 Fig. 4: Prototype components.

Fig. 5 :

 5 Fig. 5: Gateway connecting the cloud to a low-end IoT device, running an operating system hosting a container.

Fig. 6 :

 6 Fig. 6: SAMR21-xpro with custom break-out board connecting light sensor, sound level sensor, buzzer and revolving light.


Capucine Carlier

Iris Brémaud

Miyuki Matsuo

Eiichi Obataya

Masashi Nakamura

Tancrede Almeras

Joseph Gril

Carlier Capucine

Matsuo Miyuki

Obataya Eiichi

Nakamura Masashi

Almeras Tancrède

Gril Joseph

« CHARACTERISTICS OF "RESONANCE WOOD" AS VIEWED BY VIOLIN MAKERS OR BY WOOD SCIENTISTS: PART 2 -CHARACTERISATION AND CORRELATIONS OF STRUCTURAL AND MECHANICAL PROPERTIES »

come

Introduction

The objective of this study is to improve the understanding of the interactions between physic-mechanical properties of resonance wood, their natural variability, and the actual expertise of violin makers in the selection and qualification of their raw material.

o 10 Viola and 14 violin soundboard, Quality grades "Excellent" and "Master grade" o 72 samples in R radial direction (120×2,5×12mm, R×T×L) and 177 samples in L longitudinal direction (12×2,5×150mm, R×T×L).

Measurement of visual/structural characteristics (growth-ring width, uniformity and percentage of latewood). Density is mostly affected by latewood Proportion(Lw).

Measurement of physical and vibrational properties and the acoustical indexes of the specimens

Ring width (Rw) and Lw reflect vibrational properties. Density provides information on the acoustical indexes.

Visual parameters = indicators of wood mechanical properties

Link between specific modulus and density unexpected => microstructural explanation ?

Correlations between properties, acoustical index and visual characteristics of wood

=> Necessity to construct a model to evaluate the properties of a full violin plate from sampling fabrication offcuts

Conclusion and perspectives

To go further : Work in progress 2. Visual and vibrational features of spruce

 Specific modulus of elasticity E'/ρ  Damping coefficient / internal friction tanδ=Q -1

Evolution of density, specific modulus and damping within the radial direction of violins soundboards

High variability within and between plates  a single specimen may not be representative of the properties of the entire board.

Relation between visual characteristics of spruce wood and its properties

Resonance wood Classical spruce Kubojima and al., 1997 (Longitudinal and Radial; 3 weeks at 65% relative humidity and 20°C, Frequency range 100-750 Hz)

Material and Methods

ACE=R/tanδ

Can the microstructure of wood (microfibril angle) be the cause of the specificities of resonance wood ?

  Radial distance (cm) from plate's centre Radial distance (cm) from plate's centre Radial distance (cm) from plate's centre the confidence of luthiers for their suppliers coming from the pre-selection of an uncommon material?

••

  MFAEW(early/spring wood) > MFALW (late/summer wood) • MFA from high quality plates < MFA low quality plates • Next step : to study the link between MFA, visual characteristics and wood properties Vibrational tests: beyond indicators of "amplitude and response", how to get indicators of "timbre"? • GAcer (maple) > Gpicea (spruce) • Spruce: G from high quality plates are clearly lower than G from low quality plates (0.7 for 1st quality to 1.2 for 4th quality) • No clear trend for tanδ Wood properties: variability and correlations How can we determine the appearance of wavy grain of curly maple ? Noticeable features are changing by the lighting azimuth. • Calculating differences of the lightness in local 3x3 area (local contrast) everywhere at every filter size The authors gratefully thank Daniel Guibal in CIRAD, Montpellier for the assistance during the experiments and Bernard Michaud for his time and help to choose our wood. The support of CNRS-INSIS, of Région Languedoc-Roussillon and of the Japan Society for the Promotion of Sciences (JSPS) is gratefully acknowledged.  Acknowledgments This study shows the peculiarity of spruce "resonance wood" in regards to classical softwoods. Empirical choice by violin makers, based on perceptual criteria that can be visual, physic-mechanical, auditory, are relevant to the acoustic properties measured  Perspectives • To construct a model to evaluate the properties of a full violin plate from sampling fabrication offcuts. • To analyze microstructural features of resonance wood in regards to visual characteristics and wood properties • To enlarge the study to 'fiddleback' maple. Sampling plan R L

device for non contact forced vibrations testing of free-free beams developed in LMGC

« Vybris », a

o Spruce (Picea abies [L.

] Karst) Visual characteristics analyzed by an Image J plugin developed by Tancrède Alméras (LMGC) Rw (mm) Lw (%) mean Lw (%) r/r Density ρ

	Density ρ -0.44	0.78	0.75
	EL/ρ	-0.63	0.86	0.86	0.69
	ER/ρ	0.69	-0.55	-0.56	-0.36
	tanδL	0.58	-0.63	-0.65	-0.28
	tanδR	-0.74	0.73	0.73	0.59
	zL	-0.51	0.84	0.82	0.98
	RL	0.28	-0.58	-0.54	-0.93
	ACEL	0.00	-0.25	-0.21	-0.72