Support for alternative of python-crypto

[Rocco83]

python-crypto is no longer available in rhel7
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Migration_Planning_Guide/sect-Red_Hat_Enterprise_Linux-Migration_Planning_Guide-Removed_Packages.html

Supported alternative would be very appreciated.
m2crypto seems supported on python2 from at least debian/ubuntu and centos/rhel.

Thanks,

[davidhalter]

IMO if anyone considers to improve the library I would go with the library cryptography. It looks like that's what the general Python library is steering towards.

https://github.com/pyca/cryptography

IMO a lot of the functionality of PyCrypto (if not all) could be used replaced with cryptography.

>>> from cryptography.hazmat.primitives import serialization
>>> from cryptography.hazmat.backends import default_backend
>>> k = serialization.load_ssh_public_key(PUB_KEY, default_backend())
>>> k
<cryptography.hazmat.backends.openssl.rsa._RSAPublicKey object at 0x7fdf421eed30>
>>> k.key_size
2048
>>> dir(k)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_backend', '_evp_pkey', '_key_size', '_rsa_cdata', 'encrypt', 'key_size', 'public_bytes', 'public_numbers', 'verifier', 'verify']
>>> k = serialization.load_ssh_public_key(b'foobar', default_backend())
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/dave/cloudscale/venv/lib/python3.5/site-packages/cryptography/hazmat/primitives/serialization.py", line 40, in load_ssh_public_key
    'Key is not in the proper format or contains extra data.')
ValueError: Key is not in the proper format or contains extra data.

PUB_KEY in this case is the content of a simple id_rsa.pub (or dsa/ecdsa) file. I have only tried it with .rsa files, but i don't see why that would not be working with other files as well.

It probably doesn't validate RFC4716 keys (keys starting with ---- BEGIN SSH2 PUBLIC KEY ----) this way, but I'm not sure that this is what you want in this library anyway (I would suggest an alternate API endoint than the default one).

IMO the key_size is really all you need in your library and therefore it should be quite easy to replace.

[chrisWhyTea-zz]

I replaced pycrypto with cryptography due to the latest proof of concept vunability in pycrypto and like davidhalter said this is propebly the more future proof lib...
https://github.com/chrisWhyTea/python-sshpubkeys

Replacing the pycrypto RSA is no problem but DSA acctually is. (I hate DSA :<) While it works with strict mode the loose mode has problems because cryptography has internal checks to only allow DSA Keys that are 1024, 2048, or 3072 bits long ... so two loose mode tests are failing (test_valid_key_dsa_4096_mode_loose and test_valid_key_valid_dsa_16384_mode_loose) because crypthography acctually wants to enforce some security.

So for my usecase dropping the loose mode (Not done yet, and additionally catching possible value errors isnt done yet too) would do the trick ¯\_(ツ)_/¯

[ojarva]

@chrisWhyTea as DSA keys should not be used, I think dropping support for DSA keys != 1024/2048/3072 makes sense. If you finish that & delete failing DSA tests, please make a PR and I'll publish a new major version.

[chrisWhyTea-zz]

Done but fails due to the fact cryptography doesn't support python 3.3 #39

[davidhalter]

IMO drop it, it's end-of-life anyway.

[ojarva]

Already dropped and merged. I'll release a new version to pypi along with related notes (what changed/is broken) later today.

[Rocco83]

I would suggest to write anyway the output of old dsa with "not supported" text or something as output.
So it will be known that the output was not parseable.

[ojarva]

@Rocco83 what could be added is https://docs.python.org/3/library/warnings.html , but printing that is not going to happen.

Also, current paradigm for this library is to throw exception for that case, which is already happening. I don't see a reason to separately print that.