[pycrypto] RSA exportKey question with bcrypt?

[Kurt Vogel]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dlitz.net/pipermail/pycrypto/attachments/20130715/670efb00/attachment-0001.html>