# Tag Info

6

An attack would be trivial if the seed of the RNG was only 32 bits; just enumerate the seeds, and test which matches the intercepted messages. That's easy. However the default Java Random class uses a 48-bit state and seed (which would still be attackable, though $2^{16}$ times less easily), and there are safe subclasses, thus use of Random does not imply ...

6

CRAM-MD5 is a protocol to demonstrate knowledge of a password. In the context of email, it is sometime used by an email client to authenticate to a POP, IMAP, or/and SMTP server. Basically, the password is used as the key of HMAC-MD5 in a challenge-response protocol. Among positive things there are to say about CRAM-MD5: The password is not exchanged in ...

6

Handing keys in general is known as key management. Symmetric keys should be kept secret. Secret key is often used as a synonym for symmetric key. The establishment of symmetric keys can be performed in several ways: (Authenticated) Key Agreement (KA) Sending of an (authenticated) encrypted key, also known as key wrapping Derivation from a base key using ...

5

There is nothing related to passwords in AES. AES uses 128-bit keys, i.e. sequences of 128 bits. How you come up with such a key is out of scope of AES. In some contexts, you want to generate these 128 bits in a deterministic way from a password (and possibly some publicly known contextual data, like a "salt"); this is a job for password hashing. In other ...

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

4

Fair exchange protocols aren't new by any means, but there is a lack of layman-friendly material out there, unfortunately. I think the high prevalence of theoretical cryptography in fair exchange protocols may be partially responsible for that. At any rate, here is the basic idea behind a fair exchange protocol. Suppose you have two parties, Alice and Bob, ...

4

Think about this, say my public key is 9821347676528476512348612390874073765227653408545634205496835 (note this is not a valid public key, just randomish typing). What does that mean? Big or little endian? Hex or decimal? Specifically for RSA, where is $e$, where is $N$? What is this public key authorized to do (encrypt, sign, etc)? Who has signed this ...

4

Without pairings, there is no known single round tripartite key-exchange algorithm. However, it is possible to do it in two-rounds. For example, refer to the Burmester-Desmedt conference key protocol (http://www.cs.fsu.edu/~burmeste/eurocrypt_plus_proof.pdf) which in fact works for an arbitrary number of users. This being said, would it be possible to find ...

3

Most likely, this 'shared secret' was actually an IKE "preshared key"; it is used to authenticate the two sides (and, for IKEv1, is stirred into the keys). It actually isn't used as a key (and hence someone learning that key cannot use it to listen in, unless they perform an active Man-in-the-Middle attack). I suspect the password is the authentication ...

3

It is possible to achieve PFS against active adversaries in two messages. The "as we know" that you mention is incorrect; this misconception seems to stem from over-interpreting Krawczyk's result in his HMQV paper from 2005. At best, the argument seems to hold from protocols that exchange messages of the form g^x, g^y, where x and y are random values: for ...

3

The key must be kept secret or it is no longer an encryption system. They key must be shared at some point, when is not important, but how is, and how determines when. You can send encrypted messages to someone, then hand them the key on a post-it note at a later point in time so they can decode it, or on a flash drive, or some other physical handoff or ...

3

Asynchronous forward secure encryption is possible if you allow users to have synchronous clocks. It seems impossible without that or a third party, though I am aware of no formal result. A trivial(and hence awful) solution is to generate N key pairs and use one for each interval, discarding them as we go. A somewhat more efficient solution is to use ...

3

SIGMA The SIGMA paper does not describe how a "response message" for SIGMA-I would be implemented. If it was implemented as (for example) $B$ sending $\:\operatorname{MAC}_{K_m}\hspace{-0.02 in}(\text{"ACK"})\:$ to $A$, then that would not actually provide the desired peer awareness property in the case where $\: B = \text{"ACK"} \:$. If || denotes ...

3

I will address your question below, however I have a serious concern that I want to bring up first. I glanced at the $p$ used in ngx_ssl_dhparam, and it is not immediately obvious that it was chosen correctly. Unless you know that whoever generated that value knew what they were doing, you should select a different value. The security of DH depends on, ...

2

You are inventing your own protocol. Don't do that! You're likely to get something wrong. Instead, use SSL. You can use SSL with a server cert and a client cert. That solves exactly this problem; each party can verify the public key of the other end of the communication and verify they're talking to who they want to talk to. If everything checks out, ...

2

Generating an (EC)DH key pair entails "producing" the group parameters (the curve or the modulus+generator), then the private key $x$, (a random integer modulo the group order $q$), and then applying the private key to the generator (i.e. computing $xG$ on the curve, $g^x \mod p$ for plain DH). Producing new group parameters would be the most expensive ...

2

The open source version of CyaSSL contains code that calls into the commercial NTRU library -- the library itself is missing of course. You might be able to make CyaSSL work with the open source NTRU implementation at https://github.com/tbuktu/libntru ; it's alpha level software though.

2

There have been a large number of so-called authenticated key exchange (AKE) protocol proposals in the literature since the sigma protocols that could be used to replace them. I know of too many to list. They offer various advantages over the sigma protocols, ranging from various stronger security properties (some interesting ones, some which might be of ...

2

The first part of the protocol – e.g. alice choosing a random secret key and sending it public-key-encrypted to Bob – is in essence the same as the usual RSA key exchange used in SSL/TLS. As you mentioned, Mallory can't read the key, but can start her own connection to Bob pretending to be Alice, so this part only provides authentication of Bob for Alice, ...

2

Given a SSL-enabled web site, the Qualys SSL tester will tell what ciphersuite would be negotiated by a bunch of different browsers if they connected to that web site. It will also tell you the list of ciphersuites supported by that server and the list of ciphersuites are supported by each of those major browsers. For example, here is the output for one ...

2

I guess the best place to begin is with the paper that started it all: Entity authentication and key distribution, by Bellare and Rogaway. In a nutshell, they define a protocol to be a secure mutual authenticated key exchange if it fulfills the following four criteria (I will explain the term "matching conversation" below): Matching conversations ...

2

We know that traditional mathematical proofs can contain mistakes, and that these mistakes can remain undiscovered for years. Sometimes, the scheme is secure even if the proof is incorrect, e.g. RSA-OAEP. Sometimes, the scheme is mildly flawed, the flaws undiscovered because of mistakes in the proof, e.g. HMQV. And sometimes a scheme is simply insecure. We ...

2

In an ordinary ID-based scheme, you won't get strong PFS. The center always knows a secret that can be used to recover your private key and thus can violate PFS. One approach is a hybrid scheme, such as the following. You could do a (non-ID-based) Diffie-Hellman or ECDH key exchange, with messages signed and authenticated using an ID-based signature ...

2

First, understand that keys need to last only as long as you need to recover what they are protecting. If you are storing a secret in a box until next year, you have to keep the key until next year. But if we're talking on the phone, we only have to keep the key for the duration of the phone call. If Alice and Bob are going to speak securely, they don't ...

2

PKCS#3 is an older standard which only defines the DH primitive itself. It contains the following information: parameter generation, the Diffie Hellman key agreement algorithm, integer/octet string conversions (as in PKCS#1, RSA) and the specification of an ASN.1 structure for the parameters. The ASN.1 structure is very limited, containing only the necessary ...

2

Is there any chance of finding symmetric key from encrypted public key? The answer is no, assuming the symmetric key has sufficient entropy and a secure encryption algorithm and mode is used correctly. Modern ciphers like AES with proper secret keys are not vulnerable to known plaintext attacks. Why? This has been answered in an earlier question: Why ...

1

For the Legendre symbol and DDH: when working modulo a prime $p$, you can have have a group where DDH (apparently) holds. Namely, suppose that there is a known prime $q$ which divides $p-1$, and $g$ has order exactly $q$. This is easy to achieve if you generate $q$ first, then look for a prime $p = qr + 1$ for some random values of $r$; then, to compute $g$, ...

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

The difference between weak and strong perfect forward secrecy lies in the capabilities of the attacker. Perfect forward secrecy is strong if it remains secure in the face of an active attacker, while weak perfect forward secrecy's security claim only covers passive attackers. If I'm not mistaken weak perfect forward secrecy (wPFS) is a term introduced to ...

1

Let me propose you this: Try to write down your protocol without any security proofs. Since you think that there are no attacks, give it a try here: Proverif (http://prosecco.gforge.inria.fr/personal/bblanche/proverif/) or Scyther (http://people.inf.ethz.ch/cremersc/scyther/). They are tools for formal verification of protocols. Not only will they tell you ...

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