BIP 38 - Clarify AES parameters passed in #72

1. 
   ricmoo commented at 6:20 pm on June 9, 2014: contributor

   There was some slight ambiguity in which items passed into AESEncrypt was the key and which was the block.
2. Clarify AES parameters passed in

   There was some slight ambiguity in which items passed into AESEncrypt was the key and which was the block.

   e33c834cf5
3. ricmoo renamed this:
   Clarify AES parameters passed in
   BIP 38 - Clarify AES parameters passed in
   on Jun 10, 2014
4. 
   shea256 commented at 8:02 pm on July 25, 2014: contributor

   @midnightlightning @telepathic @wozz @laanwj @ricmoo saw you were the ones who made commits on BIP38, so just wanted to ask you a few questions:

   1. Do any of you know what AES mode is used in BIP38? It seems like the implementations I’ve looked at use ECB mode but ECB mode is only supposed to be used when you encrypt a single block, and in BIP38 there are two halves that need to be encrypted.
   2. I’ve heard there has been some controversy about BIP38. It seems to be quite popular across wallets but some of the core devs have been very outspoken about BIP38 not following the standard review practices. What is the consensus regarding BIP38? Would you consider it to be a recommended method of encrypting private keys? Or would you suggest simple AES encryption with massive key stretching?
   3. Is the lack of initialization vectors here really OK?
   4. Why is BIP38 so complicated? Isn’t there a simpler way to accomplish the same thing?
5. 
   ricmoo commented at 8:42 pm on July 25, 2014: contributor

   1. It does not use any of the common modes, but uses the AES block cipher directly, with a sort of one-time pad (derived from the scrypt pbkdf) applied; so it is more of a custom mode of operation
   2. When I brought up a suggestion for BIP38, I was sent to https://bitcointalk.org/index.php?topic=258678.0 . That said, it seems bip38 has a moderate level of adoption; but someone with more knowledge of the politics should answer this.
   3. You can think of the one-time pad derived from the scrypt pbkdf as a form of IV. However, take a look at the CTR (counter) common mode of operation (which is a recommended mode) to see an example where the lack of an IV is OK.
   4. I will be posting my implementation of a BIP38 wallet soon, and it is actually quite straight forward, with only 26 lines of code to encrypt an address and around the same for encryption. The code is much easier and concise to read than English, it did take some time fiddling to get the code and the English to match, but it really sounds more complicated than it really is. :)
6. 
   shea256 commented at 9:02 pm on July 25, 2014: contributor

   1. What do you mean by this? As far as I understand, the default AES mode is ECB. At least that’s the case with pycrypto’s AES libarary.
   2. OK. I think @gmaxwell was the one who was most vocally against the process employed here.
   3. Hm, well have you checked out this? http://stackoverflow.com/a/1220779/1530754.
   4. That would be nice, thanks.

   Any thoughts on this implementation? https://github.com/bpdavenport/btc/blob/master/bip38.py Seems to be easier to read than some of the others.

7. 
   ricmoo commented at 9:57 pm on July 25, 2014: contributor

   1. A mode of operation can be thought of as “a way to use a block cipher”… There is no need to necessarily use the AES block cipher, you could use any block cipher. So, it is important to distinguish between a block cipher and a mode of operation; both are interchangeable.

   A block cipher, by itself is simply an algorithm that takes in a key and a block, and returns a new block, in a reversible way. ECB is a mode of operation which does nothing beyond pass its bytes directly through to the underlying block cipher, so it can “kinda” be thought of as the default behaviour.

   The PyCrypto AES Block Cipher is the class: Crypto.Cipher.AES.AESCipher The PyCrypto AES Modeof Operation is: Crypto.Cipher.AES.MODE_ECB

   They will both return the same result, as ECB is the trivial layer on top of the block cipher.

   The idea of an initialization vector is specific to certain modes of operation (usually to bootstrap feedback).

   You can check out my implementation at https://github.com/ricmoo/pyaes/blob/master/pyaes/aes.py

   Line 95-269 cover the AES block cipher algorithm. Below is each of the common modes of operation; as you can see each in only at most a dozen or so lines of code to cleverly use the block cipher for more interesting purposes.

   More interesting, you will see that the CTR (counter) and OFB (output feedback) modes use their encrypt() method to decrypt, as they are symmetric.

8. 
   ricmoo commented at 10:21 pm on July 25, 2014: contributor

   1. For the concerns here, you can think of the first 32 bytes of the scrypt pbkdf as an IV, or implicit feedback based on the key… I will think more about this though… Off the top of my head, I wonder if it would be weak against two keys with the same 4-byte prefix of their sha256d (ie. what becomes the salt) and also protected with the same password, as the pbkdf would return the same one-time pad.

   Seems like the chances are low, but birthday problem a couple thousand addresses with the same password and it may become an issue… May not be an issue… thinking

9. 
   ricmoo commented at 4:56 am on July 26, 2014: contributor

   (that last 1 was supposed to be 3… Seems github automatically turns numbers into number lists, starting at 1)

   That said, for 3, I think because the OTP is applied before the block cipher encrypt, that it is actually not an issue, as it behaves more like an IV. I have spent a few hours trying to exploit it, and haven’t found anything meaningful; I’m still open to people smarter than I to try though. Here are some test vectors, each set is a pair of keys that produce the same salt, so if encrypted with the same password, will have the same scrypt pbkdf derived components:

   a) 5JJ4qiuny4jZheGy5BcFmkkrfQBBbsrabQAxBVmmqvLPj2p9DPu 5Kcicw7Lgu5rt2ywLNnx54hXrHEWnyygf5GW1nKfDErk1BxxxXR

   b) 5KBwzUEWPNepAEMabpTyLdGQ8wVXQchZtTRiT7Q32Z8V1WGm9pH 5JCMEW9FpjDT9ESHvhE6bDVTxQCyZYNd31Kh5WM9uQU877FP65y

   c) 5JvaJrRgU6c3LifUcdYvhu21Y6XmbzwFr9gzL5nM4NUezmkjwLf 5JKzgnLPspteLdjDNytakdevaDkUgSsGqJmQV2xWUeBxf8ckvHj

   d) 5KjaZxcRe9dPCpWhYMZR8PrCfUAVGChwt7UTNKRdg2bwaALndbn 5K2FKeDN2yX3DV2DXTzoGpUNVz6QSMhjEapPQqQrmYxydes3sTH

10. 
    ricmoo commented at 9:25 pm on September 5, 2014: contributor

    Regarding point 4, here is my Python implementation of BIP38…

    https://github.com/ricmoo/pycoind/blob/master/pycoind/wallet/address.py

    At the time, I had not implemented EC-multiply addresses. After implementing them, it does indeed seem a tad complicated. :)

11. laanwj referenced this in commit 666bbf3c4a on Oct 15, 2014
12. laanwj merged this on Oct 15, 2014
13. laanwj closed this on Oct 15, 2014

    ---

14. ajtowns referenced this in commit 2d2e268ee8 on Sep 25, 2019
15. ysangkok cross-referenced this on Aug 21, 2020 from issue Reject 38 (expired) by ysangkok
16. real-or-random referenced this in commit 836f9e0023 on Feb 23, 2023

Contributors
ricmoo shea256