Can someone explain how the RC2 key schedule works (particularly the very beginning of it)? i know it uses little endian, but my implementation is not working for any key except "0000 0000 0000 0000"
Test Vector
Key = 88bc a90e 9087 5a
Plaintext = 0000 0000 0000 0000
Ciphertext = 6ccf 4308 974c 267f
im assuming that the first thing to do with the key would be to change it into
bc88 0ea9 8790 5a
and yes i know RC2 is not even used anymore, but i would still like to know
The RFC says:
The key expansion algorithm begins by placing the supplied T-byte key into bytes L[0], ..., L[T-1] of the key buffer.
So if your key is 88bc a90e 9087 5a you get L[0]=0x88, L[1]=0xbc, ... L[6]=0x5a.
No need to consider any endianess here.
If you want to treat the key-buffer as 16-bit words you get:
K[i] = L[2*i] + 256*L[2*i+1]
I.e. K[0] = 0xbc88, K[1] = 0xa90e, K[2] = 0x8790. L[7] is only assigned later in the key-expansion step, so strictly speaking K[3] is undefined at this point. Feel free to choose any value you want however, since it makes no difference to the algorithm. If you select 0, you get K[3] = 0x005a.
Related
Anna wants to send a message with a random arrangement of only 5 words, which are
INPUT, GET, HTTP, OUTPUT, POST
like
INPUTGETOUTPUTPOSTGETHTTPHTTPINPUTGET
Each letter occupies 1 byte, and the entire message will be aligned to an integer multiple of 128 bits by adding 0 at the end of the message.
After getting the message to be sent, Anna divides it into several 128-bit (16 bytes=16 letters) plaintext blocks from beginning to end, like
INPUTGETOUTPUTPO, STGETHTTPHTTPINP, UTGET00000000000
Randomly pick 2 plaintext blocks P1 and P5, and use a same 128 bit key to get cipher block C1 = P1 xor key C5 = P5 xor key.
Now suppose I am an adversary. I know all the above encryption algorithms, and intercepted 2 ciphertext blocks CA and CB, and can determine that 2 ciphertext blocks are generated by the same key K1.
The question now is how to decrypt the key and 2 plaintext blocks with the above information.
I have tried many ways, and the ideas are all broken. I am very grateful for the ideas and opinions that have helped me.
This is a version of two-time pad. I believe this is a contest question so only give you the hint.
X-or the two ciphertext
PP = CA x-or CB = PA x-or key x-or PB x-or key = PA x-or PB
Now apply one of your limited texts say OUTPUT to x-or with this PP by sliding and see that the x-or reveals some other. If you see one, now you get the position of OUTPUT in PA. Now you find some in PB too. continue...
Is there any way to change standart S-Box and Inv. S-Box of AES algorithm with another pair of S And Inv S -boxes?
Standard S-Box and inv. S-Box here: http://en.wikipedia.org/wiki/Rijndael_S-box
The only possible explanation is that your sBoxInv is not the inverse of sBox. A simple check reveals that sBox[5e] = 6a, whereas sBoxInv[6a] = 68 (and not 5e as it should be).
I am trying to decipher a trace of USB I/O traffic produced by usbmon and am having some issues getting my head around the endianness. For the sake of example, here are two lines from the trace I am working with:
ffff8800650e7000 433121059 S Ci:2:000:0 s 80 06 0100 0000 0040 64 <
ffff8800650e7000 433121661 C Ci:2:000:0 0 18 = 12010002 00000040 da0b8781 00010102 0301
I initially had no suspicion whatsoever of anything other than big-endianness in the trace, but then I saw da0b8781 in the second line, which corresponds to the identity of the USB device I am tracing which has a vendor ID of 0x0bda and product ID of 0x8187 (note the reversal of byte-order in the trace).
So at this point I thought that maybe within a given field of a usbmon trace, the bytes were always in reverse byte order and should be interpreted as such. But to the contrary, let's examine a small part near the end of the first trace line, ... 0040 64
0040 is a hex field representing the maximum accepted response size. 64 is a decimal field that should represent exactly the same thing. 0x0040 = 64 decimal, without switching the byte order to 0x4000, which would then != 64 decimal. So it's at this point I started to get a bit uncertain about the byte-order of the different parts of the usbmon trace.
Next I thought, maybe it's just the data portions of the usbmon trace that are in reverse byte order. So I thought perhaps I should really be reading
...12010002 00000040 da0b8781 00010102 0301
as
1030 20101000 1878b0ad 04000000 20001021...
Nope, that doesn't seem to be right either. The USB Specification states that the vendor Id (0x0bda in my case) should be at byte offset 8 for this particular string. If we leave the above string in its original order, then the vendor Id does start at byte offset 8 (12010002 00000040 consumes the first 8 bytes), but if we reverse it as I have above, then it starts at byte offset 6 (1030 20101000 only consumes the first 6 bytes).
So my best guess now is that usbmon displays everything big-endian, accept that it switches to reverse byte order within each 4-byte word, but for data only. Can anyone offer some clarification on whether this is correct, or whether there may be something else I'm missing?
May be a bit late for you but I've tried usbmon (and found it OK)
you may want to take a look at evtest
http://www.freedesktop.org/wiki/Evtest
I was hoping someone could help me with the PIV smart card standard.
I would like to authenticate the smart card by making it sign a PKCS#1 padded nonce with the previously generated RSA 1024-bit modulus Digital Signature Key 0x9C. Here is what the output of my test application looks like:
Requesting Signature
Sending: 0087069C867C84820081800001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00CB441C4A656E071F1FB9F31BC6AB1824324FB42780
Error: (6A80) Incorrect parameters in command data
And here is the breakdown:
00 - Not chained (chaining not required because message does not exceed max length)
87 - GENERAL AUTHENTICATE
06 - RSA 1024 Algorithm
9C - Digital Signature Key
86 - Length of data field
7C - Dynamic Authentication template identifier
84 - Length of dynamic authentication template
82 - Response
00 - Response length 0 (Response requested)
81 - Challenge
80 - Challenge length 128
0001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00CB441C4A656E071F1FB9F31BC6AB1824324FB427 - PKCS #1 padded 20-byte Nonce (Padded with OpenSSL RSA_padding_add_PKCS1_type_1)
80 - Expected response length (128 bytes)
I have also run tests using all of the different keys (having generated all of them successfully already) and using chained messages vs single part messages.
See further test data.
There was a bug with the PIV card applet loaded on my smart card. It will not sign any data that starts with 0x00. If you change the 0x00 to anything else (as long as the data as an integer is less than the modulus as an integer per requirement of the RSA algorithm) it will sign successfully. So of course this means these cards cannot sign any standard PKCS1 padded data :(
Thanks for the help
http://en.wikipedia.org/wiki/CMAC
http://www.rfc-archive.org/getrfc.php?rfc=4493
There are two keys K1 and K2. Are there any other reasons, beside that messages 1 differs from 10^127 (1 and 127 zeroes)
If message carries length (and length is also CMAC-ed whit message), are there any security weaknesses using only one randomly generated K?
First of all, there's really only one key K in AES-CMAC - it's the only one you have to generate, to address your last question, and that's stated explicitly in the spec:
The subkey generation algorithm, Generate_Subkey(), takes a secret key, K, which is just the key for AES-128.
Your other question - why do we need to generate K1 and K2 from K - is a little bit harder to answer, but there's actually a very simple explanation: to eliminate any ambiguity in the message authentication.
To illustrate, supposed we take the binary keys from the wiki article: K1 = 0101 and K2 = 0111. Now let's play with the message M = 0101 011. Because M is not made up of full blocks (three bits rather than four), we have to pad it. Now we have M' = 0101 0111.
To generate the MAC for this message, we just have to XOR our keys in:
M' = 0101 0111
K1 = 0101
K2 = 0111
MAC = 0000 0000
If we had used K1 in both cases, then we'd have the following procedure:
M' = 0101 0111
K1 = 0101
K1 = 0101
MAC = 0000 0010
This is all fine and good, but watch what happens when we try to generate a MAC for M'' = 0101 0111 (that is, an unpadded message M'' identical to the padded message M').
M'' = 0101 0111
K1 = 0101
K1 = 0101
MAC = 0000 0010
We've generated the same MAC from two different messages! The use of the second key (which has some number-theoretical properties that prevent it from being problematically "similar" to K1) prevents such an ambiguity.
I don't believe it has to do with known-plaintext attacks, and I disagree with symmetric ciphers are susceptible to them. One of the conditions of a cipher being secure is that it is secure under KPA, CPA (chosen-plaintext attacks) and CCA (chosen-ciphertext attacks).
Unless I am not understanding your question, yes, you still need both subkeys. K2 is used when a block is not a complete block.
.
K1 and K2 are not randomly generated, but are derived from K. Is there a reason you do not want to generate these subkeys?
There are a number of weaknesses in authentication codes based on chaining modes. CBC-MAC was provably secure only for fixed size messages. The security completely fails for variable length messages where the last block is padded.
You can read the XCBC paper to see how the attack works:
"As a simple example, notice that given the CBC MAC of a one-block message X, say
T = CBCEK(X), the adversary immediately knows the CBC MAC for the two-block message X || (X ^ T)
since this is once again T."
[1] http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf
I suppose symmetric ciphers are susceptible to know-plaintext attacks, at least they have been in the past. And since you do a portion of the plaintext (the padding pattern) you don't want to leak information about your key. If you can extract some bits of the key that way you can brute-force attack the last block but all other blocks remain secure (under this KP attack at least) since they have been encrypted via K1.
To overcome the very same problem, block-based ciphers usually operate in various modes, see:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation. Don't know why this obvious solution hasn't been considered in the design of CMAC.