Hot answers tagged

6

Even after your updates, the first part seems unnecessary. However, steps 4-5 do indeed prevent the attacker from learning future nonces they could ask the key MAC values for. So the protocol steps 4-7 would be secure with a secure MAC. I agree with CodesInChaos that using HMAC would be better, because H(m||k) has some weaknesses, while HMAC is standard. ...


5

The intend appears to be that vector is secret and the main key; and version (that, we are told, is secret) is an extension of that key (or variant selector). 1) I could say that ResetCode is a MAC of quote with key vector and version. 2) Never met this particular one. Anyone with common sense should laugh at it as snake oil if it pretends to be military-...


5

A good PRNG can't be exhausted, so your argument against random bytes doesn't matter. firstly I'd like the server to be completely stateless. Sounds impossible to me. a PRNG needs state. A clock needs state. An open connection is state too You probably want to store open challenges too. This part isn't strictly necessary, but very convenient. ...


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


4

Using time of day is predictable. Challenges should be unpredictable to an adversary. If they were not (as you sort of say), the adversary could solve a set of challenges ahead of time and then use them in rapid succession to cause a DOS. You want to meter access to the service, which is about not only ensuring clients do some work, but that work is done at ...


3

This is vulnerable to a length extension attack. Given a valid nonce/MAC, the nonce can be extended to forge a new valid nonce/MAC value. This is because $m_4$ is appended to the end inside the outer hash. How this affects you will depend on how you validate your nonce. But in general, this is not a secure construction. There's probably more things wrong ...


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

The Wikipedia article points out a good reason for using a random challenge value: preventing replay attacks. If the hash was always the same (as the hash of the symmetric key would be), then having listened in on one challenge-response cycle, a malicious listener could pass further handshake tests.


3

Whilst your altered vector value will influence the results, this extension of your script demonstrates that typically obtaining a single quote/reset pair is enough to reveal the secret version: def find_versions(quote,reset): """ Brute force search for version keys that produce reset from quote """ versions = [] for version in range(256): ...


2

It depends on the particular scheme. In a simple challenge-response scheme, the server sends a challenge, the client "encrypts" the challenge and the password to form a response, and then the client sends the response over the wire. However, standard logins typically don't use challenge/response. The password is just sent to the server by the client. When ...


2

You need to first understand the security properties you are trying to achieve. Possible security goals: It shouldn't be possible to answer convincingly if you don't know the secret If you do know the secret and provide a response, an eavesdropper shouldn't be able to extract the secret from seeing the challenge and response The challenger shouldn't be ...


2

Reading the original paper, I figure out the question. This voting scheme employed the well-known undeniable signature scheme, proposed by Chaum and Van Antwerpen in 1989 (or Chaum 1990 or Chaum and Van Antwerpen 1991). KeyGen: The RA is a signer and has a public key $X = g^x$ and a secret key $x$ Sign: For a message $m \in \mathbb{G} = \mathbb{Z}_p$, the ...


2

Designing such a challenge is Impossible. If we assume that having a connection is equal to being able to exchange any piece of knowledge at any given time then the proof of impossibility of such challenge is as follows: Proof. First assume that there is such a challenge and Alice is capable of querying such a challenge to correctly determine whether the ...


2

Yes! Here is one such scheme. Let $s=\mathcal S(x)$ be what that the question's tiny device produces for 64-bit input $x$, and $\mathcal V(s,x)$ the public verification function for that, which outputs $1$ if $s$ matches $x$, $0$ otherwise. I'll assume this resists existential forgery under adaptive chosen message attack, and we want to extend it to ...


2

Here is a small scheme how this works : Server Client | | | r,n | S: Find s such as HMAC(s,r) = xxxx0000 | ==========> | | | C: *compute HMAC(0,r) = 123456789* | | C: *compute HMAC(1,r) = 124687946* | | C: *compute HMAC(2,r) = 164946518* | | C:...


1

No, there are no problems (which I could see) with re-using the signature key in this scenario. There are two potential concerns: It may be possible to learn something about the private key using the challenge-response protocol It may be possible to re-use the signature of a run of the challenge-response protocol for TLS The first concern is clearly ...


1

From your question, I believe that what you are looking for is a proof of storage. I will point you in the direction of one paper, and you can use that to look for other work on the topic.


1

Neither scheme, as described, is secure against man-in-the-middle attacks. In particular, an attacker who wants to impersonate the client can simply relay the server's challenge to the real client, pretending to be the server, and then relay the real client's reply to the server. After that, they're free to keep pretending to be the client. However, ...


1

As long as properly implemented using secure algorithms, there is no real security difference. In both cases the protocol is secure as long as the underlying signature or encryption algorithm is. However, one difference is the random number used: In scheme A the numbers must be unique. If the server ever reuses a number, then an adversary could replay a ...


1

In real communications, you often don't reliably know each others' public keys. X.509 certificates provide a way to verify a public key (as the certificate is signed by another key, and that key can be in a certificate signed by a third key, and so on, until we reach a public key that the other person does trust). Certificates are unnecessary when both ...


1

Unfortunately, you are probably not going to be able to fill in the missing details, unless you have a great deal of crypto experience (which it sounds like you don't have). You could start by reading about zero-knowledge proofs. There's a lot of information on that subject available. You will need to know it before you can progress. It sounds like you ...



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