delta/python-packages/pycrypto.git - github.com: dlitz/pycrypto.git

diff options


context:
space:
mode:

Diffstat (limited to 'pipermail/pycrypto/attachments/20130717/5b8cab35/attachment-0001.html')

-rw-r--r--

pipermail/pycrypto/attachments/20130717/5b8cab35/attachment-0001.html

273

1 files changed, 273 insertions, 0 deletions

diff --git a/pipermail/pycrypto/attachments/20130717/5b8cab35/attachment-0001.html b/pipermail/pycrypto/attachments/20130717/5b8cab35/attachment-0001.html
new file mode 100644
index 0000000..a65230c
--- /dev/null
+++ b/pipermail/pycrypto/attachments/20130717/5b8cab35/attachment-0001.html

@@ -0,0 +1,273 @@

+<tt>

+Hi, quick question for the group and maintainer...<div> </div><div>I am about ready to deploy a project and wondering how set we are on the format of rsa.exportKey() for next pycrypto?</div><div> </div><div>Is it safe to include in our requirements.pip (for now) a reference to <a href="https://github.com/dlitz/pycrypto">https://github.com/dlitz/pycrypto</a> master branch?  And export my keys with the new protection scheme?  And consequently matching importKey().</div>

+<div> </div><div>It would be super nice if we could add **kwargs for iteration_count and salt_size to export() but beggars can't be choosers :)  It seems a simple enough change and looks like importKey() reads those fields in, I'd do it myself but would like any thoughts/opinions?</div>

+<div> </div><div>Thanks,</div><div>Kurt</div><div> </div><div> <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>> wrote:

+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kurt,

+

+I hope I understand correctly this time.

+The presence of a header like:

+

+-----BEGIN RSA PRIVATE KEY-----

+Proc-Type: 4,ENCRYPTED

+DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA

+[...]

+

+indicates that the PEM envelope is encrypted and that the inner PKCS#8

+structure is clear.

+

+A header like:

+

+-----BEGIN ENCRYPTED PRIVATE KEY-----

+MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo

+[...]

+

+indicates the opposite: the PEM envelope is clear and the inner PKCS#8

+structure is encrypted. That was produced by a call like:

+

+    >> rsa.exportKey(passphrase='boo', pkcs=8,

+protection='PBKDF2WithHMAC-SHA1AndAES256-CBC')

+

+I don't think you can have both PKCS#8-level encryption (with all its

+nice properties, like ability to fine tune the algorithms and so on)

+and nice human-readable headers in the PEM envelope (like DEK-Info)

+describing the type of encryption that was performed.That would

+totally confuse the receiver...

+

+It' also worth streessing that PEM-level encryption is not really

+specified anywhere other than in very old RFCs like RFC 1421, which

+only define DES as algorithm and no password key derivation. Nowadays,

+PEM-level encryption is best avoided, even if that means that the only

+hint that the key is encrypted is the generic "BEGIN ENCRYPTED PRIVATE

+KEY" line.

+

+As described in the docstrings, specifying the 'protection' parameter

+automatically implies

+PKCS#8-level encryption, so the change of export format is actually

+done on purpose.

+

+> Also maybe more importantly would be the extra parameters for salt size and

+> iteration count?

+

+I agree it would be a nice addition (along with some support for bcrypt/scrypt).

+

+> An afterthought, maybe it's time exportKey(), importKey() stay the same as

+> 2.6 and have new functions that allow these extra combinations?

+

+Which extra combinations? Salt size and iteration count you mean?

+They could be passed as a dictionary, since they are

+algorithm-specific parameters.

+

+2013/7/15 Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>>:

+>

+> Understood, but the format of the export changes when we add 'protection'

+> parameter.

+> Can we keep same format and have different headers, ex:

+>

+>> Proc-Type: 4,ENCRYPTED

+>> DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA

+>

+> Because I notice we wrap the unencrypted PEM into a PBES2 which is encrypted

+> there.

+>

+> Also maybe more importantly would be the extra parameters for salt size and

+> iteration count?

+>

+> An afterthought, maybe it's time exportKey(), importKey() stay the same as

+> 2.6 and have new functions that allow these extra combinations?

+>

+> Thanks,

+> Kurt

+>

+> On Mon, Jul 15, 2013 at 2:26 AM, Legrandin <<a href="mailto:helderijs@gmail.com">helderijs@gmail.com</a>> wrote:

+>>

+>> Hi Kurt,

+>>

+>> In the PyCrypto 2.6 release, rsa.exportKey(passphrase='boo') generates

+>> a TDES-encrypted private key, with encryption being done at the PEM

+>> level.

+>>

+>> I don't think that behavior should change (e.g. we should not silently

+>> switch to AES or even to the more robust PKCS#8-level encryption).

+>>

+>> 2013/7/15 Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>>:

+>> > And finally a comment/question/complaint :(

+>> >

+>> > If I use protection like this for ex:

+>> >

+>> > export = rsa.exportKey(passphrase='boo', pkcs=8,

+>> > protection='PBKDF2WithHMAC-SHA1AndAES256-CBC')

+>> >

+>> > The exported key looks like this:

+>> >

+>> > -----BEGIN ENCRYPTED PRIVATE KEY-----

+>> > MIIFHzBJBgkqhkiG9w0BBQ0wPDAbBgkqhkiG9w0BBQwwDgQIHI1C+JhO35cCAgPo

+>> > MB0GCWCGSAFlAwQBKgQQ2FsezYUEaQLPHxk0z6+R4gSCBNDV++BsvKxxpo6uhUYw

+>> > ...

+>> >

+>> > With export = rsa.exportKey(passphrase='boo'):

+>> >

+>> > -----BEGIN RSA PRIVATE KEY-----

+>> > Proc-Type: 4,ENCRYPTED

+>> > DEK-Info: DES-EDE3-CBC,CE7B6EC598ED0D10

+>> >

+>> > lPMvbYUypG+O4P/LilzGVQqP+6PMbnnLMP6eosyubcBqLtQxvMlvRRqgRu5CDApA

+>> > ...

+>> >

+>> > 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:

+>> >

+>> > -----BEGIN RSA PRIVATE KEY-----

+>> > Proc-Type: 4,ENCRYPTED

+>> > DEK-Info: AES-256-CBC,16D792053CB9E5981B06E020900F86EA

+>> >

+>> > oL8O6n5v1S3cgGJIwrzrAq5TQIb7OeolGJpHXiyTUj1iStulgS5vAjkht0cgq53p

+>> > ...

+>> > ..

+>> >

+>> > Thanks,

+>> > Kurt

+>> >

+>> > On Sun, Jul 14, 2013 at 11:40 PM, Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>> wrote:

+>> >>

+>> >> 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

+>> >> passed to

+>> >>

+>> >> PKCS8.wrap() like iteration_count and salt size?

+>> >>

+>> >> On Sun, Jul 14, 2013 at 9:34 PM, Kurt Vogel <<a href="mailto:kvogel@mdcom.com">kvogel@mdcom.com</a>> wrote:

+>> >>>

+>> >>> Hi,

+>> >>>

+>> >>> 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:

+>> >>>

+>> >>> 'BcryptWithHMAC-SHA1AndAES256-CBC'

+>> >>>

+>> >>> Thanks,

+>> >>> Kurt

+>> >>>

+>> >>> On Fri, Jul 5, 2013 at 2:52 AM, Legrandin <<a href="mailto:helderijs@gmail.com">helderijs@gmail.com</a>> 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

+>> >>> > > <a href="https://github.com/dlitz/pycrypto/pull/32" target="_blank">https://github.com/dlitz/pycrypto/pull/32</a>.  Just a few comments...

+>> >>> > >

+>> >>> > > * For readability can you pep8 format the code?

+>> >>> > > * RSA, for import/export the protection parameter maybe rename to

+>> >>> > > algo or

+>> >>> > > wrap algo?  It evolves from: 'protection' to 'wrap_algo' to 'mode'

+>> >>> > > as

+>> >>> > > it

+>> >>> > > goes down the call stack.

+>> >>> > > * Also maybe make this parameter an enum/value?  Since the long

+>> >>> > > string can

+>> >>> > > be error prone, low level code would need to change anyway if it

+>> >>> > > were

+>> >>> > > either

+>> >>> > > 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 of

+>> >>> > > 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

+>> >>> > <a href="mailto:pycrypto@lists.dlitz.net">pycrypto@lists.dlitz.net</a>

+>> >>> > <a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a>

+>> >>>

+>> >>

+>> >

+>> > _______________________________________________

+>> > pycrypto mailing list

+>> > <a href="mailto:pycrypto@lists.dlitz.net">pycrypto@lists.dlitz.net</a>

+>> > <a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a>

+>> >

+>> _______________________________________________

+>> pycrypto mailing list

+>> <a href="mailto:pycrypto@lists.dlitz.net">pycrypto@lists.dlitz.net</a>

+>> <a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a>

+>

+> _______________________________________________

+> pycrypto mailing list

+> <a href="mailto:pycrypto@lists.dlitz.net">pycrypto@lists.dlitz.net</a>

+> <a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a>

+>

+_______________________________________________

+pycrypto mailing list

+<a href="mailto:pycrypto@lists.dlitz.net">pycrypto@lists.dlitz.net</a>

+<a href="http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto" target="_blank">http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto</a>

+</blockquote></div> </div>

+</tt>