Tag Info

Hot answers tagged

9

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


8

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


6

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

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


5

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

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


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

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

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


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


3

I assume that Alice is capable of accepting a connection while negotiating another, and let $A_2$ and $A_1$ denote her two roles. $\;\; A_1 \to M \:$ : $\:$ Alice, $nonce_1$ $\;\; M\to A_2 \:$ : $\:$ Bob, $nonce_1$ $\;\; A_2 \to M \:$ : $\:$ $nonce_2$, $E_{k_{AB}}\hspace{-0.04 in}(nonce_1||k_2)$ $\;\; M\to A_1 \:$ : $\:$ $nonce_2$, ...


3

If we assume that $E$ is just semantically secure, without providing authenticity and integrity of the encrypted message then this scheme is has a huge drawback. It would be possible for an attacker to pose himself as either A or B, or to alter any message send from A to B. So without authenticated encryption, this scheme may protect against eavesdropping, ...


3

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


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


2

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


2

I don't think the approach you sketched helps very much. If the server is compromised, the attacker can pretty easily modify the server-side software to log and record all the cryptographic keys, and then you haven't gained anything. Therefore, I don't think the approach you sketch is likely to be a great way to spend your limited software development ...


2

In my experience the persons doing the standardization may not know about formal methods in the first place. And even if a formal method was used, they would not know how to assess it. Note that whatever mathematical method is applied, the security of a protocol is still dependent on how the domain was modelled. If the model is even slightly incorrect, a ...


2

I'll assume the obvious: Alice checks $nounce_A$ deciphered from data received at step 2 before proceeding to step 3, and Bob checks $nounce_B$ deciphered from data received at step 3 before proceeding to step 4. Including when $E$ is authenticated encryption (as stated in a comment to the question), and we suppose the origin and step number is inserted in ...


2

If the attacker M is impersonating both A and S, then he obviously doesn't have to bother sending the third message in the protocol to himself. Thus, the protocol reduces to: M(A) → B: A, Na B → M(S): B, {A, Na, Tb}Kbs, Nb M(A) → B: {A, Kab, Tb}Kbs, {Nb}Kab where M(A) and M(S) denote M impersonating A and S respectively. By itself, this is not a ...


2

From my understanding, this protocol makes use of a trusted third party in order from A and B to exchange a symmetric key, $K_{AB}$. For the protocol to work, it is assumed that both A and B must share a master key, $K_{AS}$ and $K_{BS}$ respectively with the trusted S and A wants to communicate with B but they has no shared secret. Since there is no ...


1

Well it makes the arguments about PFS stronger. If they would not frequently do a re-keying and securely erasing the old key (note that then they can not even read their own past messages anymore) an adversary that breaks either into Alices or Bobs computer and gets the shared secret can read and link all the previous communication between Alice and Bob. ...


1

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


1

Ziv-Lempel is a data compression algorithm, so in general it doesn't protect your data. As for your question: More generally, how difficult is it for an adversary to distinguish two strings which have been Ziv-Lempel encoded but not encrypted? An adversary just can decode two strings and compare them. Due to the fact that Ziv-Lempel is an encoding ...


1

Maybe this question relate to public-key version of protocol. In this case, adversary could start two synchronous exchanges with Alice and Bob, and use Alice responses to convince Bob, that he communicating with Alice. More information


1

We consider a server $S$ and a bunch of users $U_1, \dots, U_n$. What you want: Users should be able to send queries to the server and receive replies. The users should be able to register identities with the server. Any reply $m'$ that a user accepts as coming from the server in response to a query $m$ from that user, really came from the server in ...


1

Usernames A hashed username is fine; a nice idea for the security paranoid actually. If all username records use the same salt, then a rainbow attack is theoretically possible - as is knowing that a user has X pieces of secured information (plus timestamps etc). But you need a single salt per table if the username is the tuple selection mechanism. Secret ...


1

Is there a vastly simpler way? I think so. Let the server send a reset token in the following form: (deadline, HMAC(server key, id_user || S || deadline)) That is, the server calculates an authenticator that allows id_user to change their secret from S before deadline. The key used should be only known by the server and can be changed often, since ...



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