Colorful Security Question

[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.

Comments

Integrity

[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).

[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.)

[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-)

[(Anonymous)]

Why not use italic, underline, strikethrough and so on rather than color?

[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.