0

Its usually recommended that 'don't use your own system of Crypto' rather use standard SSL/TLS! I understand that SSL/TLS is a complete protocol suite that addresses all three elements of CIA triad. What if I need to use a subset of CIA, say I just need Authentication and Data Integrity. In such a cases isn't using full SSL/TLS is an overkill?

Is it possible to use a tailored down or lighter version of TLS suite for scenarios where say I don't need Integrity (basically to get some performance mileage)? OR its always a best practice to use TLS in full suite for securing a communication?

Akhilesh Gupta
  • 163
  • 9
  • 2
    If confidentiality is not a concern, then having confidentiality is not a downside, even if not required. –  Jun 23 '20 at 13:19
  • "is it ok to roll my own crypto if existing crypto does more than what I need it to?" -- no. That's not a good reason to expose yourself to the inevitable poor crypto that you will end up with. You don't state why your approach to your own crypto addresses the reasons why "don't roll your own" is the advice in the first place... – schroeder Jun 23 '20 at 13:49
  • @schroeder I mean what is risk if I use strong crypto only but not the full suite! say instead of full suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, I just use a tailored down suite like RSA_WITH_SHA384! – Akhilesh Gupta Jun 23 '20 at 14:15
  • 1
    @AkhileshGupta You still have not explained what the problem with using a well-tested TLS suite is. It's like saying "I want to buy a new car, but this car I want to buy has a heated back window, and I don't need a heated back window. What should I do?" –  Jun 23 '20 at 14:39
  • @MechMK1 well, like I stated in my question - for scenarios where I don't need all elements of CIA in a communication, why a full TLS suite should be used! like in a scenario where a point to point wired ethernet connection is there; and confidentiality is not a concern. so sending data in encrypted form is not a requirement.. is it a good idea to use full TLS suite in such scenarios as well? In other words do I need to use full TLS suite in all communication scenarios as a defacto standard! Thanks – Akhilesh Gupta Jun 24 '20 at 04:55
  • "Why should I use a full suite?" - Because it's well-tested, it works and it has no downsides to use it. –  Jun 24 '20 at 07:00
  • Mostly dupe https://security.stackexchange.com/questions/97679/can-tls-provide-integrity-authentication-without-confidentiality and https://security.stackexchange.com/questions/239614/is-there-a-protocol-that-provides-data-integrity-but-not-encryption-for-http – dave_thompson_085 May 05 '21 at 05:48

1 Answers1

2

Strictly speaking, TLS already supports what you're asking about. There are "null cipher suites" - that is, TLS cipher suites that have no ("null") encryption - that would do what you want. Using one will allow you to use existing TLS libraries and take advantage of all the work and hard thought and lessons learned that has gone into the TLS standard and implementations in major libraries. You can also just use TLS with an AEAD (Authenticated Encryption with Associated Data) cipher - most often AES-GCM (the AES block cipher in Galois/Counter Mode of operation) - and send your data as the "Associated Data" rather than the message contents; the associated data is part of the integrity check but is not encrypted.

However, as several commenters have pointed out, there's almost certainly no good reason to do this. Encryption and decryption with modern algorithms and hardware is very fast - potentially much faster than the network connection the traffic arrives over - and once you have the ability to establish a secure channel, there's no reason to make it less secure than you could. If you're running so extremely close to the performance threshold that the time spent on encryption/decryption is meaningful, some very slightly better hardware is probably a better solution. Also, make sure you're using a TLS library that is built for performance, and that supports AES-NI (AES native instructions, which all modern CPUs support).

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • Thanks CBHacking! I guess your remark 'Encryption and decryption with modern algorithms and hardware is very fast' holds also true for IoT devices, where some may have small foot print! I was specifically looking for this optimization wrt small footprint IoT devices. – Akhilesh Gupta May 04 '21 at 09:21
  • Note eNULL suites only exist up to 1.2; 1.3 removes them. As a primitive AEAD (including GCM) allows dividing encrypted and unencrypted (AAD) any way you want, but _TLS_ puts all application data in encrypted and in AAD only the 'pseudoheader' previously added to HMAC input, which is record sequence, type, protocol, length, plus fragment info in DTLS. If you don't have hardware (CPU) support for AES, ChaCha20+Poly1305 suites (in both 1.2 and 1.3) are usually good. – dave_thompson_085 May 05 '21 at 05:48