<div><br></div>Understood, but the format of the export changes when we add 'protection' parameter.<div>Can we keep same format and have different headers, ex:</div><div><br></div><div>> Proc-Type: 4,ENCRYPTED<br>
> DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA<br><br>Because I notice we wrap the unencrypted PEM into a PBES2 which is encrypted there.  </div><div><br></div><div>Also maybe more importantly would be the extra parameters for salt size and iteration count?</div>
<div><br></div><div>An afterthought, maybe it's time exportKey(), importKey() stay the same as 2.6 and have new functions that allow these extra combinations?  </div><div><br></div><div>Thanks,</div><div>Kurt</div><div>
<br><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 2:26 AM, Legrandin <span dir="ltr"><<a href="mailto:helderijs@gmail.com" target="_blank">helderijs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kurt,<br>
<br>
In the PyCrypto 2.6 release, rsa.exportKey(passphrase='boo') generates<br>
a TDES-encrypted private key, with encryption being done at the PEM<br>
level.<br>
<br>
I don't think that behavior should change (e.g. we should not silently<br>
switch to AES or even to the more robust PKCS#8-level encryption).<br>
<br>
2013/7/15 Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>>:<br>
> And finally a comment/question/complaint :(<br>
><br>
> If I use protection like this for ex:<br>
><br>
> export = rsa.exportKey(passphrase='boo', pkcs=8,<br>
> protection='PBKDF2WithHMAC-SHA1AndAES256-CBC')<br>
><br>
> The exported key looks like this:<br>
><br>
> -----BEGIN ENCRYPTED PRIVATE KEY-----<br>
> MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo<br>
> MB0GCWCGSAFlAwQBKgQQ2FsezYUEaQLPHxk0z6+R4gSCBNDV++BsvKxxpo6uhUYw<br>
> ...<br>
><br>
> With export = rsa.exportKey(passphrase='boo'):<br>
><br>
> -----BEGIN RSA PRIVATE KEY-----<br>
> Proc-Type: 4,ENCRYPTED<br>
> DEK-Info: DES-EDE3-CBC,CE7B6EC598ED0D10<br>
><br>
> lPMvbYUypG+O4P/LilzGVQqP+6PMbnnLMP6eosyubcBqLtQxvMlvRRqgRu5CDApA<br>
> ...<br>
><br>
> The logic in exportKey() looks a bit convoluted, is this for some backward<br>
> compatibility issue?  I would expect to see something like this, what<br>
> ssh-key does:<br>
><br>
> -----BEGIN RSA PRIVATE KEY-----<br>
> Proc-Type: 4,ENCRYPTED<br>
> DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA<br>
><br>
> oL8O6n5v1S3cgGJIwrzrAq5TQIb7OeolGJpHXiyTUj1iStulgS5vAjkht0cgq53p<br>
> ...<br>
> ..<br>
><br>
> Thanks,<br>
> Kurt<br>
><br>
><br>
> On Sun, Jul 14, 2013 at 11:40 PM, Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>> wrote:<br>
>><br>
>> While I'm on the subject and appears Dwayne is merging in pull requests :)<br>
>><br>
>> For RSA exportKey() think we could have **kwargs for extra prot_params<br>
>> passed to<br>
>><br>
>> PKCS8.wrap() like iteration_count and salt size?<br>
>><br>
>><br>
>><br>
>> On Sun, Jul 14, 2013 at 9:34 PM, Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>> wrote:<br>
>>><br>
>>> 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>
>>> 'BcryptWithHMAC-SHA1AndAES256-CBC'<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<br>
>>> > 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<br>
>>> > 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<br>
>>> > > algo or<br>
>>> > > wrap algo?  It evolves from: 'protection' to 'wrap_algo' to 'mode' as<br>
>>> > > it<br>
>>> > > goes down the call stack.<br>
>>> > > * Also maybe make this parameter an enum/value?  Since the long<br>
>>> > > string can<br>
>>> > > be error prone, low level code would need to change anyway if it were<br>
>>> > > 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<br>
>>> > > how<br>
>>> > > often pull requests are accepted but maybe you could reduce the<br>
>>> > > 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" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a><br>
>>><br>
>><br>
><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" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a><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" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a><br>
</blockquote></div><br></div>