Schneier on Security

Clive Robinson • January 17, 2021 8:50 AM

@ SpceLifeForm, Winnie, Who?, ALL,

Or, were you thinking of the issues of Sign/Encrypt vs Encrypt/Sign?

No, and I can not find it either, though The grugq does partially mention it in the slide deck @Who? Linked to.

It’s about the difference between authentication and attribution.

You have to consider that in every “assumed to be” two party communication a third party may be evesdropping at the time or one of the two communicating parties may rat the other out, either intentionally or to save their skin[1].

Thus comes a trade off between one party authenticating to the other, but still having full deniability to all other third parties no matter hoe sophisticated.

In a way it harks back to the notion of “duress tells” used by SOE and other operators during WWII. That is the two parties have an agrement to modify a message in a particular apparently inocuous way such that the other party knows the sender has been captured and is now under the control of a third party.

The important thing is that it must be sufficiently deniable that even if the method is reviealed it is insufficient to act as proof to a third party or anyone else such as a jury, whilst sufficiently strong to authenticate the originator to the second party.

There are three important things to note,

1, It must not require any magic numbers or other information for you to use it, as possession of these is in effect proof positive.

2, What ever the method is it must be able to survive a “messages in depth” attack. That is if the third party has any number of previous messages then the authentication method should not show up as a verifiable correlation.

3, The method should not stand out in any message. That is if the messgae is “chatty” the method should not be “formal” or “styalistic” etc.

Supprisingly as difficult as this sounds it can be done with “common knowledge” used as a code. So “met A at B’s” actually conveys nothing to a third party but if the second party knows what A and B are it has meaning to them.

As I’ve mentioned before you can do this with codes that are reordered by “One Time Pad”.

So the expression,

“We should AAA for a XXX YYY Z”

So, AAA could be – meet, meet up, go out, get together

Which gives you two bits of information.

XXX could be – tea, coffee, dring, chat

Which gives you two more bits.

Similarly XXX could be a list of times or places to give another couple of bits, and Z a final use or not of a question mark, full stop or comma gives you another two bits.

So you have 8 bits or a one in 256 chance to authenticate correctly. Obviously these indicators would have to change randomly which is why you use a one time pad to encrypt your authenticator.

So provided you use the one time pad correctly and destroy used values you have deniability, even if the second party turns traitor or is coerced and produces their OTP all they are doing is tying themselves to the messages not you.

A wise person will however do other things that the second party is not aware of to give them further deniability.

As these codes work without the need for other encryption of the messages, they can be sent in plain text over an open broadcast network such as a morse code radio circuit without attracting attention.

[1] In the slide deck the old joke about “having better sneakers to run fast enough to out run your companion when the bear comes charging through” is used. Only the twist is the slow one is the one the bear gives a chance to rat out everyone else… A point that everyone using any kind of communications with others should remember at all times. There is an old saying about “snitches and wires” which is,

A friendly chat is a deadly chat.

Clive Robinson • January 18, 2021 4:01 AM

@ Peter A.,

For the system to work all handsets would have to be identical in every way. That is even temporary ID’s will give away which handset is which just by “normal physical movment”

That is for most of us we sleep in the same bed each night and sit at the same desk most work days, shop at the same shops often at the same times every week etc etc. Thus the temporary ID can be tied to an individuals phone by an individuals standard behaviours in geo-physical space.

All the mobile networks need to know where a handset is in their network so calls can be routed to it, otherwise the broadcast bandwidth would be excessive and a compleate waste of spectrum space.

It’s just one of many reasons I keep mentioning “Security-v-Efficiency”. Generally the more efficient a system is the less secure it is.

Normally efficiency makes a system more transparant and opens more side channels. This case however shows a different issue. To get higher efficiency resources are reused, thus you need to somehow seperate the reuse instances to stop them interfering with each other. This reuse seperation can be done in different ways such as time, space, code/identity but the result is the same… For the system to work it has to know where individual units are to synchronize with the resource reuse and to ensure it uses the correct resource reuse instance.

When you sit and think about it you realise there is no usable way around the issue.

I’ve known this for four decades and I’m still looking for a way to do a version of it which is on a routed network where mobile units have to change their network ID’s / addresses when they move, how do you establish a peer to peer communication anonymously. That is can you come up with an anonymous Rendezvous Protocol because you can not use a broadcast model.

Clive Robinson • January 19, 2021 9:40 AM

@ SpaceLifeForm,

I’ve hinted at what I believe is the answer before. It requires a federated cloud.

The problem with “federated” is it means diferent things to different people.

However there is one major failing in all the common federated systems,

Trust Me because of “token”.

That is each domain has to trust another domain because it has some kind of secret that is the token.

Such a shared secret token can be issued by Alice’s Domain to Bob’s Domain (or the other way around). Provided Alice and Bob trust each other not to loose or betray the “shared secret” they can use it as a route of trust.

However such a method very quickly sufferes from a database size isse SS[m] = 0.5(n^2-n) problem that is the number of entries m in the Shared Secret database goes up proportionately to the number of domains n squared. So 100 domains needs 4950 ~5k entries and 200 domains needs 19900 ~20k entries so twice the number of domains four times the entries as expected. Now IPv4 in theory allowed ~2^24 network domains of 254 members so ~1.4×10^14 domain entries or ~1.2×2^47 or a little under 2^48 which is a very large database… The long answer short,

One to One, Shared secret systems are not scalable, thus not practical.

And that’s before talking about the practicalities of actuall sharing a secret between two domains. And how it has to be done prior to any electronic communications, etc, etc, etc.

There are two commonly known ways to resolve this. One is by a “hierarchy” system such as CA’s which has a serious coruption at the top issue. The second is by a “reputational” system such as a web of trust which has a very serious range issue beyond two degrees and becomes increasingly fragile thus easier to pervert. Oh and whilst both are pervertable by simple corruption and wildly differe for just one perversion, as the number of perversions rise the costs fairly quickly converge to about the same for industrial scale surveilance.

So the question arises of can a federated service be avoided.

Well not realy take it to the ultimate conclusion and your “address book” is in effect a federated reputational system.

The problem is assessing and weighting trust for hierarchy -v- reputation. In general the bigger a “conspiracy” is the higher the probability of one member is of betraying the conspiracy so people think hierarchical systems are more trust worth as they would hear about it sooner. The problem is like a door that argument swings both ways they are more easily secretly corrupted as well. In fact as I mentioned with corruption costs after a limited number of corruptions both hierarchical and reputational systems are about the same for mass surveillance.

So how to get reliable trust is the key question and no matter how loud you shout it the answers are few and mostly negative and lost in the background noise.