# Tag Info

0

There is no way to generate a secure key-pair from the password "puppies". If you are using a 256-bit elliptic curve and want the full 128-bit security it can offer, any password from which you directly derive a key needs to have over 100 bits of entropy. If you use a key derivation function, like PBKDF2 or scrypt, with parameters that require a few seconds ...

4

Given a EC public key, can a different, but plausible and functional private key be derived to match the public key? No, a public key will correspond to only one private key (with one minor exception, which I will explain below). With Elliptic Curve systems, the private key is an integer $d$ between 1 and $q$ (the order the generator point $G$), and ...

0

Could Eve capture Bob's public key, then derive some different private key to correspond to it, and then impersonate Bob by saying "I am Bob, and here's my public key." Even though Eve doesn't have Bob's private key, she's able to produce some other private key that's compatible with Bob's public key? No, not unless the public key system is broken. In ...

0

I obviously don't understand the mathematics behind ECC, but I am quite certain that the mentioned Multiply is not as simple as regular multiplication, nor as simple as wrapping around a finite field many times over. Because: When Alice and Bob exchange ECDH public keys, and then they each do DeriveKeyMaterial() or CalculateAgreement(), the result is ...

0

Please see https://cbcrypt.org specifically https://cbcrypt.org/doku.php#documentation_and_api. There is a method CBCrypt.GenerateKeyPair(string CBCryptHostId, string username, string password) created specifically for this purpose. This does not relate specifically to BitCoin, but if you start with something like a password, salt it with details of where ...

5

I agree with the comments that SHA-256 should be fine here. However, if you already use HMAC-SHA-256 for PBKDF2, you could use HKDF Expand, which despite its name is defined even for output lengths shorter than input. In your case the output would be simply: $$\operatorname{HMAC-SHA-256}(\text{key}, \text{info} || \text{0x01}),$$ where 'info' is an ...

0

Either is fine. If you're not concerned about database size or the size of transmitted keys, it doesn't matter which you choose. They are both secure. Choose whichever is more convenient, or easier to implement, or easier for others to interoperate with, or whatever other (non-security) criteria you might have.

2

If you are concerned about database size, only the master key needs to be stored when you use HKDF. Ditto when sending it to another computer. Otherwise, two independent random keys are clearly secure and simpler to implement, so you should do that.

2

Is it subject to some class of attacks or is it just a really bad crypto nightmare which is only subject to brute-force attacks? You are calculating PBKDF2 twice, which takes twice as long. An attacker doing a brute force or dictionary attack only needs to calculate one of them to verify his guesses. That means you are making attacks twice as easy as ...

1

If you are certain that SecureRandom is a trusted, verified CSPRNG you can use that without HKDF without problems.

Top 50 recent answers are included