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).
Related
Does it make a problem about security as long as key and iv kept secret but same?
Thanks.
UPDATE: I did some research and learned why iv used. As mentioned in the answer below it's a protection way against frequency attacks. And there is two requirements when creating iv: uniqueness and unpredictability.
The algorithm that I thought for creating aes key and iv is:
Get two values from a certain elliptic curve point that agreed before by using asymetric encryption.(x,y)
Aes.Key <- HASH(x)
(string)unique <- timestamp()
(string)unpre <- y
Aes.IV <- HASH(unique + unpre)
And share data as {encryptedmessage, timestamp}
Is this logic alright?
You need a random (or at least pseudo-random) Initialization Vector for block ciphers like AES.
Ripped straight from Wikipedia:
Randomization is crucial for encryption schemes to achieve semantic
security, a property whereby repeated usage of the scheme under the
same key does not allow an attacker to infer relationships between
segments of the encrypted message.
In an Atmel datasheet, I see a notation I've never seen before, for example:
Register bits MAX_BE define the maximum value of the backoff exponent in the CSMA- CA algorithm. It equals macMaxBE; refer to section 7.5.1.4 of [2]. Valid values are [4’d8, 4’d7, ... , 4’d3].
How does one interpret/decode the 4’d# values?
That looks like verilog to me (or at least it's the same format as verilog uses).
4'd# means a 4-bit field, with a decimal value of #.
So 4'd8 is binary 1000.
Other number formats can be 'h (hex representation), or 'b (binary representation)
examples:
16'd1 = 0000000000000001
8'hff = 11111111
5'b10101 = 10101
(etc).
I'm not sure what the notation is supposed to mean, but a similar datasheet for an Analog Devices chip lists the valid values as 3 to 8, so I'd guess the actual values this one wants are also 8,7,..3.
Edit
I think Tim is right.
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.
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.
I'm trying to encrypt some date using a public key derived form the exchange key pair made with the CALG_RSA_KEYX key type. I determined the block size was 512 bits using cryptgetkeyparam KP_BLOCKLEN. It seems the maximum number of bytes I can feed cryptencrypt in 53 (424 bits) for which I get an encrypted length of 64 back. How can I determine how many bytes I can feed into cryptencrypt? If I feed in more than 53 bytes, the call fails.
RSA using the usual PKCS#1 v.1.5 mode can encrypt a message that is at most k-11 bytes, where k is the length of the modulus in bytes. So a 512 bit key can encrypt up to 53 bytes and a 1024 bit key can encrypt up to 117 bytes.
RSA using OAEP can encrypt a message up to k-2*hLen-2, where k is the modulus byte-length and hLen is the length of the output of the underlying hash-function. So using SHA-1, a 512 bit key can encrypt up to 22 bytes and a 1024 bit key can encrypt up to 86 bytes.
You should not normally use a RSA key to encrypt your message directly. Instead you should generate a random symmetric key (f.x. an AES key), encrypt your message with the symmetric key, encrypt the key with the RSA key and transmit both encryptions to the recipient. This is usually called hybrid encryption.
EDIT: Although this response is marked as accepted by the OP, please see Rasmus Faber response instead, as this is a much better response. Posted 24 hours later, Rasmus's response corrects factual errors,in particular a mis-characterization of OAEP as a block cipher; OAEP is in fact a scheme used atop PKCS-1's Encoding Primitive for the purpose of key-encryption. OAEP is more secure and puts an even bigger limit on the maximum message length, this limit is also bound to a hash algorithm and its key length.
Another shortcoming of the following reply is its failure to stress that CALG_RSA_KEYX should be used exclusively for the key exchange, after which transmission of messages of any length can take place with whatever symmetric key encryption algorithm desired. The OP was aware of this, he was merely trying to "play" with the PK, and I did cover that much, albeit deep in the the long remarks thread.
Fore the time being, I'm leaving this response here, for the record, and also as Mike D may want to refer to it, but do remark-me-in, if you think that it would be better to remove it altogether; I don't mind doing so for sake of clarity!
-mjv- Sept 29, 2009
Original reply:
Have you check the error code from GetLastError(), following cryptencrypt()'s false return?
I suspect it might be NTE_BAD_LEN, unless there's be some other issue.
Maybe you can post the code that surrounds your calling criptencryt().
Bingo, upon seeing the CryptEncrypt() call.
You do not seem to be using the RSAES w/ OAEP scheme, since you do not have the CRYPT_OAEP flag on. This OAEP scheme is a block cipher based upon RSAES. This latter encryption algorihtm, however, can only encrypt messages slightly less than its key size (expressed in bytes). This is due to the minimum padding size defined in PKCS#1; such padding helps protect the algorithm from some key attacks, I think the ones based on known cleartext).
Therefore you have three options:
use the CRYPT_OAEP in the Flag parameter to CryptEncrypt()
extend the key size to say 1024 (if you have control over it, beware that longer keys will increase the time to encode/decode...)
Limit yourself to clear-text messages shorter than 54 bytes.
For documentation purposes, I'd like to make note of a few online resources.
- The [RSA Labs][1] web site which is very useful in all things crypto.
- Wikipedia articles on the subject are also quite informative, easier to read
and yet quite factual (I think).
When in doubt, however, do consult a real crypto specialist, not someone like me :-)