# Tag Info

## New answers tagged protocol-design

0

Here's a simple solution, but with some proviso's that may or may not be acceptable... Alice's private and public key: $skA$, $pkA$ Bob's private and public key: $skB$, $pkB$ Encryption is $E_x(P)$, where $x$ is the key, and $P$ is the plaintext. Decryption is $D_x(C)$, where $x$ is the key, and $C$ is the ciphertext. Summary of Protocol $A \rightarrow ... 3 I may be interpreting your question incorrectly, but it sounds to me like you are asking if Caroline can prove (in court or whatever) that she can only gain access to some secret$S$if both Alice and Bob collaborate in revealing it to her. Unfortunately as you have currently set up the question, I don't think that is possible, because your question ... 6 SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010. With stream ciphers, MAC-then-encrypt ... -1 if you do encrypt first you have to have pre-shared secret keys between client and servers? once master secret is generated then Record protocol job is to encrypt/decrypt. 0 After having thought about this for a considerable amount of time I came up with the following as the easiest and best solution I could think of. The following protocol assumes that Alice is trusted whereas Bob isn't.$S_X(P)$denotes signature by$X$on$P$.$E_X(P)$denotes encryption using the public key of$X$of message$P$.$E_{K_X}(P)$denotes ... 2 Covert two-party/multi-party computation provides exactly what you're looking for. The two-party case was introduced by von Ahn, Hopper, and Langford, and a more formal definition and multi-party protocol was given by Chandran, Goyal, Ostrovsky and Sahai. Covert secure computation even hides whether or not the parties participated in the computation at ... 0 Your design is that the server has a key (which you call the salt, but would have to be secret here) and generates the client's public and secret values using e.g.: $$p = ID\\ s = H(k|p),$$ where$H$is some hash function. This seems secure: if an attacker only has access to$p$they have no chance of generating$s$without knowing$k$. However, if$H$is ... 0 If Alice and Bob express their interest in the other party as a single bit (say 1 for 'crush' and 0 for 'not crush'), essentially what you want is for Alice and Bob to privately compute the logical AND of their two bits. If you also assume they will not lie in their interaction (i.e., they are at most passively corrupted), then there is a simple solution ... 0 Ah, cryptographically secure tinder If Alice and Bob also broadcast messages to many other with non-yes answers then the other party wouldn't be able to tell the difference between a "no" and a "did not choose" In this case, the "yes" does get a "no" (atleast, "not interested") from the other party, but the "no" doesn't know the other party chose yes. ... 1$A$has outsourced it's private data to the server, right? In that case$A$'s private data has already been leaked to the adversary when the server was corrupted. So there is no added leakage in$B$also learning this data. In fact since only one of$B$and the server can be corrupted (assuming static corruptions) we can conclude that$B$is honest, and ... 0 Without the initial exchange of nonces, an attacker could replay a recorded handshake. Although an attacker can't use this to replay actual packets, an attacker could possibly execute a denial of service attack if the process protected by spiped is not expecting a large number of connections. The attack (assuming a modified spiped protocol that MACs the ... 0 Without the nonces, one could violate explicit authentication by replaying the group_element || MAC_tag messages. 1 Should we sign-then-encrypt, or encrypt-then-sign? ... Do the same issues with (symmetric-key) MAC-then-encrypt apply to (public-key) sign-then-encrypt? Yes. From a security engineering standpoint, you are consuming unauthenticated data during decryption if you mac-then-encrypt or sign-then-encrypt. A very relevant paper is Krawczyk's The Order of ... 1 You could ask Alice and Bob to rate their "affection" for one another using some scale, then apply a protocol for the Socialist Millionaire's Problem (a variant of Yao's Millionaire's Problem) to determine whether the values are equal. If the scale is finite (say, in the range from 1-10), then a party can learn some information about the other's value by ... 1 You could do something fairly simple, such as$UserSecret = Random()UserID = HMAC(ServerSecret, UserSecret)$Send the user the two values. When he reconnects, he sends the two values back. If re-calculating$UserID$with the user's$UserSecret$gives the same$UserID\$ then that proves (to a high degree of certainty) that it's the same person that was ...

2

NOTE: My cryptography-based solution above (accepted answer) is my preferred method, but since it is significantly different I am including my old answer here (I did not want to clutter my other answer with it). Non-cryptographic solution: While the above extension to the BitTorrent protocol would require a lot more work, you can still nearly eliminate ...

Top 50 recent answers are included