Timeline for Counter based cipher using HMAC-SHA-256
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
|
|
| Jun 28, 2016 at 12:19 | comment | added | Gilles 'SO- stop being evil' | @poncho True, you can take a variable-length key and hash it to produce the “real” key. This has always seemed iffy to me: why specify an ad hoc KDF? Even so I still don't understand that statement in the question. | |
| Jun 28, 2016 at 3:30 | comment | added | poncho | "HMAC-SHA256 uses a 32-byte key" - actually, HMAC-SHA256 uses a variable length key; any length between 1 byte and $2^{61}-1$ bytes | |
| Mar 9, 2015 at 22:55 | comment | added | Thorham | I only included both pads in the text to show that I'm not forgetting them. Everything is self written in assembly language based on existing C code (AES), pseudo code (SHA256) and explanations (HMAC). | |
| Mar 9, 2015 at 22:29 | comment | added | Gilles 'SO- stop being evil' | @JohnSmith I'm not sure what you're describing here but this is not HMAC. If you were using HMAC, you wouldn't be talking about IPAD and OPAD — they're purely internal to the HMAC primitive. | |
| Mar 9, 2015 at 22:23 | comment | added | Thorham | It doesn't seem so tricky. The message for the first SHA hash is the first HMAC key (with IPAD), the initial counter, the cipher text and normal SHA padding. The the message for the second SHA hash is the second HMAC key (with OPAD), the first SHA hash and normal SHA padding at the end. This second hash is the authentication tag. Seems simple enough. | |
| Mar 9, 2015 at 22:18 | comment | added | Gilles 'SO- stop being evil' | @JohnSmith Because combining them is tricky (see the threads I link to). “Creating your own” is bad because you're using primitives whose behavior is not well-known, so it's delicate at best to use them correctly. In the case of HMAC+CTR, it's known that it's a tricky combination, and neither encrypt-then-mac nor mac-then-encrypt can be used without being very very careful. Using a known authenticated encryption mode frees you of this concern. | |
| Mar 9, 2015 at 22:13 | comment | added | Thorham | Why? How is picking an encryption mode and an authentication mode creating your own mode? | |
| Mar 9, 2015 at 22:11 | comment | added | Gilles 'SO- stop being evil' | @JohnSmith But combining them makes a new mode, AES-CTR+HMAC-SHA256. | |
| Mar 9, 2015 at 22:09 | comment | added | Thorham | I'm not using my own mode. I'm using AES CTR as the cipher and HMAC SHA256 as the authentication mode.As for the IV/counter, I understand that the counter can't stay the same for each block, it's a counter after all. | |
| Mar 9, 2015 at 20:34 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |