Hot answers tagged

12

This is due to the Brassard et al.'s method on hash functions. That has $\mathcal{O}(\sqrt[3]{n})$ attack time for n-bit hash function where as the Grover's method has $\mathcal{O}(\sqrt{n})$-time. Level I: At least as hard to break as AES-128 $\mathcal{O}(\sqrt{2^{128}}) = \mathcal{O}(2^{64})$ - by Grover Level II: At least as hard to break as SHA-256 $\...


5

No, there is no big shortcut possible in practice, as far as we know. One would be a major blow of AES. A small speedup is pre-computing the subkeys, which saves a small constant factor (like 2) compared to doing that computation on the fly at each iteration. Also, the first and last subkeys can be grouped into one by XOR, saving one 128-bit XOR at each ...


5

Since AES under any fixed key is a permutation, we necessarily have $j = 0$ and $i = l$—iterating a permutation enough times will always return you to the starting point. From Harris 1960 (paywall-free), if we model AES as a uniform random permutation, every period length $l$ has equal probability $1/n$ (Eq. 5.2) for any particular starting point, where $n =...


3

If you are using AES-CBC, You can store the IV however you like. It is not important to keep the IV secret; you just need to make sure that an adversary cannot predict the IV in advance. However, you have the right intuition that you should generally always use an authenticated cipher like AES-GCM. AES-CBC is bad for other reasons too having to do with ...


3

In most cases, you should probably use AES, especially if there is hardware support. In some cases, it might make sense to use one of the others. For example, the simplicity of Threefish would make sense for an embedded controller using a micro lacking hardware support for AES. Its lack of S-Boxes reduces the amount of ROM needed. If you don't need the ...


2

The safe academic thing is to assume that no, something using the Web Cryptoraphy API can not be assumed resistant to side-channel attacks. The Web Cryptography API is, as the acronym states, an Application Programming Interface. What it does is platform-dependent. For example, in a browser environment, the code that implements that API is browser-dependent ...


2

One reason is to mitigate from the Rainbow tables which is the work of Oechslin. If everybody uses the same salt, one can build a Rainbow table for cracking everybody's passwords. There are even commercial tables for sale (I'm not advertising them just providing the existence). Using the salt for key derivation and passwords simply kills the usage of ...


2

Yes. HOWEVER.... An implementation may put the content of the encrypted message wherever it wants, and format the encrypted message any way it wants, including different text encodings such as Base64 You will need to take that into account, when decrypting the message, the input must be formatted in the way that an implementation is expecting, and that ...


1

Generally we first encode the text to binary and then do the encryption. Then we can decrypt and decode to text again. If that suits your need then you can use any secure cipher. The conversion of a textual message to binary is called character encoding. UTF-8 is probably the most used encoding as it supports all Unicode characters & code points, keeps ...


1

For a well-designed block cipher like AES, its output should be indistinguishable from random noise except to someone who knows the key, so this is not possible in the general case. The larger problem here, however, seems to be that you are trying to use the magic tests to verify file integrity without having any other protections. Confidentiality (as ...


1

Everything is defined in the RFC that specifies the protocol. For example, if you're using TLS 1.2, then see section 5 of RFC: PRF is defined using P_<hash>, where hash depends on the suite negotiated in the handshake; P_<hash> in turn is defined using HMAC.


1

ChaCha20 Provides 128 or 256-bit key space. The best attack against 6 (128-bit) or 7 (256-bit) of 20 rounds Stream cipher requires 64-bit nonce and 64-bit position counter Used in TLS 1.3, OpenSSH, as well as BSD and Linux kernel RNGs Part of ESTREAM portfolio Serpent Provides 128, 192, or 256 bit key space. Best attack against 11 or 12 of 32 rounds Block ...


1

Just filling some details of the previous answer Am I therefore supposed to include the salt in the encrypted message? For example send something like: "message = message, salt=salt"? Yes. The salt is often sent as part of the ciphertext (e.g. for OpenSSL the salt is first 8 bytes of the ciphertext for password-based ecryption). In theory you may pass ...


1

The security bound for this construction is (PDF, section 4.7.3 in v4) $$\mathbf{Adv}^{\text{sPRP}}_{\text{AESX-192}}(\mathcal A)\leq \frac{2Q_sQ_{AES}}{2^{192}\cdot 2^{128}}$$ to be a strong PRP assuming AES can be modeled as an ideal cipher (not perfectly accurate but probably "close enough" here), where $Q_s$ is the number of "online" queries against a ...


1

Using T-Tables in software renders your AES open to sidechannel attacks. If you're doing AES in SW, compute it directly with shifts and xors. Don't use tables. Do use SBOX masking. The Boyar-Peralta SBOX construction is a very good option. https://rd.springer.com/article/10.1007/s00145-012-9124-7 Here is a python implementation that shows the logical ...


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