# Tag Info

14

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

13

Decrypt the ciphertext with every possible key and store the result: $2^{56}$ decryptions. Now encrypt the (known) plaintext of the ciphertext with every possible key: $2^{56}$ encryptions. Now you have to check every entry, which is in both lists and try it with another plaintext-ciphertext pair. If you can successfully decrypt that, you are very likely to ...

8

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

8

Review of the paper The paper's goal is to offload to a server the computation of the inverse of a (non-singular) $n\times n$ matrix $X$ of (the floating-point approximation of) real numbers, while keeping $X$ and $X^{-1}$ confidential. Towards that goal, the paper's method is to draw a secret key consisting of two random permutations and $2n$ non-zero ...

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

5

Here are some hints on how it's done on Mega: The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call). To bring it down to the crucial bits: The KDF applies $2^{16}$ rounds of AES-128 with it. The details can be found in the function prepare_key() of 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

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 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 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 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 Assuming for the moment that your claim is correct, I would suggest caution in revealing the details of your findings. After having your results validated by one or two people with the skills to do so (and whom you trust to keep things confidential), then some sort of general announcement (without specifics) would be best, to give people time (say three ... 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 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 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 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 do that. Start by generating a random key and encrypting the data under that key. Now, you in turn encrypt that key with your password-derived key. The twist is that you include the already encrypted file in your PBKDF. So you generate a random key$k$and then encapsulate it as$\mathcal{E}_{k'}(k)$, where$k' = H(PBKDF(\text{password}) \| ...

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

3

I don't believe he is answering the right question. You essentially asked "why are public keys so much larger than symmetric keys", and after his first sentence (which started to address the question, but was a bit vague), he tried to answer the distinct question "why are public key operations so much slower" (not that he got the details of that correct; ...

3

When seeing clearly through all the cube "magic", one recognizes the following: All the cube operations are just key-dependent bit permutations. Therefore, the whole cipher is a sequence of key-dependent permutations and XORs with key bits. This admits an algebraic description: For all keys, there is a permutation matrix $A\in\mathbb F_2^{512\times512}$ and ...

3

Under your scheme, the keystream generated by the stream cipher will be the same for each message enciphered with the same key. While your scheme does not encrypt identical blocks of plaintext in the same message to the same value, it does encrypt identical blocks of plaintext in different messages to the same value, meaning that XORing two ciphertexts ...

3

CAST5 seems to be a solid 64-bit block cipher with 128-bit key. As far as I can tell after a short literature search, it's definition is sound and unbroken, despite nearly two decades of exposure (more for the round function). CAST5 is also known as CAST-128, defined in RFC 2144 (1997), and endorsed by ISO/IEC 18033-3:2010 (current). It is a 16-round ...

3

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a vigenere cipher instead. You can determine this is insecure with a simple algebraic combination: \$ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...

2

First off, your definition is not IND-CPA: In the IND-CPA setting, the adversary has access to an encryption oracle. As you have already determined, no deterministic encryption scheme can be IND-CPA secure. I don't think IND-CPA is widely used for symmetric encryption though (although I might be wrong), semantic security might be a better option. For public ...

2

HMAC: The hmac version is considered slightly more secure than sha-256, assuming it's also based on SHA-256, because the HMAC formulation folds in the key material with 2 rounds of hashing, making it harder to use a chosen plaintext attack on the digest. SHA-256: SHA-256 should be relatively secure against chosen plaintext attacks, but it's better to be ...

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