2017-10-01 20 views
5

Rijndael key schedule procedure 모든 _mm_aeskeygenassist_si128에서 지원하는 RotWord, SubWordXOR, 포함 :SSE의 AES가 전체 기능을 제공하지 않는 이유는 무엇입니까?

X3[31:0] ← SRC [127: 96]; 
X2[31:0] ← SRC [95: 64]; 
X1[31:0] ← SRC [63: 32]; 
X0[31:0] ← SRC [31: 0]; 
RCON[31:0] ← ZeroExtend(Imm8[7:0]); 
DEST[31:0] ← SubWord(X1); 
DEST[63:32 ] ← RotWord(SubWord(X1)) XOR RCON; 
DEST[95:64] ← SubWord(X3); 
DEST[127:96] ← RotWord(SubWord(X3)) XOR RCON; 
DEST[VLMAX-1:128] (Unmodified) 

그러나, 그것은 완전한 라운드 키를 반환하지 않습니다. 예를 들어, 대신 단순히

DEST[31:0] <- SubWord(X1)

,

을 수행하는 동안 나는 우리가 실제로

DEST[31:0]<-RotWord(SubWord(X3)) XOR RCON XOR X0을 수행해야합니다 같아요.

결과적으로 _mm_aeskeygenassist_si128 이후 개발자는 라운드 키가 완전히 생성되기 전에 추가 작업을해야합니다.

SSE가 완벽한 AES 키 생성 절차를 제공하지 않는 이유는 무엇입니까?

답변

6

Intel의 AES-NI 백서에서 Key Expansion Using AESKEYGENASSIST (page 23)을 참조하십시오. 이들은 명령어가 128/192/256의 서로 다른 키 크기를위한 빌딩 블록으로 사용될 수 있다고 지적했습니다. 단지 128b에 대한 예를 보여 주며 설명 할 때마다 aeskeygenassist 명령어를 사용한 후 함수 호출로 추가 작업을 수행합니다.

AESKEYGENASSIST 이미 마이크로 코드 (예 : 13 스카이 레이크에 마이크로 연산 대 만 1 AESDEC/AESENC (http://agner.org/optimize/)), 그렇게하지 것이다 다양한 키 크기에 따라 다릅니다 지난 몇 단계를 수행 다른 지침을 가지고 현재 구현되는 방식보다 훨씬 빠릅니다.

Skylake는 12 사이클 당 1 개의 처리량을 가지고 있지만, Nehalem은 aesenc과 같은 2 사이클 당 1 회의 처리량을 가지고 있습니다. 그래서 Nehalem에서는 대부분 전용 하드웨어로 구현 한 것 같습니다. 이것은 아마도 설명의 다른 부분 일 것입니다. 더 많은 단계가 1 세대 구현에서 더 많은 하드웨어를 가져 왔을 것이거나 그 명령을 마이크로 코드로 만들었을 것입니다 (아마도 Nehalem에는 없었을 것입니다).

Intel은 Nehalem 이후에 aeskeygenassist의 성능을 저하 시켰기 때문에 분명히 키 설치가 성능에 중요하다고 생각하지 않습니다. (심지어 샌디 브리지. 그들은 1 당 8 클럭 처리량 microcoded했다) 더 오피 코드를 촬영 한 것


다른 키 사이즈에 대해 서로 다른 지침을 가졌어요. 이 시점에서 인텔은 VEX 접두사를 아직 도입하지 않았으므로 AES 지침에 더 많은 opcode 공간을 사용하면 향후 확장을 위해 남겨진 공간이 줄어들 것입니다. (VEX는 현재 지침에서 사용되는 기존의 필수 접두어 조합에 대해 여러 비트 코드 만 사용하여 사용할 수있는 많은 코딩 공간을 가지고 있습니다.