Let's consider an embedded device which supports ECC and some symmetric cryptographic primitives but not the RSA algorithm.

Can it be TLS compliant? I think that if the device and the server share a cipher suite which has nothing to do with RSA, then there is no problem.

The RFC 5246 makes me doubtful because of this section:

  1. Mandatory Cipher Suites

    In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

So what should I conclude?

  • 1
    I wonder what's going to happen when the chosen SHA hash (I think it's SHA-256 but don't quote me on this) is found to be too weak. AES128 may hold forever but we've had bad luck on hashes. – Joshua Mar 25 '16 at 18:35
  • @Joshua: If you believe AES is secure then then can't you just encrypt it with some portion of itself as the key to simulate a hash and then XOR its chunks together to turn it into something small? In fact it makes me wonder why people don't do that... – Mehrdad Mar 26 '16 at 0:48

This clearly says "In the absence of an application profile standard specifying otherwise". Which means if you write a TLS stack and expect arbitrary TLS implementations to connect then you must implement the given cipher as the minimal common cipher. If instead you need the TLS stack only for a specific application and define the ciphers used by the application as ECC only then you don't need to implement this specific cipher.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.