<div><br></div>Gotcha, thanks for the updated information.<div>Didn't know PEM level encryption is best avoided and being phased out</div><div><div><br></div><div>So ignore comment on additional function names, but add **kwargs to exportKey()</div>
<div>to support iteration count and salt size for protection types allowing those arguments?</div><div><br></div><div>And if I didn't mention already thanks for all the work on this, there is a lot..</div><div>Kurt</div>
<div><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 1:52 PM, 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>
I hope I understand correctly this time.<br>
The presence of a header like:<br>
<br>
-----BEGIN RSA PRIVATE KEY-----<br>
Proc-Type: 4,ENCRYPTED<br>
DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA<br>
[...]<br>
<br>
indicates that the PEM envelope is encrypted and that the inner PKCS#8<br>
structure is clear.<br>
<br>
A header like:<br>
<br>
-----BEGIN ENCRYPTED PRIVATE KEY-----<br>
MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo<br>
[...]<br>
<br>
indicates the opposite: the PEM envelope is clear and the inner PKCS#8<br>
structure is encrypted. That was produced by a call like:<br>
<br>
>> rsa.exportKey(passphrase='boo', pkcs=8,<br>
protection='PBKDF2WithHMAC-SHA1AndAES256-CBC')<br>
<br>
I don't think you can have both PKCS#8-level encryption (with all its<br>
nice properties, like ability to fine tune the algorithms and so on)<br>
and nice human-readable headers in the PEM envelope (like DEK-Info)<br>
describing the type of encryption that was performed.That would<br>
totally confuse the receiver...<br>
<br>
It' also worth streessing that PEM-level encryption is not really<br>
specified anywhere other than in very old RFCs like RFC 1421, which<br>
only define DES as algorithm and no password key derivation. Nowadays,<br>
PEM-level encryption is best avoided, even if that means that the only<br>
hint that the key is encrypted is the generic "BEGIN ENCRYPTED PRIVATE<br>
KEY" line.<br>
<br>
As described in the docstrings, specifying the 'protection' parameter<br>
automatically implies<br>
PKCS#8-level encryption, so the change of export format is actually<br>
done on purpose.<br>
<br>
> Also maybe more importantly would be the extra parameters for salt size and<br>
> iteration count?<br>
<br>
I agree it would be a nice addition (along with some support for bcrypt/scrypt).<br>
<br>
> An afterthought, maybe it's time exportKey(), importKey() stay the same as<br>
> 2.6 and have new functions that allow these extra combinations?<br>
<br>
Which extra combinations? Salt size and iteration count you mean?<br>
They could be passed as a dictionary, since they are<br>
algorithm-specific parameters.<br>
<br>
2013/7/15 Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>>:<br>
><br>
> Understood, but the format of the export changes when we add 'protection'<br>
> parameter.<br>
> Can we keep same format and have different headers, ex:<br>
><br>
>> 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<br>
> there.<br>
><br>
> Also maybe more importantly would be the extra parameters for salt size and<br>
> iteration count?<br>
><br>
> An afterthought, maybe it's time exportKey(), importKey() stay the same as<br>
> 2.6 and have new functions that allow these extra combinations?<br>
><br>
> Thanks,<br>
> Kurt<br>
><br>
><br>
><br>
> On Mon, Jul 15, 2013 at 2:26 AM, Legrandin <<a href="mailto:helderijs@gmail.com">helderijs@gmail.com</a>> wrote:<br>
>><br>
>> 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<br>
>> > 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>
>> >><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<br>
>> >>> > appreciated.<br>
>> >>> ><br>
>> >>> > * I guess you refer to camel-casing used for several variables,<br>
>> >>> > 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<br>
>> >>> > 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<br>
>> >>> > 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<br>
>> >>> > I<br>
>> >>> > considered was the ability to provide 3 independent parameters<br>
>> >>> > instead of one (since protection mainly depends on type of KDF,<br>
>> >>> > 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<br>
>> >>> > 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<br>
>> >>> > (as<br>
>> >>> > in the case of DSA import/export depending on PKCS8 be applied<br>
>> >>> > 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'<br>
>> >>> > > 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<br>
>> >>> > > 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<br>
>> >>> > > 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>
><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></div>