# Tag Info

16

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

7

I've checked out the source code (well, more or less, it's not that well designed, the main crypto class is 1600 lines) and as Richie guessed, the algorithm is stored together with the ciphertext. Pretty gruesome stuff, but it does do EAX mode for text strings to my surprise. It probably only uses it for text strings originating from the password vault code ...

6

SIV is a mode specially designed for this purpose. SIV-AES would be a good choice, but it has the same issues as AES-wrap; not many implementations. If you use a GCM you should make sure that the IV is unique (if your plaintext is ever not random you would otherwise be in problems). As for the password based key derivation function: yes, PBKDF2 is good, ...

5

Yes, in any algorithm where keys are just random numbers, reading them from /dev/random is safe. However, /dev/random blocks if the kernel's entropy estimate goes to zero so it is often a good idea to use a user space CSPRNG seeded from /dev/random or /dev/urandom for session keys and other similar random numbers that are used in bulk. The newer getrandom ...

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

There is a simpler way: implement a stream cipher using the hash function, and use that to encrypt the plaintext. Probably the most used stream mode is counter (CTR) mode, which is normally defined for block ciphers. CTR mode works equally well with a PRF (MAC) as with a PRP (block cipher). It only uses the function as a one-way function; with a block ...

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

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

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

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

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

Symmetric keys don't need to be in any particular format -- they're just a sequence of (pseudo)random bits. Most programming environments provide some sort of "secure random" mechanism (a CSPRNG). You can use this to acquire a byte array of the appropriate length (e.g. 32 bytes for AES256), which can be used as a key. Be sure to pass in the raw bytes, and ...

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 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 advantage of asymmetric encryption is not security, it is capability. Asymmetric crypto provides completely different capability that you can't get with symmetric crypto. With symmetric encryption, you have to establish a key a priori. With asymmetric crypto, you can establish a key on the fly (granted you have to have trust in the public key, that it ...

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

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

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

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

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

2

Salsa/ChaCha and the other eSTREAM winners are likely to be the "fastest but still secure" options today. Don't forget authentication of course. Reduced-round ChaCha/Poly1305 is likely to be the fastest software-only option, due to tuned implementations in the libsodium and NaCl libraries. UPDATED: The following slide deck has good info on state of the art ...

2

Key generation and key scheduling are different things. The key scheduling is part of the cipher, the key generation generally isn't. Symmetric keys should be indistinguishable from random, so often they are the product of a secure random number generator. There are other ways as well, such as derivation from a password using a Password Based Key Derivation ...

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