Python 3 and other

[jbtule]

This was the last pull request I had from 2 years ago adding python 3 support. It's only difference from
jbtule/keyczar-python2to3 is it doesn't have the Travis-CI continuous integration, since that is per repository and there are multiple platforms in the google keyczar repository. Do with it what you will, I imagine 2 years will have some adjustments needed.

• Python 3 support using 2to3 Issue 125
  • moved unit tests to package keyczar.tests
  • moved keyczart to package keyczar.tool
  • Added binary-only api for en/decrypt, attachedverify
  • refactored backend to use streams for all en/decrypt
  • refactored most of the char manipulation to bytes & bytearray
  • removed cut/paste python source code
  • removed circular references
• Adds Timeout Signatures Issue 10
• Adds Tool recursive Directory creation Issue 115
• Adds Tool usekey implementation to produce full test data Issue 116
• Suite of interop unit tests for Java, Python2, Python3, C#, and Go data
• Added key collision support Issue 108
• Corrects zero padding of RSA key data described here
• Adds leading zero to EMSA pkcs#1 1.5 to match spec.
• Moved test data to submodule

[devinlundberg]

I skimmed across this PR for about an hour today and overall I really like how it reorganizes the code and makes the split between binary data and strings more concrete.

From a high level I noticed:

1. The indentation seems to be inconsistent especially when continuing lines. @divegeek I have been writing lots of python using pep8 for the past year now, could you refresh me on the google python style guide? (If they open sourced any of their style tools that would also be a huge help)
2. I feel like the submodules don't really fit with anything else we have in our repositories. We can probably get rid of the javatests if we get this working with the interop testing.
3. I should probably give the stream sections and the testing for those sections much closer looks since those seem to be the biggest changes in actual logic.
4. There are definitely going to be rebasing issues since I noticed conflicts with several more recent inclusions to the python project (like optional encoders). Hopefully these won't take too long.

@jbtule I'll probably end up forking this and taking off where you left off since you said you don't have time to work on this. If that's not the case, let me know. Otherwise I'll add you on the PRs and would be happy to have your feedback.

[jbtule]

@devinlundberg fork away!

[dgryski]

@devinlundberg maybe run https://github.com/google/yapf across the whole code base?

[devinlundberg]

@dgryski looks like a useful tool! I'll play around with it.

[bufke]

I was playing around with this. Did RsaPublicKey.Encrypt become RsaPublicKey.EncryptIO? Is this intentional? It seems inconvenient having to use BytesIO if I just want to encrypt a string in memory.

[jbtule]

You don't use the encrypt functions of the keys directly, because if you do you are bypassing one of the biggest security features of keyczar, the key rotation. So design wise using byte streams on the non public API portion makes a lot of sense. There is still a string version of encrypt method on the public facing Encrypter class.

[soferio]

Where does this fit in? https://pypi.python.org/pypi/python3-keyczar/0.71rc0

[jbtule]

@soferio It looks like someone added this pull request to pypi. I just eye-balled it and saw most of my changes in it.

[asacamano]

It seems like there's some real value here - but there are conflicts... Anyone want to finish this off?