[Cryptography-dev] Landing AES

[Vladimir Diaz]

https://github.com/alex/cryptography/blob/5c02ef3260aa4ffc5920aca4bc5d8aa88b430c14/cryptography/bindings/openssl/api.py#L64-L68

Instead of just asserting that 'evp_cipher' is not NULL, you may instead
raise a user-defined Python exception matching the OpenSSL error code that
you extract with ERR_get_error(), ERR_GET_REASON(), etc [1,2,3].

Example:

cipher.name = "bogus_cipher_name"
cipher.mode = "bogus_mode"
cipher.key_size = 0

ciphername = "{0}-{1}-{2}".format(cipher.name, cipher.key_size, cipher.mode)
evp_cipher = self._lib.EVP_get_cipherbyname(ciphername.encode("ascii"))

# If EVP_get_cipherbyname() returns NULL, OpenSSL should have added the
error
# code to the thread's error queue (i.e., call ERR_get_error(),
ERR_GET_REASON(),
# etc. to extract the specific OpenSSL error.
if evp_cipher == self._ffi.NULL:
  error = routine_that_extracts_ssl_error_information()
  # Raise user-defined exception matching SSL error?


Perhaps your Python library defines exceptions for each expected OpenSSL
error code and your test modules test against these user-defined exceptions?

assertRaises(cryptography.SSLCipherNameError, create_block_cipher_context,
bogus_cipher, bogus_mode)


[1] https://github.com/openssl/openssl/blob/master/crypto/err/err.h
[2] https://github.com/openssl/openssl/blob/master/crypto/evp/evp.h#L1444
[3] https://github.com/openssl/openssl/blob/master/crypto/evp/evp.h#L1453



On Sat, Aug 31, 2013 at 11:27 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> Sure, but the problem is triggering errors in the first place in the tests.
>
> Alex
>
>
> On Sat, Aug 31, 2013 at 4:16 AM, Vladimir Diaz <vladimir.v.diaz at gmail.com>wrote:
>
>>
>>
>>
>> On Sat, Aug 31, 2013 at 1:47 AM, Alex Gaynor <alex.gaynor at gmail.com>wrote:
>>
>>> So I gave up on trying to test the paths, until we know how they're
>>> supposed to fail, I just made them asserts, this way errors do not pass
>>> silently, and we have coverage (this is particularly important since we'd
>>> further have untested code for figuring out what the current openssl error
>>> is).
>>>
>>
>> Might OpenSSL's ERR_get_error() and ERR_GET_REASON() help in figuring out
>> what the current OpenSSL error is?
>>
>> http://www.openssl.org/docs/crypto/ERR_get_error.html
>> http://www.openssl.org/docs/crypto/ERR_GET_LIB.html
>>
>>
>>>
>>> We still need an answer to "change the API" vs. init on first method.
>>> Anyone have strong opinions?
>>>
>>> Alex
>>>
>>>
>>> On Tue, Aug 27, 2013 at 5:53 AM, Donald Stufft <donald at stufft.io> wrote:
>>>
>>>>
>>>> On Aug 27, 2013, at 8:50 AM, Hynek Schlawack <hs at ox.cx> wrote:
>>>>
>>>>
>>>> We've slowed a bit in the last week or so. I want to get the AES patch
>>>> landed so we can get the momentum back up (
>>>> https://github.com/alex/cryptography/pull/28). There's a few
>>>> outstanding issues we need to resolve:
>>>>
>>>> * How the heck do we test error conditions in OpenSSL? OpenSSL is
>>>> totally negligent in how we reproduce them. Should we monkeypatching the
>>>> cffi functions to return error codes so we can at least test our code paths?
>>>>
>>>>
>>>> That sounds rather sketchy TBH but I don't know the innards of both.
>>>>
>>>>
>>>> I agree on this sounding sketchy but it might be the best way forward.
>>>>
>>>>
>>>> * Since the BlockCipher object doesn't know if it's in encrypt or
>>>> decrypt mode until the first call it can't really initialize itself in the
>>>> constructor. Is that fine?
>>>>
>>>>
>>>> I see two options:
>>>>
>>>>  1. Explicit factory methods.
>>>>  2. Init on first use.
>>>>
>>>> I tend to prefer 1., ideally with separate types. I love me some types.
>>>>
>>>>
>>>> I prefer just init on first use, it's currently setup to switch into
>>>> decrypt or encrypt modes based on if you call BlockCipher.decrypt() or
>>>> BlockCipher.encrypt() first. FWIW Encrypt/Decrypt mode only makes sense for
>>>> certain combinations of things, some block ciphers can use the same
>>>> operation.
>>>>
>>>>
>>>> —h
>>>> _______________________________________________
>>>> Cryptography-dev mailing list
>>>> Cryptography-dev at python.org
>>>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>>>
>>>>
>>>> FWIW there are a few outstanding issues inside the Pull Request
>>>> comments as well.
>>>>
>>>> -----------------
>>>> Donald Stufft
>>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>>>> DCFA
>>>>
>>>>
>>>> _______________________________________________
>>>> Cryptography-dev mailing list
>>>> Cryptography-dev at python.org
>>>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> "I disapprove of what you say, but I will defend to the death your right
>>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>>> "The people's good is the highest law." -- Cicero
>>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>>
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>>>
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> http://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> http://mail.python.org/mailman/listinfo/cryptography-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20130831/21911cfc/attachment-0001.html>