Tag Info

Hot answers tagged

13

Most hashes are built from permutations (either keyed permutations/block-ciphers, as in MD5, SHA-1 and SHA-2, or unkeyed permutations as in Keccak/SHA-3 and CubeHash). A permutation is a shuffling of the inputs. Once you have a good random permutation, you can easily build a hash from it. See Construction of One-way compression functions from block ciphers ...


10

In complete honesty: if you have to ask this question, it's overwhelmingly unlikely that you have actually succeeded in breaking the security of AES. At best, you may have discovered a well-known attack against misuse of particular block cipher modes; for instance, plaintext recovery with a chosen-ciphertext attack against ECB, or blind manipulation of the ...


6

In hash functions (and similarly block ciphers) each round applies a non-linear function to its input. This function is somewhat difficult to calculate backwards (and it needs a few other properties, but let's leave it at that). This concept is called diffusion. On the other side, one of the goals of cryptanalysis is to reverse this diffusion in order to ...


5

We need clear goals. The question asks for "plausible deniability" or "deniable encryption", and these terms needs a precise definition in a public-key context (implied by RSA). I assume that in addition to the IND-CPA and IND-CCA1 properties of a cipher, including hybrid (as implied by AES), it is desired that: One without the private key can't ...


5

Given: The attacker can call PRP() and the inverse function prp() on any message of his choosing. PRP is a pseudorandom permutation indistinguishable to the attacker from a random permutation. Assuming R and K are "sufficiently large", perfectly random, and never leaked to the attacker -- in particular, during a chosen-ciphertext attack, the decryptor only ...


5

Symmetric encryption is no longer necessary, because all security services can be implemented with public-key cryptography. No. The speed of asymmetric encryption is prohibitive when it comes to encrypting more than a few hundred bits of data. This is why most protocols that implement encryption with asymmetric cryptography are hybrid, using asymmetric ...


5

Quite apart from the correction that Reid made (it takes $2^{127}$ attempts to achieve a probability of 50% of finding the right key; with $2^{64}$ attempts, the probability of success is $2^{-64}$), with AES, there is no known way to take advantage of known (or even chosen) plaintext to speed up any brute force search; even with $2^{64}$ chosen ...


5

Yes, we need symmetric cryptosystems, for many reasons; to give three of these: We need a hash function to make most asymmetric cryptosystems secure (e.g. we simply do not have a secure signature system based on RSA without a hash), and current hash functions are (or are built from) symmetric cryptosystems. All asymmetric encryption cryptosystems are bound ...


5

Assuming you really had broken AES or another frequently used algorithm that is thought to be secure, the first step would be to prove it. Write the code for the attack. Verify that it works on randomly generated data of the kind it requires. If it can break some challenge (e.g. these), do it. Post the results to the challenger or show the results ...


5

Is this (cryptographically) secure? That is hard to say without knowing the exact details of the bitcoin protocol (which I would like to understand better, but don't have the time at the moment). Looking at the document you linked to, the public child key is created as $\text{HMAC-SHA512}(Key = c_{par}, Data = ser_P(K_{par}) || ser_{32}(i))$. This ...


4

You can get what you want programmatically. No special ciphers or modes needed. You say there is a single, continuous subset that needs to be encrypted. Thus, you could have a function where the programmer specifies the start of the portion of the plaintext that needs to be encrypted and the number of bytes to encrypt. The function could pull that part out, ...


4

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 ...


4

Ciphers with Arbitrary Finite Domains by Black and Rogaway have some options like Prefix Ciphers, Generalized Feistel networks , Cycle walking etc. Also Format preserving encryption has traits that you are looking for , but NIST standardized ones are patented by Voltage Inc. In general Feistel networks + Cycle walking would give a good option for any ...


4

Yes, absolutely. Here is the standard construction to address this problem. Let $pk_1,\dots,pk_n$ be the public keys of the $n$ recipients. We pick a random symmetric key $k$, encrypt the message $m$ (using authenticated encryption) under key $k$ to get $c=AE_k(m)$, and then encrypt $k$ under each of the public keys. Finally, we form the whole ciphertext ...


4

The idea you have is: lets say we have a known plaintext/ciphertext pair; can we use a precomputed table to speed up the recovery of the key? Well, the main problem with that precomputed tables don't actually speed up the search time, if you count the time taken to generate the precomputed table. What the table precomputation does is (for example) generate ...


4

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...


4

Based on the additional details in the comments, it seems like your question is: given $c_1=a\oplus d$ and $c_2=b\oplus d$, can we get $(a+b)\oplus d$. Where $a,b,d\in\mathbb{Z}_p$, $+$ is addition modulo $p$, and $\oplus$ is a bitwise XOR of the values, then taken modulo $p$. Or put another way, is there an operation $\boxplus$, such that $(a\oplus ...


4

Your teacher is right, and here's why: What happens if you encrypt A with G and B with G? You can't decipher it, because you have no idea if the G in the ciphertext was an A or a B. So for the plaintext letter A you can use the ciphertext letter A, B, C, D, ..., Y or Z. (26 possible letters.) For B you can use A, B, C, D, ..., Y or Z, but not the letter ...


3

To answer your questions in order: You won't find test vectors for the s-boxes in the submission - the s-box functions are implementation specific optimisations, especially the bit-sliced s-box functions like the Osvik and Gladman/Simpson, which actually compute multiple s-box lookups in parallel. If you need to test your s-box implementations, I would ...


3

The scheme is secure against chosen-plaintext attacks up to $2^{|R|/2}$ queries. Indeed, given this number of queries, it is likely that every encryption call yields a new value $R$, which has never used as part of the permutation input. However, when this bound is reached, some problems occur. Suppose you encrypt the same message $M$ as many as ...


3

I've thought quite a lot about this, and I think in general the answer is no, it would not be a good idea to use a KCV for those kind of situations. Using a hash or even better a MAC (using the key as MAC Key) would be a much better idea if a KCV is required. Instead of zero's, it would be much better to use a block of bytes that is not likely to be of use ...


3

Notice that $N_b$ has not been seen until step 4, so it is generated by B. In step 5, A sends $N_b-1$ back to B. This proves to B that A knows $K_{ab}$ otherwise A could not have recovered $N_b$. This is done to prevent A from replaying the message in step 3 and therefore authenticating. For example, suppose Eve sees Alice send the message in step 3 ...


3

GMAC is quite simply GCM mode where all data is supplied as AAD (or additional authenticated data), or as NIST SP 800-38D puts it: If the GCM input is restricted to data that is not to be encrypted, the resulting specialization of GCM, called GMAC, is simply an authentication mode on the input data. If you don't have access to a cryptographic provider ...


3

No, for the same reason that you can't crack 1.3 million ciphertexts knowing they use the same key but different plaintext. As long as the CSPRNG you use to get your IVs is strong, you're safe. You are correct in that decrypting the first block without the right IV is not possible. If it were, we wouldn't be using CBC. But yeah, if he could somehow guess ...


3

Symmetric encryption is no longer necessary, because all security services can be implemented with public-key cryptography. I suppose that is true enough at a high level; if all you had was public key cryptography, you could do symmetric cryptography (if necessary, giving both sides copies of the private and the public keys); this would meet the ...


3

The CPU efficiency difference has been mentioned. Symmetric encryption is also usually more efficient in key length. If you have n-bit key, the attacker needs about (1/2)*2^n tries in average in the ideal key length efficiency. With AES (symmetric), you can get pretty close to this efficiency. On the other hand, with ECC (assymetric), you need to about ...


3

Yes, you can pad the message with zero's or random values. As long as you can retrieve the location of the message inside the padded plaintext then you can hide the exact message length. Note that statistical methods can still be applied; you will have to always create a message size of $N$ if you want to full hide the length of messages of $0$ to $N$ in ...


3

Assuming perfect implementations and good block ciphers, it doesn't matter (for any of your questions). As long as the underlying block cipher is good and has a long enough block length (e.g., 128 bits, as all versions of AES have), any good mode of operation has a security theorem guaranteeing security against chosen plaintext attack for a total of about ...


3

With symmetric encryption, any key exchange protocol you run inside the encrypted channel must also be secure when run in plain text, if you want perfect forward secrecy. That means you can only rely on the previously established keys for authentication (you are using authenticated encryption, right?), but not for hiding the new keys. Diffie–Hellman key ...


3

As one of the authors of the paper, let me give you an answer. The operation $F$ is indeed applied to both $x$ and $x'$. By stating that $\oplus$ is invariant under rotation, we mean that if you first rotate $x$ and $x'$ and take the difference with $\oplus$, you get the same result as if you first take the difference with $\oplus$ and then rotate the ...



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