ewx: (penguin)
[personal profile] ewx

https://en.wikipedia.org/wiki/Red/black_concept describes a notation sometimes used when discussing confidentiality:

  • red denotes signals carrying secret plaintext;
  • black denotes signals carrying ciphertext.

Is there any generally agreed coloring for the analogous integrity question? i.e.:

  • a color which denotes signals where integrity matters (or maybe this is "all of them" and we don't need a specific choice of color); and
  • a color which indicates a signal with cryptographic integrity protection of some kind.

Non-color visual notations also welcome for several reasons:

  1. things still get printed in monochrome;
  2. color vision is not uniform among humans;
  3. using too many color notations at once leads to angry fruit salad rather than clear diagrams.


Date: 2016-02-23 08:55 pm (UTC)
From: [identity profile] martinbonner.livejournal.com
Once a signal has cryptographic integrity protection, you don't have to worry about an attacker manipulating the message (just as, once a signal is encrypted, you don't have to worry about the attacker reading it).

Signals that aren't protected like that, have to be protected in other ways (like keeping them inside a potted module).

Once you have that distinction, it is useful to be able to show them graphically.

Of course, manipulating a signal requires a more powerful attacker than reading it (it's the difference between Schneier's "Mallory" and "Eve" figures).

(no subject)

Date: 2016-02-24 03:52 pm (UTC)
simont: (Default)
From: [personal profile] simont
I wonder if it matters that integrity is more subtle because it can be applied retrospectively?

For example, an SSH connection setup initially has no integrity protection – because how could it, when you haven't yet got a shared secret to base it on? – but after the key exchange completes, signatures are generated which cover a hash that includes the whole of the unprotected connection setup phase. So those messages are not integrity-protected at the time of sending in the same sense that the rest of the protocol session is, but they are integrity-protected eventually, in that later on there will come a point where you are convinced that they hadn't been tampered with.

I feel as if that kind of subtlety might be harder to represent in a simple colour code than confidentiality protection, which is much more like a fixed property of the message as originally sent.

(Though, I suppose, even confidentiality protection could be retrospectively removed, either by sending the decrypted version somewhere or by revealing a key.)

(no subject)

Date: 2016-02-24 07:24 pm (UTC)
ext_8103: (Default)
From: [identity profile] ewx.livejournal.com
It's a good point; trying to represent it on a detailed protocol diagram would be tricky, I think a spatial indication (e.g. a line extending from the signature to a box containing the kx messages) would be more appropriate there. Perhaps having it 'fade out' as it went back in time would be a good way to indicate that it was retroactive.

But, for my immediate purposes, I'm representing things at least one abstraction level up from that, if not two - my diagram doesn't even state exactly what protocol is in use (the surrounding text does and in fact it's also a fixed part of the context, because this is really a small improvement to a long-established system).

In the confidentiality case it suffices to draw red lines inside a box and black lines between boxes; I'm just looking for an analogous way of indicating that there are some worthwhile integrity protection properties too, ideally something that I can do easily in Gliffy l-)

(no subject)

Date: 2016-02-26 07:29 am (UTC)
From: (Anonymous)
Why not use italic, underline, strikethrough and so on rather than color?

(no subject)

Date: 2016-02-26 09:11 am (UTC)
ext_8103: (Default)
From: [identity profile] ewx.livejournal.com
Because I'm looking for a way to distinguish elements of a diagram such as lines and boxes, not purely textual elements.

August 2017

13 141516171819

Most Popular Tags

Expand Cut Tags

No cut tags