# Tag Info

1

There's really two things to consider here: Entropy. Assuming that the hash function in question maps exactly the same number $2^{n-k}$ of bit strings of length $n$ to each hash output of length $k\leq n$, then fixing $l\leq k$ bits of the hash reduces the set of possible choices for the input from $\{0,1\}^n$ to some subset $S\subseteq\{0,1\}^n$ of ...

3

From the linked page, a minikey is a 30-character string over the base58 alphabet with the first byte fixed to 'S', so effectively 29 characters. This gives a space of $log_2(58^{29}) \approx 169.88$ bits. Assuming that SHA is a random function, the probability of the hash starting with an 0-byte after appending a ? is 1/256, so this check loses 8 bits of ...

0

Yes, it's fine. However, you might as well use HKDF-Expand (with your counter as the context information 'info'), so that if you later need some session keys to be larger than 256 bits, the extension is already defined for you. So, $$sk_1 = HMAC(mk, 1 || 0x01)\\ sk_2 = HMAC(mk, 2 || 0x01)\\ ...$$ And if you need a 512-bit $sk_3$ that's: sk_3 = HMAC(mk, ...

0

Is this approach (deriving a password from a signature) cryptographically sound? Not in general. There are signature algorithms that are completely deterministic and signature algorithms that aren't. With the latter kind you would be unable to reproduce the password later. With a deterministic algorithm, yes, the basic idea of using the signature as a ...

0

First, there is a non-security argument in favor of option 2.: if you can cache the AES key across key exchanges, you can save time in key setup. Whether that's relevant I'll leave for you to decide. CTR fails when the same key-input pair is used twice. Let's first assume the nonces $N_a$ and $N_b$ are always unique, and that key derivation and mixing is ...

Top 50 recent answers are included