Hot answers tagged authentication
11
A few observations:
RC4 suffers from related key attacks. This means your idea of concatenating a 224 bit key and a 32 bit IV is not a good idea. You should rather use $\operatorname{SHA-256}(Key||IV)$
Remember that a (Key, IV) pair must not be reused, ever.
A 32 bit IV can work if it's a counter, but IMO such a scheme is unnecessarily fragile. I'd rather ...
9
There's an obvious solution using DH: Alice has a private key $a$ and a public key $g^a$; Bob has a private key $b$ and a public key $g^b$.
When Bob sends a message, he computes the shared secret value $(g^a)^b$, converts that into a MAC key (possibly using a nonce to prevent key reuse), computes the MAC of the message, and sends the message and the MAC ...
8
No, you are not leaking any information except how to MAC those specific values with the specific key you are using. Using a short message is exactly as secure as using a long message.
For the following, remember the definition HMAC (K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)). There are two hashes here, an outer hash and an inner hash nested inside the ...
7
No, RC4 is not completely broken. It is possible to use it properly. It's just not very likely that an average developer will do so.
RC4 is not a good choice for new systems. It is tricky to use properly. There are some serious pitfalls which, if you're not an expert cryptographer, can bite you in the butt. In fact, if you take a quick look in the ...
6
If this is simply the AES permutation on a single block, it's hard to find such a pair.
If it's AES-ECB with multiple blocks, you can pick each block from either (x1,y1) or (x2,y2), producing a new message that contains parts from each of them.
With other modes it depends on that mode, but with many modes there will be a similar mixing attack as for ECB.
5
To get non-repudiation, you must have a "proof" which can be used against the signer himself. Symmetric cryptography, by itself, will not help you there, because a cryptographic proof can only come from some "secret" which is under exclusive control of the signer, and the symmetric model assumes that there is a shared secret between two entities. The concept ...
5
The idea that cryptography alone can provide non-repudiation is a myth. I realize it is one that is taught in many crypto textbooks -- but the textbooks are wrong.
See, e.g., my answer here and here.
I could suggest some constructions (e.g., sign the message, append the signature to the message, then encrypt it using an authenticated encryption mode of ...
5
What you describe looks secure to me, but excessively complicated. The following simpler procedure should suffice:
When a password reset token is requested:
Generate a secure random token and save it (or a cryptographic hash of it) in the database, along with a timestamp. Overwrite the previous token, if any.
Send the token to the user by e-mail ...
4
That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue.
I disagree with Polynomial who ...
4
You didn't mention at what level you're hoping for, so I'll provide a few resources, and you can figure out which ones best meet your needs.
UMAC: Fast and secure message authentication. John Black, Shai Halevi, Hugo Krawczyk, Ted Krovetz and Phillip Rogaway, CRYPTO 1999. (This research paper describes UMAC, a fast Carter-Wegman style hash. It also gives ...
4
It's fine, as others have noted.
However, by invoking PBKDF2 twice (first to check the password, then to derive the actual key), you're essentially doubling a legitimate user's workload, whereas an attacker still only needs to run it once for each guessed password. Thus, you're cutting the legitimate user's advantage in half, or, equivalently, wasting one ...
4
The short answer is: They prepend bits in that way because the scheme is not secure without them. While they might not explain it in English, their proof makes it clear where they use it.
Let us construct an attack against the scheme that does not prepend a bit to the blocks. The same idea will work against a version of the scheme that prepends the same ...
4
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 ...
3
Ask the server for the salt for a specific username.
Compute the expensive salted hash on the client, send to server
Server performs a cheap unsalted hash(or HMAC) on the hash received from the client and compares with the stored value
Note that sending a hashed password doesn't mean you can use an insecure transport. You still need proper transport ...
3
What you want is exactly one of the use cases of ring signatures.
A ring signature scheme allows you to choose an ad-hoc group of public keys and compute a signature in such a way, that it could have been created by any holder of one of the corresponding secret keys but by nobody else.
The privacy of the construction from the paper linked above is perfect. ...
3
Yes you can use PBKDF2 for both (from section 3 of this memo)
Another application is password checking, where the output of the key
derivation function is stored (along with the salt and iteration
count) for the purposes of subsequent verification of a password.
Also (as mentioned in the comments of this post), the memo also says (emphasis ...
3
One of the goals of MAC is to detect/avoid message tampering.
Bellare, Canetti and Krawczyk defined 1996 formally: "The adversary sees a sequence $(m_1,a_1),(m_2,a_2),\dots,(m_q,a_q)$ of pairs of messages and tags ... and breaks MAC if she can find $m$ not included among $m_1,m_2,\dots,m_q$" and the corresponding valid tag $a = MAC_k(m)$.
However, you can ...
3
The standard answer in the research literature is to use information-theoretically secure message authentication codes, typically universal hashing (aka Carter-Wegman authenticators). Of course, you could use computationally-secure message authentication codes, like CMAC or HMAC, if you wanted, though that would partly defeat one of the reasons for using ...
3
Let Alice have a key pair (PubKeyA, PrivKeyA), where the first is public, the second private,
and similarly for Bob (PubKeyB, PrivKeyB). Alice and Bob know each other's public keys in a reliable way (from a key server, or because they received them in person etc.)
If we use RSA keys, e.g., then they could use just one pair, so I'll assume this first.
When ...
3
Non-malleability of Scrypt w.r.t. to salt (as well as passphrase) follows from the definition of Scrypt (which simply pass that salt to that input of PBKDF2); the definition of PBKDF2 (which uses the salt followed by a non-malleable encoding of an integer as a massage passed to HMAC_SHA256); the non-malleability of HMAC_SHA256 w.r.t. the message; and perhaps ...
3
With the method below, the server never sees either the password or the key the password decrypts.
To generate a password:
The client generates a new RSA key, encrypts it with the password (using something like PBKDF2 to generate a symmetric key), and hands the server the RSA public key and the encrypted private key.
To Authenticate:
The server sends the ...
3
Without an out-of-band channel, no.
If all Alice has only a public key , she can't tell the difference between Bob's key and Mallory's. Hence Mallory can mount a man in the middle attack.
To prevent this you either need a certificate or a a trusted out of band channel though which you conform the key. The channel could be something that is harder to man ...
2
Something like this should work, right?
There's no reason you have to use sha2, you can use any cryptographic hash function. I just used sha2 everywhere for simplicity.
Server Side
To store the password, store the result of: sha2(sha2(client_salt + password) + server_salt), as well as client and server salts
Client Side
Have the server transmit ...
2
In the common configuration of SSH, the session keys (and a session ID) will be negotiated using the Diffie-Hellman key exchange, and then authenticated by the server, using its private key to sign all the exchanged data (which is then checked by the client).
The public key authentication of the client happens after that, when the actual connection is ...
1
SSL/TLS can be used with a pre-shared secret, which ensures mutual authentication and about all the properties you are looking for. The "raw PSK" cipher suites entail only symmetric cryptography and should be efficient even on very limited platforms. If you want perfect forward secrecy (i.e. protection of the confidentiality of past conversations even if the ...
1
There are no non-repudiation services without using of digital signature.
Or maybe I just need to encrypt (using a plain randomized mode,
provides confidentiality only) then sign the ciphertext+associated
data (which provides integrity, authentication and non-repudiation)?
Yes, it will be enough. Or you can sign, then encrypt to secure information ...
1
I'm guessing the idea is domain separation :
if $F_a$ is a secure PRF then $G^0_a(x)=F_a(0.x)$ and $G^1_a(x)=F_a(1.x)$ are two "independant" PRF. What they're doing here is basically using 2 different PRF for the randomness and the message.
If that protection wasn't there you could use an attacker supplied $r$ to cancel out blocks and then with a pair ...
1
The type of scheme desired here would be Signcryption.
Signcryption fulfills the role of a digital signature while simultaneously encrypting the data. It appears that there are some primitives in Elliptical Curve Cryptograpy which will allow for this.
1
There are two approaches: either using symmetric-key cryptography, or public-key cryptography.
Symmetric-key cryptography. When Bob receives an authentic message that has been authenticated by a key known only to Alice or Bob, Bob can deduce that the message must have come from either Alice or Bob. Therefore, if Bob wants to verify that this message came ...
1
RFC 4226, section 7.5 defines two shared key generation schemes: deterministic and random. I would suggest that you use the deterministic scheme, which only requires the server to store a single "master key":
"Deterministic Generation
A possible strategy is to derive the shared secrets from a master
secret. The master secret will be stored at ...
Only top voted, non community-wiki answers of a minimum length are eligible
