Tag Info

Hot answers tagged

11

The solution is called onion routing; the gist of it is that there are a number of anonymising servers; when Alice wants to send a message to Bob, she picks a random route through a number of the servers; she then repeatedly encrypts the message for each hop, and sends the encrypted message (which states only the first hop in the clear) to the first server. ...


8

Annex E.1 of RFC 5246 contains the following text which is a nice summary of the situation: Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will ...


7

Short answer: Because the browser developers have long thought interoperability to be more important than security and standard compliance. Slightly longer answer: Some SSL/TLS server implementations do not negotiate the protocol version correctly, but terminate the connection with a fatal alert if the client attempts to negotiate a protocol version that ...


5

The protocol's description includes "Alice then encrypts $R_B$ with her private key". This has no standard meaning. Comments have clarified it is used an "RSA encryption scheme with proper padding" and I am taking as granted that encryption of $R_B$ using the private key half of $K_A$, denoted $K_A^-(R_B)$, is obtained by padding $R_B$ as in encryption, then ...


5

For P2P authentication, you can go for web of trust concept. Simply this means, if someone is trusted by people you can trust, you can also trust that unknown person. In OpenPGP, a certificate can be signed by other users who trust the association of that public key with the person or entity listed in the certificate. So trust relationships can be ...


4

You may be interested in something like the Cryptographically Generated Address (CGA) from RFC 3972. CGA is used in Secure Neighbor Discovery Protocol (SEND) of RFC 3971 to bind a public key to an IPv6 address. The basic idea of CGA is to generate part of the IPv6 address by computing a cryptographic hash over the public key. The corresponding private key ...


4

That was a bad edit to Wikipedia. The phrase "Carry-forward verification" is not a standard, well-known term in the cryptographic literature. It should not have been included in Wikipedia without a reference to something more specific. But oh well, no one is perfect, sometimes these things happen. Your request for an elaborate survey of MITM defence is ...


4

Anonymity is indeed hard. How practical does it have to be? There's a trivial solution which is to broadcast everything. That way Carol can make correlations based on the time of messages but otherwise cannot know the destination of each message. The messages can be filtered by the recipient based on an encrypted destination identity that only they can ...


2

No. This does not help Eve the eavesdropper. AES is secure against known-plaintext attacks, so knowing that the same plaintext (kaes1) was encrypted under two different keys (k1 and k2) does not help her to recover any of the keys or break of the traffic. Of course, it still might not be a good idea to do what you suggested: there might be other reasons ...


2

I wouldn't consider voice or video to remain a secure means of identification for much longer. Advances in real-time video stream editing are near enough to reality that I wouldn't build a new security system on it. In the olden times in millennia past, you could have the computers on either end display a short MAC for both parties to alternate reading ...


2

Why are there exactly $m$ values for $k$? Well, assuming $k$ is the value of the shared secret that either Alice and Bob derive, well, that's not true; there are at most $m$ possible values, however it may be fewer. There will be exactly $m$ values if $g$ is a primitive root modulo $p$; however when we use Diffie-Hellman in practice, we generally avoid ...


2

Authentication without a central server (as trusted authority, e.g. root of a PKI) is a difficult task. The main question is, what actually defines the identity of a user and which information can be used to verify an identity claim. One idea would be to use digital signatures, where each user holds his own signing key and can verify himself by signing ...


2

Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy ...


2

Firstly, PKI makes use of a private key and a public key. The private key is known only to the user, while the public key is communicated securely via the use of certificates. To provide authentication and non-repudiation, users may sign a message with their private keys and obtain a digital signature. Any other users can verify that the signed signature is ...


1

The question Alex linked in comments explains why authentication works to prevent a man-in-the-middle attack on Diffie–Hellman. So, whenever you can do the key exchange in an authenticated channel, you can be sure there is no MitM attack. (Assuming DH problem remains unbroken, of course.) Now, your questions: Is one solution for both Alice and Bob ...


1

The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and ...


1

DrLecter is right. It all boils down to making sure to use the right public key. In fact this is the same for any public key cryptosystem be it RSA elGamal or ECC variants thereof. A MAC or whatever other construction local to your system won't do the job. The MAC e.g. can only make sure the last "editor" of the message knew the symmetric key the message ...


1

No, because Bob cannot know for sure who send the public key in the first place. So impersonation may still be an issue, even if man-in-the-middle attacks are not possible. If the communication is over a channel that can only be eavesdropped by Eve (i.e. Even cannot send anything to Bob within Bob knowing it is not from Alice), then this is secure. But ...


1

…what if I only verify the signature of one end? Bob would not be able to know if he is looking at a signature by Eve, or if it’s a valid signature coming from Alice. In case if Eve is messing with the exchange, Eve would be able to inject her own (as it is handled non-authenticated) and Eve would be able to verify that it’s Bob on the other end (which ...


1

Server distribute respective private keys to A (PrivateKeyA) and B (PrivateKeyB) and stores their public keys (PublicKeyA and PublicKeyB) within it's database. Now any of the user (eg A) generates a random session key (K) and encrypts this key with its own private key (PrivateKeyA). Since server has public key of A, it can decrypt the encrypted session key. ...


1

In short: If you assume no shared secret, you can not build anything. For some theory on this, a similar assumption is formalized in the Dolev Yao model (all messages are send via the attacker, assumes perfect encryption), where no unauthenticated key exchange is possible. If you assume a shared secret, then it depends on the kind of secret to run a number ...


1

SSL offers protection against Man-in-the-Middle only if the client can make sure that what it believes to be the server's public key is, indeed, the true server's public key. X.509 certificates aim at providing this information, but this is relative that no rogue CA was involved. A "rogue CA" is here one of: An evil or gullible root CA ("subverted" CA ...


1

Modifying the video stream or creating a fake of the video with your own QR code is not hard, so your specific proposal is not secure. Verifying the identity of someone who you have never met, remotely, when they are not physically present is... well, it's challenging.


1

I think you have to specifically define what you're trying to do. Just "authentication" doesn't quite make sense from a practical stand point. I can thinking of saying "hello" to someone for the purpose of "ok, if you get a hello from me then attack!!", but that protocol would look differently than what you're trying to do. Why would you just ...


1

No, since compromising the communication $\:\implies\:$ compromising the PKI setup $\:\implies$ falsely claiming that a party generated a particular public key $\:\implies\:$ "if Alice … immediately." . Yes, we might assume that. Note that, if the channel can carry voice, then faking a comparison can require voice impersonation. This is the idea behind ...


1

You are right that the session public keys can be replaced if they are not signed by long term private key known to all parties. What you want to do is not have Trent do anything but be a relay, then you need a standard key exchange process between the two parties using new random key pairs. Then once all parties have both public keys, they can generate an ...


1

You basically ask the following question: Is there a weakness anywhere if I encrypt the same message independently with 2 different keys? To answer this, please consider the following: The cipher text coming from a perfect encryption algorithm is indistinguishable from random data. Practical encryption algorithms have some flaws, leading to ciphertexts ...


1

How do cryptography in SSH(2) work? This is a very broad question. If you're interested in the details, then read the relevant RFCs that describe the SSH protocol. In particular: RFC 4253 - The Secure Shell (SSH) Transport Protocol RFC 4252 - The Secure Shell (SSH) Authentication Protocol Does key authentication in SSH(2) protect from MitM by ...


1

I am sorry that I can not comment your post, and have to write this as answer... But maybe you want to move this question to security.stackexchange.com. And the security goal of key authentication is that both enities can be sure that the public key of the other person actually does belong to the other person. This should prevents a potential attacker ...



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