New answers tagged

1

I am answering on the basis of this paper (pdf) linked in the comments, as well as some of the related papers it cites or is cited by. I am not aware of more realistic attacks on HMAC. It assumes a DPA side channel that leaks the number of bits flipped when a new value is read into a CPU register (or in another instruction in some of the papers). I.e. it ...


3

This answer is based on IntelĀ® Advanced Encryption Standard (AES) New Instructions Set whitepaper (Revision 3.01, September 2012) by Shay Gueron. No, the keys are not identical (within order) for encryption and decryption. The first and last key used in decryption are indeed the last and first one used in encryption; but the other decryption keys are the ...


2

A similar question as been asked before: Use cases for CMAC vs. HMAC? To resume it, AES-CMAC is a MAC function. It can be seen as a special case of One-Key CBC MAC1 (OMAC1) which also a MAC function that relies on a block cipher (so AES in the present case). HMAC is also a MAC function but which relies on a hash function (SHA256 for HMAC-SHA256 for ...


4

What you are looking for is a definition of PEM, privacy enhanced mail. Obviously PEM is not just used for mail anymore. The definition of the header lines seems to be best described by section 4.6: "Summary of Encapsulated Header Fields" of RFC 1421: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication ...


1

Well, as SEJPM and Mok-Kong Shen pointed out, it's described in FIPS 197, but let's explain it in details: Here's the Key Expansion algorithm pseudo-code from FIPS 197: Where $Nk$ is the number of $32$-bit words that composed the key $Nr$ is the number of rounds $Nb$ is the number of columns in the state block (which is always $4$). $word$ is a ...


0

First you need to think about what range of numbers you want to encrypt. You need to create a scheme that is secure for at least the numbers within this range. Make sure you don't encrypt any other numbers. Then you need to specify an encoding of the number to binary. It's probably easiest to make sure you encode to octets instead of bits. Handling odd bits ...


1

Basically you would be constructing an AEAD scheme. You will need to perform HMAC over the IV, the ciphertext and possibly over additional associated data (AAD). If you just need to authenticate the ciphertext then you may simply leave out (or leave empty) the AAD - but not the IV during the HMAC function. Fortunately somebody already thought about ...


4

The only limitation that you really have to consider is that of nonce collisions. With 128-bit random nonces, you would expect collisions after about $2^{64}$ nonces due to the birthday bound. Even if you stored all 30 fields of all 50 million rows thousands of times (you need a new nonce if a field is rewritten), you would still have a chance smaller than ...


5

AES is a block cipher and would return wrong data when a wrong key is used. It only works on a single block of data (16 bytes). The default CBC mode of operation enables you to encrypt multiple blocks of data. The padding then enables you to encrypt plaintexts of arbitrary length. The padding has to be removed somehow after the decryption. You're seeing a ...


3

Strictly speaking, we can't know for sure that the output of AES is indistinguishable from random noise. It's conjectured to be true but no "proof" of that fact exists. For most commonly-used ciphers, it is conjectured that their output is indistinguishable from random. Specifically, modern ciphers are conjectured to be "strong pseudorandom permutations", ...


1

What you're describing is a ciphertext-only attack on AES. No, there's no (known) ciphertext-only attack on AES. Condition one: We know none of the weaknesses and similar plain-texts in these two blocks, I just mentioned, how easily could we discover it? By the lack of an transmitted IV, an attacker can learn whether the two messages are equal and ...


0

For my answer, I'll assume that you have symmetric keys pre-shared between your heater and your sensors. If your devices have enough computational power to support asymmetric cryptography (which will increase workload by a large factor and message length by at least 32 bytes) the answer will be different (and provide stronger guarantees). AES-128 CCM is a ...


7

The Simplified AES uses the Galois field GF(16), which can be represented by polynomials over the F_2 field: hex ... bin ... polynomial 1 ... 0001 ... 1 2 ... 0010 ... x 3 ... 0011 ... x + 1 4 ... 0100 ... x^2 ... ... n ... abcd ... ax^3 + bx^2 + cx + d ... ... F ... 1111 ... x^3 + x^2 + x + 1 with multiplication defined as ...


1

well it probably varies on how you want to access the key, one of the most extreme version could be an HSM which should keep it really safe but is also rather expensive. another way would be encrypting it with a key that just you know with plain AES and storing the base64 somewhere for example, that's what I do for some of them if you want to require ...


3

Yes, the principle to use a common password and a unique salt per file with a key derivation function is a good and acceptable practice, as you generate the salt randomly and with the right size. The uniqueness of the salt guarantees a different password per file (actually one password per salt, so: do not reuse a salt, use a csprng). You forgot to mention ...


0

T-table is an optimization for AES on 32-bit platforms introcuded by the designer of AES and explained in their book: J. Daemen and V. Rijmen, The Design of Rijndael, Berlin, 2002, p.56-59. A similar further optimization is feasible which is done in my AES C-code of 2003 (http://www.mokkong-shen.privat.t-online.de/).


1

It is per message. I.e. per (key, nonce) -pair. The reason it exists is that GCM uses CTR mode for encryption with (normally) a 32-bit counter. That means you can only encrypt $2^{32}$ blocks, i.e. $2^{39}$ bits with AES. The 256 bits that are subtracted are due to authentication. So you can encrypt multiple maximum-length messages securely.


1

In Password-Based Encryption (PBE) we use a randomly generated (and hopefully unique) salt to prevent dictionary attacks on the key generated from a password. Every "user" in a system should at least have a different salt. Since key derivations can be made arbitrarily hard just by increasing the iteration count, we can have, let's say, a key derivation ...


8

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...


1

I do not agree with the other answers and comments given here. The use of the 96-bit nonce gives the best bounds, but it is certainly not the only way to use GCM. Also, the degradation is gradual. It is not the case that anything else is insecure. Having said this, it is completely insecure to encrypt beyond $2^{32}$ blocks using a 96-bit counter since the ...


5

The source of the limitation lies in the fact that GCM has a fixed block counter using a 32-bit integer. Since the block size is $2^7$ bits, the total amount that can be encrypted with the CTR component is $2^{39}$ bits. The first limit reducing this by 128-bits is the fact that the block counter starts at 1 and not 0, at least with a 96-bit nonce. Nonce ...


0

IV in the CBC mod applied to Sensitize the plaintext to initial value. So it isn't necessary that "IV" be secret. On the other hand, when we apply "IV" in CBC mod we can prevent from iteration attack and prevent from collision.


1

OK! This won't be the best answer I can give, but since I know a fair bit about this subject, CSPRNGs (Cryptographically Secure Pseudo-Random Number Generators), also known as Dertemistic Random Bit Generators (DRBGs). Now your question asked about CBC, so I'll come onto that second, first I want to give a slightly less technical/broad answer, I'll give you ...


5

A Padding Oracle attack due to my use of CBC Cipher Mode CBC in and of itself does not directly result in a padding oracle. It is when you abuse the padding after decryption to decide whether or not decryption was successful and then communicate (maybe not even directly) the results of that padding check. Based on your comment that The connection ...


1

In the Rijndael proposal document a clear explanation of the possible implementations is given. It was later completed by D. J. Bernstein (https://cr.yp.to/aes-speed.html) with further optimizations. However as said before, be careful of the possible side channel attacks which may applied to your implementation.



Top 50 recent answers are included