3

Hello Everyone I am trying to build a code to do demonstrate doing AES encryption in assembly. the latest Intel manual has

AESENC xmm1,xmm2/m128 —Perform One Round of an AES Encryption Flow round key from the second source operand, operating on 128-bit data (state) from the first source operand, and store the result in the destination operand.

AESENCLAST xmm1, xmm2/m128 —Perform Last Round of an AES Encryption Flow a round key from the second source operand, operating on 128-bit data (state) from the first source operand, and store the result in the destination operand.

AESKEYGENASSIST xmm1, xmm2/m128, imm8 Assist in expanding the AES cipher key, by computing steps towards generating a round key for encryption, using 128-bit data specified in the source operand and an 8-bit round constant specified as an immediate, store the result in the destination operand.

To do this I will be trying inline assembly, I will be building it to compare speeds with normal AES done in C! my first brainstorm took me thinking how to use xmm in inline assembly any help/brainstorming/sharing ideas concerning my probs or the idea in general is welcome Cheers=)

Syntax_Error
  • 5,964
  • 15
  • 53
  • 73
  • I'd rather code a COBOL compiler in assembly than any cryptography in assembly. – San Jacinto Jan 05 '11 at 22:07
  • 3
    @SanJacint: Cryptography is one of the few use-cases where hand crafted assembly is really a good idea. It's short, well defined code that needs high performance. And in case of AES there are even special instructions. – CodesInChaos Jan 05 '11 at 22:09
  • FWIW The PadLock (xcrypt*) instructions on VIA processors also support AES algorithms, and having been around for longer than Intel's extensions, there's more benchmarked material out there. – ephemient Jan 05 '11 at 22:19
  • 1
    So what's the problem, exactly? – Chris J Jan 05 '11 at 22:19
  • 1
    @San:if it hadnt been for the specialized Intel insns I wouldnt have gone there but AES is a special case that Intel has dedicated macro ops for, plus in assembly it should be faster – Syntax_Error Jan 05 '11 at 22:20
  • @Chris: inline assembly and xmm usage – Syntax_Error Jan 05 '11 at 22:34
  • @Syntax_Error ... in what way? Looking for example on how to use the instructions? A guide to assembly? Something else? I can't quite see what it is you're asking for help with. Have you tried anything so far, and if so, what problems have you bumped into? – Chris J Jan 05 '11 at 22:51
  • @Chris: I have written a code, but the problem I am facing as I write is how to mov 128 bits to xmm registers. because as u can c the upper instructions take as operands xmm or mem128. I want a way to get my operand to either one of them so I can work on them. – Syntax_Error Jan 05 '11 at 23:05
  • I have to say, when I saw that implementation note in SSEx (4?) I concluded that they were absolutely out of decent ideas on how to move the processor instruction set forward. It's done. – Hans Passant Jan 05 '11 at 23:11
  • @Syntax_Error please revise this so there is a *specific* question to answer ([read this for some help](http://tinyurl.com/so-hints)). – Richard Jan 07 '11 at 11:06

1 Answers1

2

If you want to get a 128-bit value into an XMM register, look at the MOVDQA and MOVDQU instructions.

Anon.
  • 58,739
  • 8
  • 81
  • 86
  • looked into it but both take the second operand as xmm or mem128...i want some way to move immediate to xmm....Im new to inline assembly so if im wrong let me know:) – Syntax_Error Jan 05 '11 at 22:28
  • @Syntax_Error: You can use `MOVD` to move a general-purpose register into an XMM one, but that will zero-extend it to 128 bits. Which works fine for small constants, I guess. Anything larger than that you've probably got sitting on the stack anyway. – Anon. Jan 05 '11 at 22:37
  • so what ur saying is that ill be limited to 64 bit operands? – Syntax_Error Jan 05 '11 at 22:41
  • @Syntax_Error: You can load 128-bit operands from memory just fine. If you really don't want to do a load from memory, you can fiddle about with the insert commands (forex: `PINSRD`) which let you specify where in the xmm register you want the operand to be placed. – Anon. Jan 05 '11 at 22:46
  • the PINSRD looks promising. I might look into it. I am aiming at the easiest way to look a 128 bit to xmm. I want to load from memory, but my problem is how do I move the operand to memory in the first, and where is its location and how to address it? – Syntax_Error Jan 05 '11 at 23:02
  • 2
    @Syntax_Error: It depends on what the source of that operand is. For example, if it's encrypted data coming off the network, you'll probably read it straight into the xmm register from wherever the device driver leaves it. If you're providing a C interface to this code, then the key material will probably be passed in on the stack, and once again you'll just read that straight into the appropriate xmm register. If you've done some calculations and want to move the result into xmm registers, you can either use a sequence of inserts or copy it to the stack and then back. – Anon. Jan 05 '11 at 23:15