Hot answers tagged

10

There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ...


7

In addition to the other answer Using asymmetric cryptography in the meters would have some benefits: it can make passive eavesdropping of meter/server communication useless, even to a party holding or able to use the server's private key; something not achieved with secret-key cryptography. it can ensure that any central key leak can not compromise the ...


7

As SEJPM notes in the comments, the IVs will repeat after $2^{32}$ frames. This is bad (unless the key is changed more often than that). In particular, if you can temporarily capture the device and make it encrypt $2^{32}$ known messages of sufficient length, you will learn the keystreams corresponding to all the $2^{32}$ possible IVs for that device. ...


6

Does it matter WHICH bit I'm flipping? Is it legit to always flip the MSB f.e. or should it be a random position? If you see the cipher design as a black box then certainly yes. It could well be that the design would be more secure for certain positions than the other. This would indicate a (local) weakness. Note that the Hamming distance is just one ...


5

TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy. In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called ...


4

Yes, in case of VeraCrypt there is a difference, but it is negligible in practice. First we need to consider how VeraCrypt actually performs the cascading of the encryption algorithms which is (literally) a block-wise chaining. E.g.: $$C=E_{XTS}^{1}(E_{XTS}^{2}(E_{XTS}^{3}(M)))$$ where each $E$ is a block cipher run in XTS mode and all using the same XTS ...


4

You can (and should) do the reduction in constant time using masking. That is, instead of using the following (non-bitsliced) pseudo-C code to do the reduction: if ((result >> 8) & 1) { /* bit 8 is set: clear it and flip bits 0, 1, 3 and 4 */ result ^= 0x11b; } you can simply do: result ^= 0x11b * ((result >> 8) & 1); ...


3

If the central key database is hacked, does an attacker is able to decrypt the communication of any meter? To tamper it? Indeed, if the central key database is hacked, then an attacker will know all the secret keys and so will be able to decrypt all communications. Why not choosing an asymmetric public key mechanism instead, where the central ...


3

From what I understood, data units are sectors, so a sector can have at most $2^{128}-2$ blocks but you can only encrypt $2^{20}$ blocks which cannot be correct (it seems too little compared to a disk's capacity). The data unit is the sector, yes, but both of those quotes only talk about the length of a single data unit. The larger number in the latter ...


3

I want to make it harder to decrypt AES I send. Fundamentally, the thing you are trying to do is completely unnecessary. If AES does ever become broken, the scenarios in which this makes any measurable difference are exceedingly unlikely. If AES isn't broken, then doing this was wasted effort in the first place. There is zero plausible reason why your ...


3

"Given the above assumptions and limitations, is the encryption scheme still secure?" No; the attacker can remove blocks of [IV + rest_of_ciphertext] from either end to remove corresponding plaintext blocks without affecting any other part of what it decrypts to change the IV to change the initial plaintext block in the same way as for the OTP, without ...


3

This is a type of chosen-plaintext attack, where the adversary gets partial choice of plaintexts — they can cause the same substring to be encrypted multiple times. AES-CTR, if used properly, is resistant to chosen-plaintext attacks. Used properly, for CTR mode, means that the same counter value must not be reused for different messages. For example, if ...


3

If you have a nonrepeating (but possibly predictable) value, you can convert that into an unpredictable CBC-mode IV at fairly minimal cost. Here's how: Prepend the 128 bit nonrepeating value to the message CBC mode encrypt the (value, message), using any IV that's not correlated to the nonrepeating value (all 0's work) Use the first 16 bytes of the ...


3

A slight correction about terminology: The key is constant when you use CTR. The IV/counter affect the cipher input and so the keystream varies. The reason this can be decrypted is that the decrypter knows both the key and the IV/counter. They can calculate exactly the same function as the encrypter did, resulting in the same keystream block, which a XOR ...


3

Just use AES. It's hardware-accelerated and implementations have had ages to have flaws discovered and patched. More strongly, just use GPG to encrypt data at rest and just use TLS (>= 1.2, with appropriate AEAD ciphers) for data in motion. "If you're typing the letters A-E-S into your code, you're doing it wrong." Anything you build yourself is infinitely ...


2

If MixColumns is omitted, the following happens: The cipher essentially becomes a group of 8-bit block ciphers, that work only by subkey addition and s-box transformation. After every 3 rounds, the original bytes will shift back to their original locations, in the following pattern: Original state a b c d e f g h i j l k m n o p After round 1 a g i o f k ...


2

I would not consider your case to be a cascading encryption. The reason why is the fact you need multiple interventions before getting access to your file. Here is what I would consider a cascading encryption (let's go crazy) : $$E(k_1,k_2,k_3,m) = \text{KEYAK}(k_1,\text{NORX}(k_2,\text{AES}(k_3,m)))$$ which you would decipher with : ...


2

If you ask about the protocol itself, as a theoretical construct, then it is safe. In theory it indeed provides all the feature that it promises. And now for the "but..." part. When you use a protocol to communicate, you are actually using one implementation of the protocol. The implementation tries to do exactly what the protocol says. However you can ...


1

The entire premise of modern ciphers is that they're indistinguishable from random by a computationally-bound adversary. If you believe the assertion that a modern cipher is secure, then it follows that you believe you cannot reliably distinguish it from randomness. If you share a secret key with your clients, what you can do is verify a MAC over the ...


1

The main advantage I have heard is reducing the amount of data the client has to send to the cloud. As said in A Comparison of the Homomorphic Encryption Schemes FV and YASHE: [...] ciphertext expansion (i.e. the ciphertext size divided by the plaintext size) of current FHE schemes is prohibitive (thousands to millions). For example using ...


1

Basically there are two ways: decode the counter to be a big number in some kind of library, increase that number, then encode it back as unsigned, statically sized, big endian value, making sure you left pad with zero valued bytes when necessary; increase the value of the right-most byte (highest index) as unsigned number, if the resulting value is zero ...


1

I'm not sure about your definition, so let's take branch number in terms of the byte-wise differential branch number, i.e. the branch number of a function $F(x)$ is $$\mathcal{B}_{F(x)} = \min_{a,b \neq a}\{ w(a \oplus b) + w(F(a) \oplus F(b))\}$$ where $w(x)$ is the number of non-zero bytes in $x$. In this case, the branch number of the Twofish round ...


1

The main complexity of attacks using a quantum computer with Grover's attack is explained here. I'll use the remainder of the answer to indicate some possible misconceptions in your question. It's hard to say exact QC specs, but let's assume we have decent a quantum computer using Grover's algorithm that is able to half AES-128 keyspace to that of ...


1

The speed of a cipher actually depends on lots of factors, including: The specific hardware platform you're considering (CPU architecture, instruction set, number of cores etc). Implementation details. Compiler flags used. Some ciphers have a large initial overhead due e.g. to a slow key setup; as a result they are slow when encoding very small messages. ...


1

Suppose you use 128 characters out of an alphabet (this is a large alphabet). To create a key you'd need about 37 fully random characters to create an AES key of 256 bit strength. Even you would create such a password, you'd have trouble encoding it over the required number of bits. You could either use a 44 character base 64 string or 64 character hex ...



Only top voted, non community-wiki answers of a minimum length are eligible