Schneier on Security

Clive Robinson • January 30, 2013 5:06 PM

@ Johann Gevers,

“Centralization makes systems fragile. Antifragile systems are decentralized.—Nassim Nicholas Taleb, in his new book”Antifragile”

I’ve not read the book but, as you’ve described it Taleb has it wrong.

The fragility of systems is not primarily related to whether they are centralized or decentralized.

It’s primarily related to the number and topology of the communications paths between nodes and secondarily the ability of the nodes to recognise and either issolate or work around points of failure. It is only at the tertiary level that the redundancy or duplication of information and control in nodes has a bearing on it’s fragility.

The problem with a fully decentralised system is that it is grossly inefficient due to the required level of communication i.e. each and every change has to be communicated with every other node and this has a quiternary effect for which no realistic solution has been found, which is as nodes change how do they ensure that the information in every other node is correct. The only general solution is that only one node can change at any one time and this has to be “rollback” proofed usually with a three phase commit protocol which is even more inefficient as it tripples the communications involved each of which has a path length delay issue related to the longest path. Which encorages a centralized system which “rippless out”.

The reason traditional “pyramid” hierarchical systems are fragile is that in general none of the communications paths are duplicated and they are organised for “efficiency” into a tree structure that is general balanced. Such systems generaly encorage centralisation at the root node simply because it’s generaly the shortest distance to all nodes in a balanced tree.

It can also quite easily be seen that a decentralised system based on a balanced tree structure ranges from compleatly inefficient through to extremly fragile depending on the redundancy at the nodes (ie each nodes stores all information related to all nodes to each node only stores the information pertinent to that node and no other).

Such systems can be shown quite easily to be more fragile and more inefficient than a centralised system on a balanced tree structure…

I guess the question is, is Taleb wrong or have you misread what he has written?

Clive Robinson • January 30, 2013 11:37 PM

@ Ari Maniatis,

Firstly, schizophrenic doesn’t mean what you think it does. Perhaps you were aiming for ‘bi polar’.

Unfortunatly it depends on who’s definition you use…

If you Google the various online Dictionaries you will find they have several definitions in each dictionary (as is normal with most words).

Importantly though is the one they mainly have in common under general usage of the word,

(in general use) A mentality or approach characterized by inconsistent or contradictory elements

Which I think we would probably agree is one of the NSA’s defining characteristics.

But… As I think you mean with “schizophrenic doesn’t mean…” it is not the definition that is used in clinical diagnoses. Which is amongst practicioners found in ICD as recomended by WHO.

One of the joys of ICD is every so often they update it and sometimes (actually often) they change clinical definitions quite radicaly and this has knock on effects [1].

Whilst it might be proffesionaly prudent to change definitions, as we know “words have a life of their own” once in the general publics hands [2]. The fact that the practicioners who think they own the words they coin get upset/frustrated/whatever by what the public do with them is just one of the reasons George Orwell came up with his ideas on Newspeak being used to conttrol people by jargon.

Thus I respectfully submit that in our own ways we are both right and thus we should just say “hang the lot of them” to those who disagree with us (however I won’t hang around for your answer 😉

[1] In the UK we have a statute which is called the Autisum Act 2009 by many people, it was drafted back a few years before that, when ICD had a very broad set of diiagnoses fall under what was the Autism Spectrum Disorders (ASD) however the latest ICD has changed all that and moved a number of things into their own catagories etc. What is not clear is what legal repercussions this will have long term.

[2] In ITSec we have been forced to change our meaning of “Hacker” to that of the general public even though we had a perfectly good word that we had coined “Cracker”. And I remember this being debated on this blog, where people had decided the lackadasical Journalists had by their termilogical inexactitude for ever cursed us into a different meaning and that we should just acquiesce lest we look ridiculous.

Clive Robinson • January 31, 2013 4:04 AM

@ Ari, Scott Ferguson, Nick P,

All gentle jesting about word meanings aside, on to the technical asspects where in the case of ITSec every word does matter including those squirreled away behind generalisations and assumptions.

Ari you said,

Secondly, many of the issues with redundancy in voice communications creating opportunities to recover the key can be solved by applying good recover the key can be solved by applying good compression before encrypting

I was not talking about “opportunities to recover the key” that should be with a good crypto algorithm not possible except by chance or other failings in the implementation (one such being poor prime selection in PK Certs).

I was talking about the ability to recover inteligence from the cryptotext directly from the incorrect choice/use of codecs and crypto modes, which is an altogether different form of attack which is not much talked about these days on the assumption that it’s “old news” belonging to the days of “Substitution Ciphers”

Now I realise from your subsiquent text you were not actually talking about “key recovery” but “intelligence recovery” but I suspect other readers will ignore the mistake or take it as read depending on their experiance.

As Bruce has found in the past over AES key issues assumptions about who’s reading can be the equivalent of target practice at your foot. As critics pull you up more for what you don’t say than for what you do 🙁

So I apologise if I sound like I’m being pedantic (but I quite like my toes 😉

But with voice encryption “The devil is in the details” rather more than it is with other forms of encryption and it’s incredably easy to miss a step in the process, and that could be disastrous for security.

As Scott has indicated,

I also recall reading some research done by Google into the ability to search and index encrypted VOIP…

There are some very real and actually quite simple attacks that can be performed against voice encryption systems if not properly implemented. Which allow speakers to be identified, the language spoken and the type of content of the conversation.

The first problem is as I noted the soken word it’s self, for something that requires 144,000 bits per second raw digitized data rate to convey information at around 10bits per second [1] that’s one heck of an amount of redundancy.

Whilst the data rate terms abound in communications and computing [2] in information theory we tend to only talk about the information content in abstract and use the fundimental data element of a bit. This was due in the main to the work of Claude Shannon carried out around WWII. Shannon partialy defined and charecterised what we now understand as a communications channel [3] and came up with the term entropy [4] for the redundancy in information in the channel which he borrowed from thermodynamics.

Most codecs seek to reduce the redundancy and thus get the bit rate required down. However other codecs actuall try to match the charecteristics of the voice to the channel which although it usually gives compression can give a vastly improved error rate or reduced latancy etc. Thus care has to be used in codec selection or other mitigating techniques used.

One such mitigation used in the early days was adding synthetic noise to the audio signal to fill out quite spots and make the speach envelope less apparent. This has a significant number of problems so is not usually used these days.

The major reason for this these days is that tailored synthetic noise can actually be used to significantly reduce the resulting bit rate from a codex. In essence this is what the CELP based codex algorithms do, so adding further synthetic noise at their input is likely to degrade their performance.

Another mitigation is data expansion by whitening to the codec data output, this has two benifits, firstly it makes many attacks more difficult and secondly it spreads the energy in the channel which is usually desirable, the obvious downside is the data rate goes up. This can be easily achived by a simple 3-4 bit expansion that is you take 3bits of codec output and add a fourth bit that is unpredictable to an evesdropper. In essence it’s a little like adding bits from a stream cipher generator to pad out the data to make it more random. At the other end the recivier knows which bits to strip out so does not actually need to know what the bit values are.

However the same effect can be achived without expanding the data simply by xoring the data with the whitening stream. It does however make synchronisation harder and requires the receiver to know the whitening stream. This is in effect a stream cipher operation for which many stream ciphers are available. However as it is done prior to the main encryption it does not need to be a secure cipher therefor a simple LFSR of say 8bits can be used.

But there is another issue with codecs not yet mentioned and that is the quality of their data output verses the bit rate.

A codec can be either fixed rate or variable rate, variable rate codecs produce better reduction in redundancy but have the disadvantage of having their output rate correlated with thae audio input in some way. Whilst fixed rate codecs don’t correlat their bit rate to the audio, their data output is quite clearly correlated with the audio input thus in effect it produces a predictable pattern of data where say it produces all zero data output for times when the speaker is not voicing or uttering. Whilst the corelation is usually not that simple the statistics are, so the speach envelop can be easily recovered if the wrong cipher mode is used.

Of the two it is technicaly easier to use a fixed rate codex and whitening. However variable bit rate produces less data overall and usually does not require whitening providing the packet packing is done correctly.

There are two basic ways to put a variable bit rate output into data packets. The hardest to do is conncatination, but this results in variable rate data packets which is not good, the easiest generaly is “bit stuffing” although this does provide fixed rate data packets it has the side effect of increasing the overall data rate and to a small degree add extra latency.

Thus in realtime systems where latency is important variable rate encoders are best given a miss.

Which brings me onto the points Nick P made specificaly,

3. Link encryptor should be a dedicated, very hardened advice.

5. The Black IPSec packets should be fixed length and each node constantly sends packets to other at fixed speed. These defeat covert channels

There are two assumptions in there which can kill the security of a system stone dead.

Firstly whilst point 5 is correct you need to be aware of the differences between “data stuffing”, “packet stuffing” and “link stuffing” and where and how you apply them. Get it wrong especialy with the wrong encryption type and mode and you will alow the evesdropper to recover intelligence.

Further as the stuffing process adds redundancy, if badly done it gives known data in fixed points of the transmission data stream, this gives the possability of performing “bit flipping” attacks against stream ciphers and other types of attack against block ciphers esspecialy if it coincides with the block width, at the very least it’s easy to see how it would half the brut force search time for one known bit and by a power of two for each successive known bit

Second point 3 is correct but insufficiently stated. Thus the assumption that many people will make about the “Link Encryptor” is that is actually the point to point or application level encryption. It’s not it’s in addition to the application level encryption. Further having got it wrong they will use something like a crypto library to make the application encryption or link encryption or both themselves. Almost invariably they will use it incorrectly. The operation of the application encryption and the modes used are speciffic to voice encryption, likewise the operation of link encryption are speciffic to link encryption and are usually quite different.

One thing that often goes wrong is the developer will find that using a block cipher can add considerable latency to the audio especially if not used in ECB mode. I don’t have the space to do the subject justice (you need a large book) so all I will say is there are many trade offs with cipher systems and many gotchers both of which will wreak your security margins. So you realy need to know how your whole system works from the microphone onwards before you sellect operation type and mode for the various encryption stages (of which you should have three, codec data whitening, application encryption and link encryption).

Then not mentioned so far is what do you do on an error…

My simple advice is fail hard and fail long prior to link encryption to stop system transparency issues opening up side channels and have fast self resyncing modes on the link encryption. But… one of the problems with self resyncing cipher modes is they can be abused effectivly in ways that reveal intelligence.

And there is the Press To Talk (PTT) dilema, when using half duplex communications users talk in turn. Each time they “key up” to start talking the cipher systems have to resync. It is very very easy to get this badly wrong. Which is why “open mic full duplex” often appears very attractive to designers. I would urge them to actually work out how to do PTT correctly as this then makes error recovery more secure etc plus it is kinder on what is the VPN created by the link encryptor, and also alows the transmission of other data such as “whiteboard data” as well.

Voice encryption like many real time encryption systems can be very difficult to get your head around. There are all sorts of “Gottchers” waiting to be like “the croc in the swamp”. There are whole books that have been written on the subject and likewise for just small parts of the subject. Much that is in the public domain about VOIP and Mobile communications goes out of the window when you start talking about Secure Voice Comms which means there is a whole body of knowledge that is right for one domain (VOIP) and wrong for another (SecCom, VPN) but no easy way to distinguish which bits are transferable and which bits are not…

My advice is as given by Nick P’s point use as many off the shelf parts as you can in a strongly layered aproach. That way you have less development work. But make sure you configure things correctly at each layer for what you are doing. That is with VoIP pick the right codec for encryption not transmission, whiten it correctly, and then encrypt it correctly. You can do the whitening and encryption as a push in software tunnel similar in idea to using stunnel on a loop back interface. Finally ensure that your VPN link encryption is correctly configured to link stuff to prevent the problems problems Nick P identified in his points list. And as always test thoroughly the test again when you break each bit in turn to find out the behaviour under fault… Oh and most importantly keep the user out of the loop they will break things in more ways than you can imagine, such as forgetting to switch from red to green mode and using the wrong keys etc etc etc.

[1] Iit is difficult to define the amount of redundancy in speach as it varies depending on what asspect you are trying to determin (actuall words, accent, identity, mode of speaking and thoughtfulness etc). For just the words we know from analysis of copious quantities of written text that English convays aprox 1.4bits per letter. Further we know the average word length for simplified “plain speak” is five letters per word, which is usually spoken at a maximum of four words per second and more normaly half this in ordinary conversation and about 1.33 words where clarity of meaning is being convayed. Thus 1.4 x 5 x 1.33 = 9.3 b/s to 1.4 x 5 x 4 = 28 b/s giving the aproximation used for effective millitary radio telephony of 10 bit / sec.

[2] In communications we frequently talk about the number of sent symbols per second (BAUD) which is then multiplied out by the number of bits of information per symbol to give the “bit rate” in bit’s per second (pbs or b/sec). However in information theory we general only talk about bits of information, whilst in computing we usually use Bytes and confusingly talk about data transmission in Bytes per second (Bps or B/Sec). Comms engineers frequently tend to be quite lax about the usage of baud, bps, b/psb Bps, B/ps and this has rubbed of backwards with the “specmanship” of modem manufactures in the 1990’s.

[3] Shannon’s original channel consisted of a transmission source and a receiver for the transmission, in the channel was a noise source which added uncertainty to the transmission and the channel also had a bandwidth which would by the process of Inter Symbol Interferance (ISI) limit the capacity of the channel to a theoretical maximum for the channel. However by exploiting the redundancy in the information being sent it is possible to compress data and thus appear to break the Shannon channel limit which in fact you are not [4]. Since Shannon’s original channel other atributes have been added such as delay, susceptability and emissivity to account for other issues such as nonlinear channel charecteristics and the actions of third parties with access to the channel in some form.

[4] Shannon defined redundancy in the channel as being the difference between the maximum channel capacity to carry bits of information and the actual information sent from the transmitter to the receiver. Thus a communicattions protocol might have start bits stop bits and parrity bits, they actually do not convay usefull information over and above the seven data bits thus although 10 bits are in the channel only 7 bits of information are transfered. However in Information theory the usuall meaning of redundancy gets turned on it’s head and becomes a meassure of possability, thus the more redundancy in a system the greater the possability it has to convey usefull meaning, Shannon thus chose to call it entropy not redundancy to try and distinquish the possability meaning from the more normal waste meaning of redundancy.