# Tag Info

2

Essentially, instead of checking against a (salted) hash of a password, you suggest using the hash (since you can choose hashing = keygen) as a key to encrypt a kind of test value. The main question is whether this adds or reduces security. If you store the hash/key directly, the chance of a randomly chosen password hashing to the same value is $2^{-n}$, ...

0

Your proposal is not good. First, the checking procedure is wrong: Checking password validity: calculating test_hash=cipher(test_password+salt) for a given test_key=keygen(test_password+salt) check if test_hash consisting only symbols/bytes of predefined dictionary (...) I guess you meant: calculating test_phrase=decipher(hash) with ...

1

in diffie-hellman key exchange algorithm vulnerability's is good defined by RSA lab : "The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it to ...

3

No, it is not safe to authenticate the BIOS in that way. CRC should be used as checksum only, i.e. to avoid random bit flips. For larger random changes you should use CRC32 at the minimum. If you want to protect against malicious change you need a cryptographically secure hash. the reason for this is that any attacker can create a malicious BIOS that ...

0

I think the idea is good - it is pretty much what Lastpass does (see below). But as with anything to do with cryptography every detail matters. If you're using email for the client salt it seems like a good idea to run the email through PBKDF2 first to ensure sufficient entropy. encryption_key = PBKDF2(HMAC-SHA256, password, client-salt, rounds) // decrypts ...

0

Just to make sure I'm on the same page about the details: So, there's a master key, presumably randomly generated in the client, never shown to the server, call it $k_m$. Then there's an encryption key, derived from a user passphrase and a (random) salt: $$k_e = \operatorname{PBKDF2}(p, s)$$ There's also an authentication key, derived from the same ...

1

This is far from secure, assuming a passphrase that a human can remember. The main thing you have to note is that an offline brute force attack on the password can be carried out. This is because the server can guess the password and follow the same procedure and see if decryption works. It is possible to buy a machine that computes billions of hashes a ...

2

Answering the question in your title (and not addressing your proposed alternative which I don't quite understand) there is a zero knowledge proof of password protocol "SRP" which is fast and effective. SRP does not seem to have been given as wide publicity as it should get. Having implemented it, and being an advocate of its use, I don't really understand ...

1

I'll first assume $\phi$ is known, which would be the situation in RSA at key selection. A common method could be to select (odd) $\mu$ at random in some appropriate interval until $\gcd(\mu,\phi)=1$ is satisfied. In the context of RSA, it is fine (if we ignore performance an interoperability issues) to choose an RSA exponent at random in $[3\dots\phi-3]$ ...

2

I am a little confused about why it is believed to be secure against quantum attacks, couldn't the hash function be attacked? Yes, the attacker could attack the hash function, for example, by trying to find a second preimage (and there are known Merkle Signature Schemes where we can show that forging a signature can be reduced to the second preimage ...

0

There is multiple solutions that's more sophisticated than this one. But you could easy authenticate the user if you have a secret that both the server and the client knows. By using the HMAC protocol example: SHA256 ( SHA256 ( data_before_encryption ) + secret ) You create a hash of the the data you are sending before you encrypt it, and then you append ...

1

if you want to use a password, SRP is probably a good choice. alternatively, you could use ECDHE with ECDSA or RSA keys. you should also use a MAC of some sort if you're using CBC (and encrypt then MAC). GCM or OCB would be much better choices.

2

Yes, that is a problem. There are protocols like SRP that both eliminate the need for Bob to store the password in plaintext and prevent replay attacks.

7

ECC is indeed used by CloudFlare's website but only for the session key agreement. The authentication is performed using an RSA 2048 bit private key. The corresponding RSA public key is in the certificate. In other words, although ECC is being used, it is not used for authentication and therefore not part of the certificate. The ciphersuite is: ...

Top 50 recent answers are included