On 10/14/2016 12:39 AM, Police Terror wrote:
> Maybe I wasn't clear enough but I want to use the AES functions to
> encrypt a Bitcoin wallet.

I understood your scenario to be wallet encryption. I'm just providing
the options. Both BIP38 and BIP39 are specifically designed for wallet
encryption.

> I assumed that was their purpose being there (to encrypt the wallet
> stored on the disk).

Yes, but that intent was limited to BIP38/39 wallet encryption. It was
not envisioned that these functions be used to perform block encryption
of arbitrary data (including wallet keys and/or other wallet private
data) outside of these two features. On the other hand there is nothing
precluding the use of these utilities beyond their envisioned scope.

> Forcing the user to use a mnemonic just isn't practical and a
> passphrase is standard for Bitcoin wallets.

Using a key secured by either BIP398/39 is subject to the security
assumptions and tradeoffs of the respective designs (some of which I
described below).

> Reading here though it says I need to use a "password-based key
> derivation functions", and I noticed the pkcs5_pbkdf2_hmac_sha512()
> function....
> I noticed from BIP39 that iterations is set by default to 2048, so
> I'll use that as an iterations value.
>
> Have you thought about making that a default argument for that
> function? Can we do that?

When it comes to encryption parameters I would prefer selection to be
explicit. This doesn't place a high burden on the developer, but it
requires that they develop some understanding of the tradeoffs of the
various options. In the case of BIP39 iteration is a matter of
specification.

e

> Eric Voskuil:
>> IANAC and this is definitely that requires a rigorous analysis which
I personally cannot provide.
>>
>> Presumably your intent is to store the secret under a passphrase
recovery scheme, using the secret to encrypt a block of private data. So
the encrypted passphrase and the block cypher text are both presumed to
be accessible to the attacker.
>>
>> Key recovery requires a secure environment, otherwise a resident
attacker (e.g. key logger) can simply recover the passphrase, or a more
sophisticated attacker can monitor process memory (assuming insufficient
process-level isolation) to do the same. So I'll assume that your threat
model excludes a compromised environment and is instead focused on
securing the block plain text against theft of the static environment.
>>
>> In this case I would recommend you use the bip39 mechanism for
generating the secret. In this case you need not store the encrypted
secret, you simply derive it from the passphrase (mnemonic) at each use.
>>
>> This offers the substantial benefit of preventing the user from
generating a weak passphrase. It does however rely on a trustworthy RNG
(again, under the assumption of an uncompromised platform use of the
platform RNG is probably fine).
>>
>> If on the other hand you must allow the user to select a passphrase
(or you must use an existing 256 bit secret) then you would use bip38
key encryption. Key generation is of course subject to the same RNG caveats.
>>
>> You could use bip39 to generate both the wallet seed(s) and the AES
encryption key, from the same mnemonic.
>>
>> To satisfy the threat scenario you also need to consider the
possibility (likelihood) of insecure memory usage. The mnemonic, key, or
the entire block of clear text may become cached on disk (for example)
as a consequence of the platform's virtual memory implementation. This
would be vulnerable to static analysis. Use of secure memory primitives
for anything that touches a secret is therefore a must.
>>
>> e
>>
>>> On Oct 13, 2016, at 10:31 AM, Police Terror <PoliceTerror@???>
wrote:
>>>
>>> So libbitcoin defines the 2 functions aes256_encrypt() and
aes256_decrypt().
>>>
>>> It uses a 32 byte secret and 16 byte block size.
>>>
>>> If I want to encrypt 5000 bytes, then I have encrypt it as 313 blocks
>>> which is 5008 bytes right?
>>>
>>> How can I add a password to this? Can I simply do this?
>>>
>>> secret = bitcoin_hash("mypassphrase123")
>>>
>>> Or should I use the scrypt function instead? How can I use that?