# Tag Info

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

11

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

6

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

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

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

5

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, … , X, Y, or Z. ($26$ possible letters.) For B you can use A, B, C, … , X, Y, or Z, but not the ...

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 It can be safe, but using the same key in both directions adds several things you need to be careful about: One thing you need to make sure is not a problem is if an attacker takes a message from Alice to Bob, and sends it back to Alice as if it were from Bob. Since Bob to Alice communications use the same key, Alice might decrypt the message, and act as ... 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 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 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 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 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 ... 3 Is appending the hash of the plaintext to the end of an encrypted message sufficient to ensure integrity? Not in the sense of authentication. Such a construction is malleable for many reasonable encryption algorithms. It also leaks the plaintext to anyone who can guess it, since they can calculate$h(P_i)$for guesses (brute force or dictionary attack) ... 3 No, they are not conceptually related. A keystream is the output of a stream cipher and is of (effectively, for modern ciphers) infinite length. If you need to encrypt more plaintext, you use the cipher to produce more bytes of keystream. On the other hand, password salts are of fixed size and their purpose is to make every password effectively unique. A ... 3 It depends on what you think of as an alternative. If you think of the scheme where you do not use$M$as a modulus, but the keys a picked as: $$k \leftarrow \{1, \ldots, M-1\}$$ Encryption: $$C = d + k$$ Decryption: $$d = C - k$$ Then the scheme is insecure. One way to see this is to note that we have$C \geq d$. So the ciphertext communicates the ... 3 There are two major problems with this method. The first problem is that Susan is likely to be able to recover significant amount of data from a series of such blocks. For example, if Susan knows$subkey_1$, then she could recover the value$subblock_1 \oplus subblock_2 \oplus subkey_2\$; if a single block is encrypted with this key, she can't deduce ...

3

You can call C from Java. You can call C libraries from just about anything. Java isn't suitable for some cryptographic applications because you can't guard against garbage collector attacks, not because it's slow. It's not particularly slow. C does have a byte type, it's called "char". Object Pascal (Delphi) isn't a systems programming language, and so ...

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