[pycrypto] RSA exportKey question with bcrypt?

Kurt Vogel kvogel at mdcom.com
Mon Jul 15 15:22:09 PDT 2013 

Gotcha, thanks for the updated information.
Didn't know PEM level encryption is best avoided and being phased out

So ignore comment on additional function names, but add **kwargs to
exportKey()
to support iteration count and salt size for protection types allowing
those arguments?

And if I didn't mention already thanks for all the work on this, there is a
lot..
Kurt


On Mon, Jul 15, 2013 at 1:52 PM, Legrandin <helderijs at gmail.com> wrote:

> 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 <kvogel at mdcom.com>:
> >
> > 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 <helderijs at gmail.com> 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 <kvogel at mdcom.com>:
> >> > 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 <kvogel at mdcom.com>
> 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 <kvogel at mdcom.com>
> 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 <helderijs at gmail.com>
> 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
> >> >>> > > https://github.com/dlitz/pycrypto/pull/32.  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
> >> >>> > pycrypto at lists.dlitz.net
> >> >>> > http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
> >> >>>
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > pycrypto mailing list
> >> > pycrypto at lists.dlitz.net
> >> > http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
> >> >
> >> _______________________________________________
> >> pycrypto mailing list
> >> pycrypto at lists.dlitz.net
> >> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
> >
> >
> >
> > _______________________________________________
> > pycrypto mailing list
> > pycrypto at lists.dlitz.net
> > http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
> >
> _______________________________________________
> pycrypto mailing list
> pycrypto at lists.dlitz.net
> http://lists.dlitz.net/cgi-bin/mailman/listinfo/pycrypto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dlitz.net/pipermail/pycrypto/attachments/20130715/f3b5143e/attachment-0001.html>

More information about the pycrypto mailing list