And finally a comment/question/complaint :(<div><br></div><div>If I use protection like this for ex:</div><div>







<p class="p1"><span class="Apple-tab-span">     </span>export = rsa.exportKey(passphrase=<span class="s1">'boo'</span>, pkcs=<span class="s2">8</span>, protection=<span class="s1">'PBKDF2WithHMAC-SHA1AndAES256-CBC'</span>)</p>
<p class="p1">The exported key looks like this:</p></div><div><div>-----BEGIN ENCRYPTED PRIVATE KEY-----</div><div>MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo</div><div>MB0GCWCGSAFlAwQBKgQQ2FsezYUEaQLPHxk0z6+R4gSCBNDV++BsvKxxpo6uhUYw</div>
<div>...</div><div><br></div><div>With export = rsa.exportKey(passphrase=<span class="s1">'boo'):</span></div><div><br></div><div><div>-----BEGIN RSA PRIVATE KEY-----</div><div>Proc-Type: 4,ENCRYPTED</div><div>DEK-Info: DES-EDE3-CBC,CE7B6EC598ED0D10</div>
<div><br></div><div>lPMvbYUypG+O4P/LilzGVQqP+6PMbnnLMP6eosyubcBqLtQxvMlvRRqgRu5CDApA</div></div><div>...</div><div><br></div><div>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:</div>
<div><br></div><div><div>-----BEGIN RSA PRIVATE KEY-----</div><div>Proc-Type: 4,ENCRYPTED</div><div>DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA</div><div><br></div><div>oL8O6n5v1S3cgGJIwrzrAq5TQIb7OeolGJpHXiyTUj1iStulgS5vAjkht0cgq53p</div>
<div>...</div></div><div>..</div><div><br></div><div>Thanks,</div><div>Kurt</div><div><br></div><br><div class="gmail_quote">On Sun, Jul 14, 2013 at 11:40 PM, Kurt Vogel <span dir="ltr"><<a href="mailto:kvogel@mdcom.com" target="_blank">kvogel@mdcom.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While I'm on the subject and appears Dwayne is merging in pull requests :)<div><br></div><div>For RSA exportKey() think we could have **kwargs for extra prot_params passed to 







<p>PKCS8.wrap() like iteration_count and salt size?</p><p><br></p>







<br><div class="gmail_quote">On Sun, Jul 14, 2013 at 9:34 PM, Kurt Vogel <span dir="ltr"><<a href="mailto:kvogel@mdcom.com" target="_blank">kvogel@mdcom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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" target="_blank">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" target="_blank">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" target="_blank">pycrypto@lists.dlitz.net</a><br>> <a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a><br>


<br>
</blockquote></div><br></div>
</blockquote></div><br></div>