# Tag Info

2

This answer has 2 parts, the 1st on "quantifying" the security of unbroken ciphers, the 2nd on the choice of ciphers for different usage scenarios. If (on a scale of 1 to 10) AES is 5 and Serpent is 10, what would ChaCha be? First, you have to quantify their security in order for the scores to be meaningful. The quantification must have a basis, ...

3

Theory aside, there's basically no way to have security on the CAN bus. The Controller Area Network, or CAN bus, is a differential bus that is robust enough for critical communications but simple enough to be used with micro-controllers. CAN bus employs a message-based protocol over four wires, power, ground, CAN-, and CAN+, where the message from a device ...

6

Yes, there is an important one; The Non-Reputation; Non-repudiation refers to a situation where a statement's author cannot successfully dispute its authorship or the validity of an associated contract The HMAC key is a symmetric key therefore there is no non-repudiation. Both sides can not claim that the other side sends them the message $m$. I.e. They ...

0

You have and oracle call of $$O(\texttt{your-string}) = (\operatorname{AES-128-ECB}(\texttt{your-string} || \texttt{unknown-string})$$ Since you know that the AES has 16-byte block cipher and it uses CBC, request; $$C = O(\texttt{AAAAAAAAAAAAAAAx})$$ from oracle, where $\texttt{x}$ is the first byte of the random key. Now ask to oracle these encryptions C ...

10

All AES candidates due to specification were Pseudo-Random Permutation (PRP), however, today we don't need a PRP. We can live with a Pseudo-Random Function (PRF) since the CTR mode is designed for PRFs. CTR modes don't need the reverse operation as CBC. This can reduce the area/time cost of implementations. As an example; the ChaCha is a PRF and turned into ...

15

A serious issues with AES is its sensitivity to timing and cache side-channel attacks in many portable pure-software implementations, due to the hard-to-avoid table lookups (exceptions: bitsliced implementation, CPUs without a data cache, CPUs with AES-NI, some slow code). An ARX cipher (in the sense of using only additions, rotations/shifts, and XOR; e.g ...

34

Nobody seems to need a 192 bit version, we can do fine with just AES-128 and AES-256. Having a key that's 1.5 times the block size is a nuisance (or 0.75 times the block size if the block size is doubled). The key schedules of AES-192 and AES-256 are vulnerable to attack; we could do with a better key schedule where even these attacks are avoided. They don't ...

20

I don't think that saving rounds to increase speed is necessary. On machines with AES-NI (which is most today), it takes less time to encrypt in AES than it does to read from memory. There are rare cases where the time to encrypt is too slow. One change that I think should have been made is to also standardize a larger block size. Although 128 bits seems ...

11

The others had a fixed number of rounds (32 for Serpent, 16 for Twofish, etc.) regardless of the key size. Why was this? Is there some cryptographic attack which is unique to Rijndael which would warrant this? During the second AES conference, the Rijndael team was asked about this design decision. They turned it around, and pointed out that smaller keys ...

4

I'd argue for (3) for these reasons: the algorithms are used within their operating assumptions; related: AES may be insecure if the keys have a specific format; no entropy is lost when performing the conversion to 32 bytes as compared to (1). AES-128 is also considered secure at the moment, but it may not be if quantum computers are created that enable ...

1

You can assign each device its own unique certificate with a signature issued by the CA (for example, could be the manufacturer) on the certificate. So each device stores the following: its own unique certificate (its public key), its corresponding secret key, and the signature on its certificate issued by the CA. During key exchange, 2 devices would send ...

0

Lastly, a 32-byte HMAC value of the ciphertext is created using the HMAC key and SHA-256 and written as the last two blocks of the ciphertext (32 bytes). You really should include the IV in the calculation. Otherwise the authentication tag validates, and with a wrong IV it will still result in invalid plaintext. This is less of an issue with the salt, as a ...

0

If the key is derived from the password there is no reason to store it anywhere. The main problem in your outline is not the cryptography. You are explicitly writing the passwords to disk. This is a really bad idea. The deletion may not happen at all, e.g powe failure. Even if it does on a modern hard drive it is really hard to overwrite data it won't ...

0

That is right, but is it possible that the victim send me his encrypted symmetric key and I will send the decrypted key back? I have not personally written any ransonware, nor have I examined how they operation; however if I were to, that is what I would do - once the victim has paid up, they would send a copy of the encrypted symmetric key, decrypt it, and ...

1

I am assuming you meant to use a=2, so that if it sends an error message, we know that MCB was 1. Anyway RSA in practice is never used in raw form like this precisely because this malleability allows attacks like you just mentioned. Such malleability also allows an attacker to create fake signatures from an oracle and with good padding, we cannot trick any ...

0

I don't think you need RSA either. Where will you store the private key and how will you protect it from being stolen anyway? Use a good and hard to guess password, and a long enough salt and use a good KDF to derive an AES key to encrypt your data, I think it will work better? And 256 bits is huge, it will take many times longer than the age of current ...

0

As @mentallurg answered: use AES-256. Today, any cipher at or above 128-bit security level is very strong and as John Kelsey says: "Thare is no meaningful difference between 192-bit and 256-bit keys in terms of practical bruteforce attacks; impossible is impossible." But, just to bear with you: you can use Threefish-1024. Threefish is a fast and ...

2

Based on your comments I have a feeling that may be you don't really understand what a huge number of combinations a 256-bit key means. At the first glance 256 bit is "just" 16 bytes. But look at it closer. With 256 bits we can encode $2^{256} = 10^{77}$ numbers. It is 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 ...

0

In this case, this answer also should be a comment (I'm sorry!). @Hunter, the NIST SP 800-108 define the use of hmac as PRF. For example, in python, you can use: hash_algo = hashes.SHA512() kdf = KBKDFHMAC(algorithm=hash_algo, mode=Mode.CounterMode, length=32, rlen=4, llen=4, location=CounterLocation.BeforeFixed, label=label, context=context, fixed=None, ...

0

I recommend HKDF - it's a key-based key derivation function (as opposed to password-based). It accepts an already-high entropy input (your AES key), a salt (you could use your "plain text"), and optional info, for contextualizing the key. It would be better to use your main key to derive two separate keys, one for encryption, and one for HMAC... ...

2

In general, we always assume that the mode of operation is known ahead of time. In practice, this should be bound to the key - if the key is only used for a single mode of operation then the above shouldn't happen. However, if the same key is used for multiple modes of operation, then the mode ID should be made part of the ciphertext and therefore included ...

4

Actually, your numbers seem shockingly high at 2724 cycles for one block - even with the key schedule. Crypto++ uses standard AES-NI for the encryption of blocks and for the key generation they use AESKEYGENASSIST for the SBox (unfortunately). Ideally the expected performance would be (for their implementation, not for one with an optimized on-the-fly key ...

2

AES has highly optimized implementations, including additions of special instructions to intel CPUs specifically for AES. but even without it is amazing how much optimization can go into the implementation og an algorithm it's quite an art. I also have doubts in your measurements, the maximum may be only noise from context switches etc. AES can be ...

1

Honestly, it would be more secure, but not by much, and that is assuming you are using finite field inversion s-boxes. A better use of multiple 8-bit s-boxes would be to make them key dependent, however in software that can have the unfortunate side effect of creating another side channel to leak information about the key. If you want something based on the ...

0

Let us decrypt the CBC encrypted ciphertext.(IV and Key each of 16 bytes=128 bits) key = 140b41b22a29beb4061bda66b6747e14 IV = 4ca00ff4c898d61e1edbf1800618fb28 Cipher Text = 28a226d160dad07883d04e008a7897ee2e4b7465d5290d0c0e6c6822236e1daafb94ffe0c5da05d9476be028ad7c1d81 Now if you put them in any CBC decryption function you will get plaintext as Basic ...

1

For the CBC mode the encryption and decryption equations are as follows; CBC encryption; \begin{align} C_1 &= E_k(P_1 \oplus IV)\\ C_i &= E_k(P_i \oplus C_{i-1}),\;\; 1 < i < nb, \end{align} CBC decryption; \begin{align} P_1 =& D_k(C_1) \oplus IV\\ P_i =& D_k(C_i) \oplus C_{i-1},\;\; 1 < i < nb, \end{align} But I'm not 100% ...

Top 50 recent answers are included