[pycrypto] RSA exportKey question with bcrypt?

[Legrandin]

Hi Kurt,

In the PyCrypto 2.6 release, rsa.exportKey(passphrase='boo') generates
a TDES-encrypted private key, with encryption being done at the PEM
level.

I don't think that behavior should change (e.g. we should not silently
switch to AES or even to the more robust PKCS#8-level encryption).

2013/7/15 Kurt Vogel <kvogel at mdcom.com>:
> And finally a comment/question/complaint :(
>
> If I use protection like this for ex:
>
> export = rsa.exportKey(passphrase='boo', pkcs=8,
> protection='PBKDF2WithHMAC-SHA1AndAES256-CBC')
>
> The exported key looks like this:
>
> -----BEGIN ENCRYPTED PRIVATE KEY-----
> MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo
> MB0GCWCGSAFlAwQBKgQQ2FsezYUEaQLPHxk0z6+R4gSCBNDV++BsvKxxpo6uhUYw
> ...
>
> With export = rsa.exportKey(passphrase='boo'):
>
> -----BEGIN RSA PRIVATE KEY-----
> Proc-Type: 4,ENCRYPTED
> DEK-Info: DES-EDE3-CBC,CE7B6EC598ED0D10
>
> lPMvbYUypG+O4P/LilzGVQqP+6PMbnnLMP6eosyubcBqLtQxvMlvRRqgRu5CDApA
> ...
>
> The logic in exportKey() looks a bit convoluted, is this for some backward
> compatibility issue?  I would expect to see something like this, what
> ssh-key does:
>
> -----BEGIN RSA PRIVATE KEY-----
> Proc-Type: 4,ENCRYPTED
> DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA
>
> oL8O6n5v1S3cgGJIwrzrAq5TQIb7OeolGJpHXiyTUj1iStulgS5vAjkht0cgq53p
> ...
> ..
>
> Thanks,
> Kurt
>
>
> On Sun, Jul 14, 2013 at 11:40 PM, Kurt Vogel <kvogel at mdcom.com> wrote:
>>
>> While I'm on the subject and appears Dwayne is merging in pull requests :)
>>
>> For RSA exportKey() think we could have **kwargs for extra prot_params
>> passed to
>>
>> PKCS8.wrap() like iteration_count and salt size?
>>
>>
>>
>> On Sun, Jul 14, 2013 at 9:34 PM, Kurt Vogel <kvogel at mdcom.com> wrote:
>>>
>>> Hi,
>>>
>>> Do you guys know roughly when this will go in?
>>>
>>> Also with import/export RSA keys can we support bcrypt?
>>>
>>> Does JCA and BouncyCastle use bcrypt, eg:
>>>
>>> 'BcryptWithHMAC-SHA1AndAES256-CBC'
>>>
>>> Thanks,
>>> Kurt
>>>
>>>
>>> On Fri, Jul 5, 2013 at 2:52 AM, Legrandin <helderijs at gmail.com> wrote:
>>> >
>>> > Hi Kurt , thanks a lot for providing feedback. It is much appreciated.
>>> >
>>> > * I guess you refer to camel-casing used for several variables, which
>>> > was due to my preference to stick to ASN.1 naming.
>>> >   I can work on that and make sure flake8 does not complain that much.
>>> >
>>> > * Right. Code evolved at different points in time, and indeed it is
>>> > now hard to follow the path of the 'parameter' value. I will try to
>>> > fix that.
>>> >
>>> > * I used strings like 'PBKDF2WithHMAC-SHA1AndAES128-CBC' because that
>>> > is the style used in JCA and BouncyCastle and a lot of people are
>>> > familiar with it.
>>> >   I am not very clear what the benefit enums might bring? One option I
>>> > considered was the ability to provide 3 independent parameters
>>> >   instead of one (since protection mainly depends on type of KDF, PRF,
>>> > and symmetric cipher) but at the end I guess most
>>> >   uses case are about the desire to protect the private key using a
>>> > password in a strong way, and the ability to tweak the various
>>> > parameters
>>> >   is not that relevant. Plus, exportKey() parameter list becomes to
>>> > long.
>>> >
>>> > * I am really ashamed to admit that I actually have 9 pull requests
>>> > open, not 2 so I am totally giving headaches to the maintainer. :-)
>>> >   It is of course only up to him to decide which features should go
>>> > in; given that he has not much time these days, it is likely that only
>>> >   few features and bugfixes may go into any next release.
>>> >   The release merge window seems to roughly be once per year and I
>>> > find it is natural to have so many outstanding pull requests by now.
>>> >   To my defense, I can only say that the all pull requests cover one
>>> > feature only and that I try to keep them as independent as possible.
>>> >   Most of them apply cleanly to master (e.g. HKDF, CCM, PKCS#8, bug
>>> > fixes, etc).
>>> >   In some cases though, they do depend on an existing pull request (as
>>> > in the case of DSA import/export depending on PKCS8 be applied first),
>>> >   because keeping them separated is honestly too much work for me
>>> > *and* they are indeed extensions of other extensions.
>>> >
>>> > > Hi, I was looking at the pycrypto pull request
>>> > > https://github.com/dlitz/pycrypto/pull/32.  Just a few comments...
>>> > >
>>> > > * For readability can you pep8 format the code?
>>> > > * RSA, for import/export the protection parameter maybe rename to
>>> > > algo or
>>> > > wrap algo?  It evolves from: 'protection' to 'wrap_algo' to 'mode' as
>>> > > it
>>> > > goes down the call stack.
>>> > > * Also maybe make this parameter an enum/value?  Since the long
>>> > > string can
>>> > > be error prone, low level code would need to change anyway if it were
>>> > > either
>>> > > string or int if we support more modes.
>>> > > * And last but not least... I'm new to this email list and not sure
>>> > > how
>>> > > often pull requests are accepted but maybe you could reduce the
>>> > > amount of
>>> > > features going in?  I know you have another one, 51, after this...
>>> > > Maintainer may reluctant to do massive changes all at once?
>>> > >
>>> > > Anyway just ideas...
>>> > > Thanks for your time,
>>> > > Sincerely,
>>> > > Kurt
>>> > >
>>> > _______________________________________________
>>> > pycrypto mailing list
>>> > pycrypto at lists.dlitz.net
>>> > http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>>>
>>
>
>
> _______________________________________________
> pycrypto mailing list
> pycrypto at lists.dlitz.net
> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>