# Tag Info

## Hot answers tagged protocol-analysis

57

Draft paper linked from efail.de. TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying the use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within the said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common. The issue is that un-validated deciphered ...

48

There are a few parts to the EFAIL attacks. Some parts are the fault of the mailer authors for exposing unnecessary attack surface via arbitrary incoming email. Some parts are the fault of the OpenPGP and S/MIME designers for failing to heed modern cryptography engineering principles—in particular, failing to provide NM-CPA public-key encryption. For ...

32

Alright, I'll bite. First, let me propose bounding the discussion to just the core of the protocol. In particular, let's not get hung up on: Social engineering attacks How broadly the end-to-end encryption is applied (i.e. are all conversations in the app encrypted?) The backgrounds of the inventors and reasoning for inventing the protocol Metadata ...

28

In addition to the performance problems poncho already mentioned when using RSA signatures without hashing I just want to add on the security warning of poncho: Reordering If you have a message $m>N$ with $N$ being the RSA modulus, then you have to perform at least 2 RSA signatures as $m$ does not longer fit into $Z_N$. Let us assume that it requires $k$...

21

Generate a file of cryptographically strong random data at least as long as the message to be sent. This will allow communicating the secret using the random data as a one-time-pad. I.e., produce the ciphertext by using a bit-by-bit combining function such as XOR. Purchase a plane ticket for an international flight connecting through Sheremetyevo airport. ...

18

If you find a flaw or bug for example in Linux kernel you can create an issue in GitHub, or if you can solve it you can contribute. How about Finding a flaw in cryptographic protocol?! A protocol is slightly different than a concrete implementation of a piece of software like the linux kernel on GitHub. It is closer to a specification that may be followed ...

13

There are a couple of options for protocol analysis tools. (I don't know any established tool for their design - as said by someone else, designing your own protocols is not really recommended.) If you are looking for formal methods based, symbolic tools, some well-known tools that have been applied to many protocols are ProVerif and Scyther. Given that you ...

13

I assume the question is related to academic work: why do we implement a protocol if we already know how efficient it is by a complexity analysis? The answer depends very much on the type of protocol. However, the answer typically is that a theoretical complexity analysis usually does not suffice to understand the concrete efficiency. If the "previously best ...

13

NO, you can't ! I will only consider initial_vector_0 and next_block_0. What you have found is this: +---+ | | | | IV0 ---->+ f +----> state | | | | | +---+ | xor +---------> 1111111111...1 0000000000 +---+ | | | ...

12

Well, one reason to hash the data before signing it is because RSA can handle only so much data; we might want to sign messages longer than that. For example, suppose we are using a 2k RSA key; that means that the RSA operation can handle messages up to 2047 bits; or 255 bytes. We often want to sign messages longer than 255 bytes. By hashing the message ...

12

What does this mean, exactly? The purpose of the environment is to model "everything else happening in the universe" besides the protocol execution. In the UC model, the adversary is allowed to talk to the environment during the execution of the protocol. So UC security means "security no matter what else is going on in the world, even if other things are ...

11

First up, I think your question is less something for crypto.SE and would fit better in the security.SE corner. Nevertheless, here goes: ...except his name or identity... That's in itself already describes your problems when it comes to security and cryptography. Problem due to lack of verification options. Currently, world news outlets (example: ...

10

The general scheme is called Three-pass protocol and works for all commutative ciphers. It is secure for some of them, but xor (and modular addition) are insecure choices. Your scheme: A->B: $c_1 = m \oplus a$ B->A: $c_2 = c_1 \oplus b$ A->B: $c_3 = c_2 \oplus a$ B computes $m = c_3 \oplus b$ an attacker sees all of $c_1$, $c_2$ and $c_3$. So they can ...

10

Do we implement it for proof of concept? Absolutely. It's very easy to miss vital points if no implementation exists. W3C for instance doesn't even allow protocols to be standardized without reference implementation(s). Furthermore, an implementation may show small improvements as well. Personally I would require an implementation of all the (minimal) ...

8

As long as your encoding of $K$, $N$, and $i$ is injective (i.e., for each encoded string you can uniquely derive $K$, $N$, and $i$) and fixed-length, this is almost certainly a decent stream cipher. It won't break any speed records, obviously! But collision resistance is not relevant here, and I have no reason to suspect that the distribution of $x \... 7 One observation is that if we modify the problem so that$M, A, B$are random invertible matrices, then it is easy to prove the security of the system. In fact, we can prove that the system is informationally secure; that is, for any observed$C_1, C_2$pair, for any possible value of$K$, there is a unique set of values of$A, B, M$that yield that$K$(... 7 Am I going to regret posting this? There seems to be enough non-classified information available about GPS to answer this question. I see 3 reasons why P(Y) encryption is different and less likely to be hacked than game console encryption: Hardware containing the GPS decryption key is more difficult to obtain than hardware containing the game console ... 7 No, TLS is not secure against VM reset attacks. There are at least two attacks that are made possible by VM reset attacks, off the top of my head: AES-GCM nonces are typically generated deterministically from the message counter value. If you set the snap shot prior to the local peer sending a plain text message that will change after resetting to the snap ... 7 I agree with the comments, in that the aim of step 1 is likely to increase the cost of performing a man-in-the-middle attack. When two users want to verify their keys, the only information they rely on is that the 60-digit number derived from both their keys matches. Hence, an attacker would need to generate an expected$2 \cdot 10^{30}$random Curve25519 ... 6 No, IKEv2 has nothing analogous to 'main mode' and 'aggressive mode', and they eliminated the initial 'quick mode', When IKEv1 was originally written, they wanted a strong separation between IKE and IPsec; they had a vision where IKE might be used for things other than IPsec (other "Domains of Interpretation"). So, they completely isolated the "negotiate ... 6 I think it is still possible to use UC in this case. Recall the setup for the UC framework. We have an ideal world and a real world. There are parties$P_1,\dots,P_n$in each world and an environment$\mathcal{Z}$in each. In the real world we have the adversary$\mathcal{A}$while in the ideal world, we have an ideal functionality$\mathcal{F}$and a ... 6 The fact that a given cipher has a key length of 296 bits doesn't mean at all that it provides 296 bits of security or even that a brute force attack would take$2^{296}$steps. The problem of mono-alphabetic substitution cipher is the ridiculously small block size (in this case, barely$\log 64 = 6$bits). If absolutely nothing about the plaintext is ... 6 For the moment assume$g$is a secret (uniformly random) generator, but that$p$may be known to the adversary. Then given only$g^a, g^b$, the Diffie-Hellman key$g^{ab}$is information-theoretically uniform (up to small statistical error), i.e., it cannot even be found by brute force because the adversary does not have enough information to determine it. ... 6 Look up the words sound/complete from logic. Complete roughly means that a method can solve every instance. Sound roughly means that the answer it gives is correct. For example, assume that we have a program that's supposed to tell when an element belongs to a set. A sound program will only answer "yes" when the element actually belongs to the set. An ... 5 The other answers cover it quite elaborately, but in short: No. But let's consider this to be a game, with the following assumptions: There is a person called "Snowden". Somewhere. In the world. And he has no way to authenticate himself. Snowden initially trusts no one. There is no trustworthy way to authenticate anyone. What is the attackers probability ... 5 An implementation should generate the IV from any cryptographically secure PRNG. TLS 1.1 further details the possible ways to do that: The IV can be obtained from a PRNG. A random string$r$can be generated from a PRNG, and added to the plaintext to encrypt where the IV should go; then the whole lot is encrypted with either a fixed IV, or even the last ... 5 Yes, there are several ways in which Mallory could pretend to be Amy. One obvious way, which doesn't even involve Amy herself in any way, would be for Mallory to perform steps 1 and 2 of the protocol normally, as if he were Amy. Then, given Betty's nonce$n_b$, Mallory can start a second, parallel instance of the protocol, again pretending to be Amy, and ... 5 We can attack the MAC defined by: MAC(k,m)=MD5(m||k), in a chosen-messages setup, basically because MD5's collision-resistance is broken. The adversary chooses m and m' of the same length$b\ge64$bytes, differing only in their first$\lfloor b/64\rfloor\$ 64-byte blocks, such that there is a collision after hashing these blocks of m and m'. If follows that ...

5

Besides Joshua Warner's excellent answer, I do also want to point out that someone has to "roll their own crypto" at some point for there to be any designs and implementations at all. On that front, the Signal protocol was chiefly designed by Moxie Marlinspike, a cryptography and security researcher with a solid track record and credited with multiple ...

5

Strictly speaking, it does make a brute-force attack more likely to recover a key for any message pair, but the impact of recovering a single key is minimized by frequent re-keying, since that key can't aid the adversary in decrypting any other messages. If you don't re-key, a brute force attack is only marginally more difficult but success gives you ...

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