# Tag Info

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

16

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

11

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

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

11

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

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

9

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

8

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

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

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

5

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

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

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

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

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

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

4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...

4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...

4

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

4

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

4

As usual, I ask a question after a couple of days of research, then immediately realise the answer: I'm doing it wrong. My definitions included the following "suites": SSL2_RC4_128_WITH_MD5 0x010080 SSL2_RC4_128_EXPORT40_WITH_MD5 0x020080 SSL2_RC2_CBC_128_CBC_WITH_MD5 0x030080 SSL2_RC2_CBC_128_CBC_WITH_MD5 0x040080 ...

4

OTR uses 128 bit AES-CTR. There is a risk that the same AES key will be generated more than once, but if significantly less than $2^{32}$ messages are ever exchanged between any pair of peers, this risk might be safely considered to be negligible. However, if a pair of peers exchange more messages than $2^{32}$ and depending on how the implementation ...

3

Well, it has the obvious problem that if the UA has both $d_1H(r)^{k_1}$ (from the party) and $H(r)^{S-k_1}$ (from the UA), it can compute $d_1$ directly.

3

Yes, because Mallory can use Amy and Betty to get any encrypted nonce; Amy and Betty are oracles for Mallory. She just has to send the nonce she has to encrypt to either one of them and they perform the task for her (in another "authentication attempt", using step 1 & 2). Usually you protect against this kind of situation by performing an encryption ...

3

Encrypting the AES key does not actually make a brute force search any harder: an attacker doesn't need to know the encrypted key to decode messages, they only need to know the actual AES key. Thus, the attacker only(!) needs to search the 256 bit AES keyspace, not the roughly 296+256 = 552 bit encrypted keyspace. Besides, even if the attacker did try an ...

3

I personally recommend the CryptoVerif in http://cryptoverif.inria.fr/, and the Scyther in http://people.inf.ethz.ch/cremersc/tools/index.html.

3

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

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