[pycrypto] RSA exportKey question with bcrypt?
kvogel at mdcom.com
Sun Jul 14 23:40:05 PDT 2013
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
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 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
> > > 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
> > > 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 how
> > > often pull requests are accepted but maybe you could reduce the amount
> > > 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