[pycrypto] RSA exportKey question with bcrypt?
kvogel at mdcom.com
Mon Jul 15 00:26:45 PDT 2013
And finally a comment/question/complaint :(
If I use protection like this for ex:
export = rsa.exportKey(passphrase='boo', pkcs=8, protection=
The exported key looks like this:
-----BEGIN ENCRYPTED PRIVATE KEY-----
With export = rsa.exportKey(passphrase='boo'):
-----BEGIN RSA PRIVATE KEY-----
The logic in exportKey() looks a bit convoluted, is this for some backward
compatibility issue? I would expect to see something like this, what
-----BEGIN RSA PRIVATE KEY-----
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:
>> 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:
>> 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
>> > * 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
>> > > 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
>> > > string or int if we support more modes.
>> > > * And last but not least... I'm new to this email list and not sure
>> > > 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...
More information about the pycrypto