Tag Info

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

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

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

2

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

2

What you are describing is called $(t,n)$-threshold signature, where you need at least $t$ parties (out of a total of $n$) to create a signature. Considering your description, it seems that in your case $t=n$, so it is necessary that all the keys are used for creating the signature. This answer assumes that you want to verify the signature with a single ...

2

It is very bad practice to use the same private key for two different schemes. In some cases this is secure but you need to explicitly prove it. One example of this can be seen here: http://www.pinkas.net/PAPERS/combined.ps. My suggestion is to take the Cramer-Shoup group and to define a separate key pair for DSA or Schnorr signatures. You can use the ...

2

So your idea is to effectively turn the password authentication into a key-based authentication by deriving the machine passwords from a single random key stored elsewhere. Assuming key storage is secure (probably encrypted with a strong password), this is sound. It would be better to just use the asymmetric key-based authentication built into most remote ...

1

$\;\;\;$ Sure. $\:$ The simplest way is to OTP-encrypt the $\;\;\;$ output of an almost xor-universal hash family. $\;\;\;$ That could be used for encrypt-then-MAC, where $\;\;\;$ the MAC is applied to an ordered pair that indicates $\;\;\;$ [the message number or how far into the pad to start] and the OTP ciphertext. $\;\;\;$ (Presumably, the pairing ...

1

Use AES-OCB. It is patented, but now has a free license for any non-military software use. Unlike most other CAESAR candidates, OCB has been scrutinized for a while now, and meets all of your criteria other than 6 (assuming you have a good AES implementation). If the patent is simply too much for you, then use a heavily scrutinized patent-free tweakable ...

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

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