Maybe I wasn't clear enough but I want to use the AES functions to
encrypt a Bitcoin wallet. I assumed that was their purpose being there
(to encrypt the wallet stored on the disk).

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

Reading here though it says I need to use a "password-based key
derivation functions", and I noticed the pkcs5_pbkdf2_hmac_sha512()
function.

https://stackoverflow.com/questions/19862691/using-sha-1-hash-as-aes-key

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?

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?
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin