Tag Info

9

Such a block cipher would be completely unusable in any of the standard modes of operation, presuming you want at least IND-CPA security. Say, for instance, that you are using it in CTR mode. A chosen plain text adversary looking at a cipher text consisting of only two blocks (i.e. 2 times 32 bits), would have a non-negligible probability (higher than ...

9

In summary: the premise "there is so little space in the bootloader that no cryptographically secure decryption algorithm can be implemented there" is likely wrong; thus security-by-obscurity is not the way to go. The method described in the question attempts to "prevent theft from the publicly released update"; but it fails to do that if an adversary ...

8

No, it's not safe to seed a PRNG with the hash of a password, then generate a key from that PRNG. That is especially bad with DSA and shared parameters $(p,q,g)$, and only slightly less unsafe for RSA, or DSA with per-key parameters $(p,q,g)$. Two essentials things are missing: some slow step, and salt. If the proposed procedure was applied, all there is to ...

7

Instead of using a hash function, use a pseudo-random function (PRF). Unlike hash functions, which are publicly computable, PRFs use a secret key. HMAC-SHA256 is a widely supported PRF (although usually it's used as a MAC, which is a bit different). Use a different key for the PRF then you use for encryption. Another possibility is to use a deterministic ...

6

A PRP is a keyed primitive, so proving properties of a keyed hash on top of it is often possible. Reducing the security of an unkeyed hash to a keyed primitive on the other hand is rarely possible. For example keyed Skein (a hash) is provably a PRF if Threefish (a block-cipher) is a PRP: PRF, MAC, and KDF. We prove that if Threefish is a tweakable PRP ...

6

How long are parameters used for? Usually $g$ and $p$ are kept static for a very long time indeed. In fact, the values to use are actually written in to standards. See here for an example. Those were values standardised ten years ago. So the answer is basically decades. The impossibility of brute force Let's suppose that I as an attacker decide I'm going ...

5

Well, whether $AES'$ is as secure as $AES$ depends on the length of $k_1, k_2$. If they are both 128 bit, then what you effectively have is a standard 128-bit AES, except that prior to round 6, you replace the running key with an independent key (and you tweaked the last round, but that's cryptographically harmless). Now, it is never a good idea to do ...

5

That sounds like an overly succinct description of the 'Find then Guess' (FTG) notion of security, described in the paper "A Concrete Security Treatment of Symmetric Enryption". And you are correct, there is something the test is missing: the two 'challenge' plaintexts must be the same length ($|m_0| = |m_1|$). Also, the description is so succinct I can't ...

5

One way to address this question is to notice that if there was such a vulnerability in reusing $g$ and $P$ multiple times, then that vulnerability can be used to attack a specific exchange, even if they use $g$ and $P$ only that one time. That is, changing $g$ and $P$ cannot help matters. Here is how this observation works; suppose we have a black box ...

5

Computationally indistinguishable typically means that your adversary is computationally bounded and that because of this they cannot distingush between, for example, two messages. For example, say you encrypt (with proper padding) the messages $0$ and $1$ using RSA and send them to the adversary. We would not want the adversary to be able to distinguish ...

4

We can still safely use 64-bit-block ciphers when used in an otherwise sound protocol, and all of the following three conditions are met: The effective key size is made big enough; that disqualifies DES (55-bit), but not Blowfish (up to 448 bits), TEA (128 bits), 3DES (167 bits), and to some degree 2-keys-3DES (111 bits). Note: I computed the effective key ...

4

A cryptographic PRNG doesn't care what you feed it as entropy, as long as you provide enough. Furthermore, the PRNG will not reveal anything about its internal state, including what was fed to it as entropy. So in this sense it's safe to use a password as entropy: the PRNG will not expose it. The problem with a password is that compared with normal keys, it ...

4

The two primary techniques I'm familiar with is structuring a cryptographic primitive as a sequence of games and the universally composable security framework. Sequence of Games The idea here is to represent a protocol/primitive as a game played between an attacker and a challenger. You define a bad event and show through the game that the event happens ...

4

This is at least as secure as the original cipher. The only case I can think of where it would be less secure is if the security of the cipher relied on some special relation between the round keys, but I don't know of any ciphers that have this requirement. Most ciphers derive their round keys from the encryption key in a linear way. One example of a ...

4

None of the above answers seem to take into account that you apparently want to establish security with respect to the eCK model; the above answers are mostly about tools that verify some (related but different) properties. Afaik, there is current no automatic tool that can give you analysis with respect to the exact eCK model. In the symbolic setting, ...

4

It fails to be a cryptographically-strong PRNG because it is predictable: given some outputs, you can predict the next outputs. For instance, if you observe the outputs at offsets 0, 1, and 4096, you can predict what the output will be at offset 4097. What it's missing: it's not that it's missing some little tweak (just change line 7 to use addition ...

4

I am literally quoting the paper here. You should really try to read the paper properly first before asking questions. In the notion of [22] the adversary does not get credit for finding any old collision. The adversary must still find a collision $M, M'$ but now $M$ is not allowed to depend on the key: the adversary must choose it before the key $K$ is ...

3

This question can be answered in several way depending on the exact meaning you intend for more secure. First answer: No, it is not more secure in general. The most you can expect is "at least as secure" not "more secure". A typical example of this behavior is Even-Mansour encryption where using twice the same key is as secure as using two independent ...

3

No, it's less secure because: you're not using the algorithm in the way the author(s) designed it it hasn't been subjected to scrutiny by trained cryptographers If you don't know the above already, you certainly don't have enough experience in cryptography to tinker with the inner-workings of algorithms/modes. Stick with the standard algorithm/mode, ...

3

If I understand right, your operation effectively is $$\forall i: c_i = p_i \oplus k_0 \oplus k_1 \oplus k_2 \oplus \dots \oplus k_n,$$ whith $c_i$ the ciphertext bits, $p_i$ the plaintext bits, and $k_j$ the key bits. As $\oplus$ (this is XOR) is associative, this is equivalent to $$k^* := k_0 \oplus k_1 \oplus k_2 \oplus \dots \oplus k_n,$$ \forall ...

3

Yes, you can reasonably expect that these will provide equivalent security, if you choose all keys uniformly and independently at random. The decryption operation is basically the same as the encryption operation, so it would be extremely surprising if there was any significant difference in security among these. (Of course, if you don't generate the keys ...

3

It's usually not safe to initialize it with a password, because of the risk of brute-force attacks. Do a search and you'll find lots of warnings about this risk. Your proposed password generation method does not say anything about how long the password is or how you will choose it. If it's a 8-character password, no, it won't be secure. If it's a random ...

3

This is not a complete answer but it seems to me that it cannot be more secure than the original AES since otherwise it would mean that there is a serious weakness in the AES key schedule As far as being as secure there's at least one application in which it's a weakness : when you use AES inside a Davies-Meyer construction. An attacker has then more power ...

3

The answer is "it depends". There are two fairly commonly used sets of assumptions, the so-called standard model, and the random oracle model. In the standard model, hash functions are one-way functions. In the random oracle model they are random oracles. The random oracle model isn't actually true, but it is useful and many protocols inspired by it are in ...

3

I can highly recommend AVISPA, a tool for automated verification of cryptographic protocols. It is available as a web service, so you can upload a description of your protocol to their web server and it will give you a security analysis of it. They have detailed documentation of how to use their system and of their specification language for protocols, so ...

3

Just wrapping my comment into an answer as it seems to be what you're looking for… CryptoVerif can be used for verification of security against polynomial time adversaries in the computational model. It's available via http://prosecco.gforge.inria.fr/personal/bblanche/cryptoverif/cryptoverifbin.html Related to your "it doesn't work on my computer", here's ...

3

I could add to the list (in alphabetical order): Casper (http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/) Proverif (proverif.di.ens.fr/index.php) Scyther (http://people.inf.ethz.ch/cremersc/scyther/)

3

A fault injection attack is based on the fact that you have a healthy black box on which you can do queries, but you can mess with the black box, for example flipping random bits. In real life this could for example be a RFID chip which can be messed with using strong electronic fields. Attacks like these are generally: Very sophisticated in theory and ...

3

There are two papers on conventional differential cryptanalysis of SEED. The last one penetrates only half of the cipher. Even though there are few third-party cryptanalysis papers, there is no indication that the cipher is weak. Fault attacks are quite irrelevant in the SSL setting. I would be more concerned with BEAST-like attacks, as SEED is a ...

2

You need a large random prime modulus where the discrete log is hard. Read about how to choose a prime so the discrete log is hard. Also, you want $p-1$ to have as few small factors as possible. Therefore, the short version is, I suggest you choose a large random 2048-bit prime $p$ such that $(p-1)/2$ is prime. However, Pohlig-Hellman has some serious ...

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