# Tag Info

0

So your idea is that the client does the work in calculating the slow hash $B(P)$, and proves that to the server by using a hash as an encryption key. It is definitely not a standard way to do things, and has some problems. In particular, any eavesdropped can trivially launch an offline dictionary attack on the password, so it is like your normal password ...

0

SRP confirms that the server knows the verifier. To elaborate on the comment by @otus the design document the server steps are: Host: S = (Av^u) ^ b (computes session key) Host: K = H(S) Where K is the shared session key. Then the client and server prove that they have the same verifier: One possible way: User -> Host: M = ...

1

Nimbus or Thinbus are two popular SRP implementations in Java and Javascript compute the proof of password as you describe H(A|B|S) where you can supply your own hash functions such as SHA1 or SHA256 or stronger. The actual protocol design document states H(H(N) xor H(g), H(I), s, A, B, K) where K=H(S) so that expands to H(H(N) xor H(g)|H(I)|s|A|B|H(S)). ...

2

The short answer is that there's no link between your physical signature and any cryptographic signature. Indeed, from the high-level description of how DocuSign works and their security manifesto there's no reason to believe that any cryptography goes into the signature process itself. Note that “signature” is an overloaded word. In this post, I will refer ...

1

Now I would like to use a single-block AES128 for the HMAC calculation in this scheme [...] HMAC requires a hash function with a variable input size, so you cannot just use AES in it. If you want to use some other MAC instead of HMAC, you can use AES. AES ECB is a secure MAC for single block messages, so that would work. Given this answer to a ...

3

If we assume that AES is a pseudorandom permutation (which is a standard model for block ciphers), then AES can replace the HMAC in your construction. Be aware, this only works because you have a fixed message length, i.e. the protocol must not accept nonces $> 128$bit. Besides, I guess you are aware of this but you have a shared secret key among all ...

2

The reason Lamport's scheme is secure against a passive attacker is that even if they see $H^{n-1}(p)$ for a given $n$, the server would require the preimage of that hash, $H^{n-2}(p)$ on the next login. The active attack, in comparison, allows Trudy to find an earlier iteration than the server is expecting. That allows calculating several login hashes by ...

-1

Yes, that is possible. One of the most prominent examples is the Direct Anonymous Attestation (DAA) protocol. It is used in the TPM.

2

First, authentication is not really “proving that someone is who they say they are”, but linking an action, message or situation with an identity. If I show my passport to prove who I am, what I am really doing is linking my physical presence with the identity conferred to me by the state of which I am a national. A person may well have multiple identities. ...

0

A full solution is impossible. If the third party is able to verify the validity of tokens, they can brute force through the 10-20 bit token space and generate all valid tokens. So the third party cannot both be able to validate and not be able to forge. The below solution achieves one of the two. Tie each secret key $k_i$ to an identifier $i$. Generate ...

2

I see 2 options that fit the requirement (small, verifiable within some limit). Because the sizes are small, the probability of the collision of a random value showing linked is high, larger values will obviously help. Option 1 is to have a random value, and encrypt or hash it, then truncate the result and concatenate to the original value. The size of the ...

1

Create a public/private key pair. Generate a random value and sign it with the private key. Call that the random token.

3

My question is how do I authenticate my App to the CA, to prevent something else to request these Client Certificates? There is generally no way to authenticate the client code. Any secret you embed in the app could be extracted. You must assume an attacker can send requests that an authentic client would. Instead, what you can do is authenticate the ...

1

You'll want to integrate something in the request that is unique for the device or the user. This can be an iOS specific identifier or a hardware specific identifier. Furthermore, what you want is to make sure that the request came from your software. You can do this by authenticating the request somehow. For this you need a secret key. I guess the most ...

1

According to the Stanford page mutual authentication can be provided if both sides keep their secrets secret. Thanks mikeazo.

1

Since these keys are not signed, how can one authenticate the other to guarantee that the keys were not altered/switched? They have to be signed. By the key-exchanging parties, using their long term keys. Even if the keys are exchanged over an verified channel (for example using the signed and trusted public keys) that doesn't automatically ensure ...

2

I think you're confusing some things here. The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly. And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't ...

0

Yes there is. You have a lot of possibilities. You can check different protocols: Station to Station, NAXOS, KEA and KEA+, ...

4

I really like this question, and have two things to say. First note that CBC-MAC is no good since given the key it's easy to find a collision. Let $t$ be a tag for a message $m=m_1,m_2$ of length $\ell$ bits. Then, in CBC-MAC the input to AES first is $\ell$ and then the output is XORed with $m_1$ and input to AES, and so on. Let $t_1$ be the intermediate ...

5

It is hard to have message authenticity without integrity. To authenticate the message you need to know what message is being authenticated. If you could change the message the authentication tag should become invalid. Message authenticity means that you can establish that the message originated from a trusted entity. For this reason message authenticity ...

0

There is no single "correct" one. There are different notions of authenticity that make sense in different context and encode slightly different goals.

Top 50 recent answers are included