Subject: [Ipsec] Implementaton of AES-XCBC-MAC-96

From: Pooja Kamra <[email-masked]>
Date: Mon, 25 Sep 2006 16:29:13 +0530 (IST)

Hi,
 
In the RFC 3566, while generating K1, K2, and K3 from secret key K, what is the IV to be used. In the test vectors given in the RFC, IV is not specified. So, for generating three keys, do we have to use AES encryption in ECB mode, that doesn't need IV, or we have to use 
"E[0] = 0x00000000000000000000000000000000" as the IV.
 
Is there any sample implementation of the same available.
 
Regards
Pooja

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Mon, 25 Sep 2006 16:15:14 +0300

Pooja Kamra [mailto:[email-masked]] wrote:
> Hi,
>      
> In the RFC 3566, while generating K1, K2, and K3 from secret key K,
> what is the IV to be used. In the test vectors given in the RFC, IV
> is not specified. So, for generating three keys, do we have to use
> AES encryption in ECB mode, that doesn't need IV, or we have to use

It's just a single "raw" AES encryption operation (I guess you
could call it ECB in this context).

> Is there any sample implementation of the same available.

FreeBSD's IPsec supports XCBC-MAC.

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Sep 2006 16:47:13 +0300

> could call it ECB in this context).

You still have to XOR the previous encrypted block from the message  
with the next plaintext block of the message, so it's not like ECB.   
It's like CBC.

The best description is that it's CBC with an IV of zero.  E[0] here  
serves the same purpose as an IV in CBC.

---

From: <[email-masked]>
Date: Mon, 25 Sep 2006 16:54:20 +0300

> serves the same purpose as an IV in CBC.

That's true about the actual MAC calculation (steps 2..5), but
the original question was about the K1/K2/K3 calculation (step 1),
where you don't XOR any previous blocks (and you have only
a single block).

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Sep 2006 16:58:53 +0300

> where you don't XOR any previous blocks (and you have only

Oops.  You're right.  Should have read it more carefully.

---

From: Pooja Kamra <[email-masked]>
Date: Tue, 26 Sep 2006 11:50:33 +0100 (BST)

Hi,

Thanks for clearing my doubt. I am still stuck at one
place. Can some one please help!!

Does anyone have step to step results of XCBC-MAC for
one of the published test vectors?

I have verified my implementation with other AES-XCBC
MAC implementations and it seems to be same.

But my tests seems to be failing. I am for now just
using test vector 3, i.e 

Test Case #3   : AES-XCBC-MAC-96 with 16-byte input
Key (K)        : 000102030405060708090a0b0c0d0e0f
Message (M)    : 000102030405060708090a0b0c0d0e0f
AES-XCBC-MAC   : d2a246fa349b68a79998a4394ff7a263
AES-XCBC-MAC-96: d2a246fa349b68a79998a439

my result seems to be unmatching with known.
Can any one provide me value of k1, k2, k3 please. 
Its going to be same for all the test vectors in The
RFC.

regards
Pooja

> where you don't XOR any previous blocks (and you

___________________________________________________________ 
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html