# Tag Info

0

I'm going to assume you are using binary Goppa codes. That means, that you take a support $\mathbf{L} \in \mathbb{F}_{2^m}$, a Goppa polynomial $\Gamma$ of degree t with coefficients in $\mathbb{F}_{2^m}$ and build all codewords of a GRS code, and then intersect these with $\mathbb{F}_2^n$, resulting in a code that is actually a subset of $\mathbb{F}_2^n$ ...

1

Wrapping my (now deleted) comments into an answer… OMAC, as described in the OMAC spec and its addendum, is what Rogaway et al provide security proofs for in their EAX paper. If you take a quick look at RFC 4493, you’ll notice that it states: The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message ...

1

I read about the AEZ encryption scheme as presented at the CAESAR competition. To me it seems like a construction of an arbitrary length block cipher from a smaller one. The construction is only used in the v1.x of AEZ, because it requires appriximately 1.8 AES calls per block of plaintext, while the one used in v2.0 requires only 1 AES per block ...

1

All of them can be used to deal with unreliable, unordered datagrams; as long as you can derive an IV for the UDP packet then a cipher mode of operation should succeed. You need some kind of unique method of identifying the packet of course. Note that (the information used to generate the) IV may be public. Usually you need some way of identifying the ...

4

You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset. Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ...

3

The Secure Hash Standard and corresponding FIPS-180/202 do not specify any hash to meet a security requirement above 256-bits (using a 512-bit hash). This is unlikely to change. SHA-2 was built with state and word sizes to meet the security requirements on commodity computers (x86 and Alpha), which use 32 and 64-bit maximum CPU word sizes for general ...

8

No, because even SHA-512 was considered overkill from a security perspective. It has 256-bit collision resistance, which is unbreakable. (The link is about keys but a similar argument applies.) If you think large quantum computers will be efficient, a 512-bit hash makes some sense, but even then a 1024-bit one wouldn't. A quantum computer requires ...

6

There is no uniform permutation; there is a permutation uniformly chosen from the set of all possible permutations over $Z_2^{128}$. It is evident that AES is not a uniformly chosen permutation, since its permutation is fixed for any key. One can consider a family $\{AES_K\}$ of AES permutations under all possible keys $K$. Even if the key is chosen ...

3

The catch how ever is that if a small part of the file is given along with the location of that bytes from the beginning of the file we should be able to decrypt just that piece. Normal CTR mode encryption allows one to decrypt any block of the file independent of the rest, so no need to invent your own mode. With AES the block size is always 128 bits, ...

0

For the problem as stated, a stream cipher may not work. Stream ciphers need to either have a unique IV (increasing file size) or a single-use key. Otherwise they leak the XOR of any two files encrypted with the same key and IV. So, unless there's a side-channel that can be used for unique IVs (like file names that are known unique), AES in CTR or OFB mode ...

1

It depends on what properties the compression function has, which in turn depends on how the hash function was constructed. In hash functions based on the Merkle–Damgård construction, the compression function is required to be collision, preimage and second preimage resistant, just like the hash function itself. The only difference is input length: the ...

2

Small addition: You do not lose integrity when using encrypt-then-MAC. Since encryption is an injection, distinct plaintexts produce distinct ciphertexts, so plaintext forgery implies ciphertext forgery, which is hard if encrypt-then-MAC is secure.

0

In a Merkle Tree, data is eventually and inevitably lost, because it is compressed away. If a Merkle Tree used a non-padded compression function, the size of the resulting hashes would go down level by level, resulting in a top hash that is very short. The shorter that top hash is, the less it CAN say about the contents of its tree. The longer the resulting ...

6

Using a MAC on the plaintext may potentially leak information about the plaintext (MAC algorithms do not necessarily ensure confidentiality of the data they are applied to, although some MAC algorithms like HMAC seem pretty safe). If you want to avoid this (theoretical) problem, then you should encrypt the MAC on the plaintext (i.e. MAC-then-encrypt, not ...

3

A key derivation function lets you derive keys from others. In this case I would use HKDF, which means using HMAC in a predefined way. Your key material is the keys $X$ and $Y$, so you can concatenate those to get the PRK for HKDF-Expand. An output key would then be $\operatorname{HMAC}(X||Y, \text{info} || \text{0x01})$, if the size of the HMAC is long ...

1

HMAC is considered the most secure way of combining two keys, as compared to a single round of SHA256. hmac is designed to fold in the key material in 2 hash operations, which helps resist chosen plaintext attacks on sha-256, although SHA256 has no known chosen plaintext attacks at this time. Symmetric ciphers are considered less reliable than hashes for ...

Top 50 recent answers are included