# Tag Info

14

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

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

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

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 ... 4 Would this help preventing brute force attacks? It would slow down an attacker and prevent them from trying as many password guesses. E.g. if you used 1000 rounds like in RFC 2898, you would reduce the number of guesses by a factor of 1000. Assuming you count dictionary attacks under brute force attacks, such attacks would definitely not be completely ... 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 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 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 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 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

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

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

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

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 Vigenère 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 The answer to the first question is both. TLS uses a custom PRF based on HMAC to generate symmetric and MAC keys from a shared secret. The shared secret is created during the asymmetric key exchange between client and server as part of the handshake. The PRF generates key material of a required length. That length is determined by the key sizes and the key ... 2 Rijndael-128, Rijndael-192 and Rijndael-256 are actually 3 different variants of block cipher that are very similar. Simon, Speck, Threefish and RC5 also define different block size variants in similar way. Rijndael is not unique in this regard. Block cipher that really has variable block length is XXTEA as its block length is not limited. 2 The condition is that: $$g(0, x_2, x_3, ..., x_n) \ne g(1, x_2, x_3, ..., x_n)$$ for all$x_2, x_3, ..., x_n$This can easily be derived from the condition that implies bijectivity of$f$; that is,$f(x_1, x_2, ..., x_n) = f(y_1, y_2, ..., y_n)$implies that$x_1 = y_1$,$x_2 = y_2$, ...,$x_n = y_n$2 No, it won't "leak" information, as long as you're using a modern symmetric algorithm that's resistant to known-plaintext attacks. However, depending on the encryption mode used (and whether there's integrity checking or not), there can be other security implications, such as the data in the known spot being substituted. 2 Java isn't as fast as C for cryptographic operations, it is a factor of 2 to 10 times slower, depending on the algorithm - according to my 15 year experience. With the current processors that's often a smaller issue than you may think, you can still get very respectable speeds with Java (much higher than with non-native scripting code for instance). That ... 2 Your scheme is indeed an instance of output feedback mode (OFB), using $$(\mathit{key},\mathit{pad}) \mapsto H(\mathit{key}\oplus\mathit{pad})\text,$$ where$\mathit{key}$corresponds to keyhash and$\mathit{pad}\$ to hash, as the "block cipher". (It is very likely not really a block cipher due to lack of bijectivity, but that's not needed for output feedback ...

2

Asymmetric keys have to be much larger than symmetric keys because 1) there are less asymmetric keys for a given number of bits (key space), and 2) there are patterns within the asymmetric keys themselves. To compare, consider that the ECRYPT II recommendations on key length suggest a 128-bit symmetric key is as strong as a 3,248-bit asymmetric key, and ...

2

As usual, inserting a backdoor in a symmetric cipher becomes a lot easier if you have knowledge your adversaries lack. DES is a pretty good (counter)example of how a backdoor could be introduced in a symmetric cipher. Back in 1974, IBM and the NSA both knew about differential cryptanalysis, but they did not publish their findings. Some 16 years later, ...

2

If you are looking for something that is faster than AES, there are several options. HOWEVER (and this is a big one) if AES-NI instructions (hardware acceleration) are available to you, there is nothing that can come close. My computer is a few years old, and I get 3100MiB/s in CTR mode. That is 3 gigabytes every second. That is faster than the network ...

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