# Tag Info

3

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

-1

This link seems to give sufficient insight:

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

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

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

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

Top 50 recent answers are included