A few days ago, a fairly famous journalist tweeted a string of numbers. This journalist happens to be wellknown as working in the sector of surveillance, and is likely to be developing sources that require serious operational security. Because of these reasons, I found the tweet quite interesting, and wanted to spend some time analyzing it, the ideas behind it, and what can go wrong in this situation. For purposes of this post, the name of the reporter will be Rama.

To start with, the tweet looked like this (with the specific numbers changed):

63035 06017 21978 93715 96232 84895 60943 67119 66358 64984 80551 27945

What are they trying to achieve?

The first question we need to answer is what these numbers are, and what Rama was trying to achieve by tweeting them. Of course, in theory these numbers could be almost anything. However, we can make a pretty good guess, and work forward from there. Since the numbers are only in the range 0 to 9, and not hexadecimal or any other format - and there are 60 numbers in total - we can strongly suspect that this is a Security Number from Signal. Since the formatting of 5 numbers in 4 segments in 3 rows is also how Signal usually present its security numbers, this seems a likely guess.

Signal security numbers are not the same as fingerprints. Instead they are composed of fingerprint material from both sides of a conversation. That means that in order to have a full Signal security number of length 60, it's necessary for a conversation partner to exist. We will call this partner Sita (the Source). So, for Rama to tweet a security number, we know that Rama has done a Signal key exchange with Sita, thus generating the security number.

We can now make a strong guess that the reason for Rama to tweet this number is because Rama and Sita have established contact, and Sita wanted some kind of assurance that the person they are talking to is the same person who is controlling Rama's twitter account. It is also possible that they have used other verification methods, and that this is only one of several verification methods.

However, what's interesting to keep in mind here, is that Sita verifying the identity of Rama is not the same as verifying that no man-in-the-middle attack is in effect. Comparing security numbers is used for the second purpose, but for the first purpose there are many other solutions that don't have the problems outlined below. One simple method would be for Sita to ask Rama to tweet a specific code word or code phrase.

At this point we can start discussing the possible consequences and problems with this approach.

Under what threat model are they operating?

Before analyzing the problems, it's useful to talk about what the threat model are in this situation. It's possible that the people in question are operating under a conscious and well thought out threat model - but it's also possible that there is no specific thought to the threat model. In that case, the actions does imply a subconscious threat model.

In this case, it's clear that an adversary that can control Twitter isn't part of the model. Also, however Sita would look at the tweet is not considered a possible attack either. The adversary is also assumed to not be able to infiltrate the mobile phones of either Rama or Sita. These assumptions probably exclude most strong adversaries in the US intelligence service context.

What's a bit interesting about this threat model is that it's quite inconsistent. The kind of adversary that could effect a man-in-the-middle attack against a Signal conversation is also very likely to be the kind of adversary that could control aspects of Twitter. Thus, using Twitter for verification in the case of this kind of adversary doesn't actually serve any strong useful purpose.

What are the problems with this approach?

There are a few problems with this approach. The first one is simple - it's signaling to any observer that Rama might have a contact where it's important enough to verify the security number. Since this doesn't happen very often, it's something that stands out to any observer, and would raise suspicion. Whoever the adversary is, it's likely they would notice this kind of signalling.

Not only does this approach tell the adversary that clandestine communication is happening, it also shows the world what technology is being used for this communication.

The final problem is one of deniability. This is a particular problem of using Signal security numbers, since they contain information about both sides of the conversation. That means that in the future, if someone were to get access to Rama's or Sita's Signal instances, it can be shown that those two were in fact in contact - the tweet serves as an indication of this. This is true even if things like disappearing messages are used, since it's a fact about the conversation itself, not the content of it.

The deniability problem can be mitigated by both parties having many conversations with many different people using the same Signal instances. The other alternative would be for both Rama and Sita to publish their part of the security number in public. However, the effect of this mitigation is making it more likely that someone will be able to identify the real identities of Rama and Sita based on the tweet from Rama.

How could they improve their verification methods?

There are many ways of making this situation better. The first, and most important point, is to put together a coherent threat model and use that to make decisions.

After that, there are many different small mitigations that can be used. A simple one would be to obfuscate the missage a little bit. The form of the message is extremely distinguishable. So, don't retain the spaces and newlines. Make the numbers into one long string of numbers instead. Second, you can add noise, to change the length. Put random numbers before and after and in the middle. These will make it less likely to be identified as what it is.

There are other ways of making the situation significantly better. A big problem with the current one is that it contains information that ties Rama and Sita together. But there's no real reason for that. Rama could just tweet their part of the security number. That would allow Sita to verify that they are talking to the right person. Since Sita likely isn't known to Rama, there is no real point in doing verification in the other direction.

Another way of obfuscating the information would be to do a transformation of it. If both sides are moderately technical, using a hash would be good for this:

toTweet = SHA-256(originalSecurityNumber)

By doing this, only people that know the correct security number, can verify that it's the correct one. This still has deniability problems though, especially after the fact. One way to solve this would be to use a MAC instead of hash - by making a secret necessary to verify the security number, you can make sure only Rama and Sita have this capability:

toTweet = SHA-256(key + SHA-256(key + originalSecurityNumber))

In a situation with people who are less technical, it's possible to achieve a similar result, by creating a key that is a string of numbers, and then use them by just adding each segment.

key = [9460, 85261, 43594, 80920, 17833, 77126, 83506, 11812, 52016, 94067, 92450, 2893] originalSecurityNumber = [63035, 06017, 21978, 93715, 96232, 84895, 60943, 67119, 66358, 64984, 80551, 27945] toTweet = [key[0] + originalSecurityNumber[0], key[1] + originalSecurityNumber[1], key[2] + originalSecurityNumber[2], key[3] + originalSecurityNumber[3], ... ]

This approach is simple enough, and can be done with pen and paper. As long as the original keys are destroyed after being used, this should supply enough deniability for this purpose.

Other types of steganography is also a possibility. Especially when using a public medium like Twitter, embedding a security number inside a picture might be one way of not attracting so much attention. There are many other tricks like this - and using several of them together might also make the situation significantly better.

Summary

The actions we take for verification can sometimes have unexpected side effects. Operational security is not simple, and if we don't think carefully, and base our actions on rational threat models, it's possible we will make mistakes that can be dangerous.

Hopefully this post showed a few examples of this, and some thinking around how to mitigate these situations.