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