Schneier on Security

Clive Robinson • January 29, 2010 11:18 AM

@ MemVandal,

“And the other point is that your IP reveals quite more info than such fingerprints.”

Err that depends.

Mobile phone companies and some wireless broadband suppliers use NAT, that is they put anything upto 300 active devices to one IP address.

Which is why all SysAdmins (Hey Moderator you to) should log the port numbers as well…

If you want to know more got to lightbluetouchpaper sight and read Richard Clayton’s posts on the issue of NAT.

Clive Robinson • January 30, 2010 7:36 AM

@ jacob,

“Could an OS be used for a crypto attack? How many configurations could there be? The plaintext part of the equation.”

Oddly I’ve sort of answered this not so long ago on this blog (cann’t remember which threads though).

As regards,

“But anything that uses a key would be vulnerable.”

Sort of, it depends on a number of things (it might be multiple keys, certain operating modes and a few others besides).

“It seems logical to me but there are times when logic is a foreign language to me.”

No your logic is fairly ok on this one, there are however things and assumptions that change the base of the argument both for and against.

In essence you are talking about a “Known Plaintext” attack to recover a single key.

The answer usualy given is,

Modern encryption has too many key bits (ie large key space) to be brut forced thus it is a non issue…

What they don’t say is that it is a gross generalisation based on many assumptions.

The base of the argument is that you would need to go through each and every key trying to find the right key and that this is time consuming to do.

Well yes and no, as with Rainbow Tables you can turn it into a dictionary attack.

That is you encrypt you known plain text under every possible key once and store the results in a database (table) of some kind.

Thus do the time consuming task once and save it thus doing a quick and simple look up the next time etc (The so called British Museum attack).

Well the good news is the Universe does not have sufficient time to do it, nore sufficient atoms for storage with 128bit AES we think (and Bruce did say he was going to keep an eye on that dark matter stuff just in case 😉
The bad news is nobody would do it this way as it’s a worst case bound on the problem (which is why it’s used as a benchmark by which other methods are measured).

There are time / storage trade off’s that can be done for smaller key sizes and software can easily be rigged to only use a subset of the actual key space (and hardware as well can be rigged).

Worse a lot of code limit’s the key size already just by people beliving in the “magic pixie dust” of determanistic processess like MD5 hashes etc.

The real issue is the entropy source used to get the initial seed used to make the key.

Irrespective of what you do determanisticaly with it afterwards the starting entropy remains the same. Thus a 128bit key only based on 32bits of entropy is within a home constructors budget today (hence Rainbow Tables).

There are however other trade offs with “known Paintext” attacks. That is sometimes you can pick the “plaintext” you get encrypted this is known as a “chosen plaintext” attack.

Usually systems are designed to prevent a chosen plaintext attack but an entire OS partition under a “codebook” or other weak mode is likley to offer much in the way of fruitfull oportunities, if they have not been deliberatly planted already (NSA conspiracy No 57 ;).

Perversly strengthening against one chosen plaintext attack method appears to make other attacks easier. That is there may be an as yet unknown optimum cusp for a basic cipher such as AES.

The upshot is two different methods are likely to have a collision which gives a “birthday paradox” type advantage.

Which gives rise to a question you don’t hear spoken very often. It two different (orthagonal) “chosen plaintext” attack methods can potentialy have the effect of halving the number of bits (ie 128 down to 64) what would happen with 4 orthagonal methods would it potentialy halve it again to 32bits?

The answer is we don’t know for certain we just (hope/assume) not.

So the question then arises, are their any defences against “chosen plaintext” attacks with hard drive storage?

The answer is yes there are but…

And there are a lot of but’s most of which are to do with cipher modes not the ciphers themselves.

A simple solution for communications is cipher chaining or cipher feedback that is you use the plaintext or ciphertext feedback or forwards to make the mode non codebook. However this generaly only works for a sequential access system not a random access system which a hard drive tends to be…

Worse for speed some people build what is in effect a stream cipher as this allows precomputation of the running key in slack time thus giving speed enhancments. The problem with this is that most hard drives have multiple copies of the same file etc which makes key re-use with known plaintext virtually certain (think about issues with backup tapes etc).

The simple fact is that HD encryption is a very difficult subject with lot’s of gotchers for the unwary. Any one of which may obviate the assumptions that give rise to the belived security…

That said there are a lot of bright people looking at these things to get their doctoral and other wings.

And less and less chose the faustien bargin (of if you know what we know) to hop behind the hedge of Government work these days. And even the NSA has droped hints we may be progressing faster in an open world than their closed world (then again who knows).

Clive Robinson • February 2, 2010 4:33 PM

@ Peter Eckersley,

“We’ll do some fancier post-processing of the data to better break down correlations between the variables, reduce multi-counting of people who block or delete cookies…”

Thought for you.

Next time you run such an experiment, how about running it twice.

That is you have two DB’s the first time somebody runs their machine against it their record gets put in both DB’s, the second and all subsiquent tries into the second DB only.

The displayed results can be against both DBs.

You would have less data cleanup to do, and also you could draw other conclusions about the people who make subsiquent visits, such as if they are legitamatly trying to reduce their profile by changing their browser etc, or if they are just being silly and putting duplicate entries in the second DB.

One thing I am curious about is what are you going to do with data from people who’s browsers failed to run the tests, or came from a block of IP addressess asigned to mobile phone / broadband companies who may put upto 300 individual “hosts” behind a single IP address (NAT on Overkill 😉

Clive Robinson • March 27, 2010 3:57 AM

@ Rubble Barney,

“When mobile users surf the Web they also may be inadvertently disclosing their phone numbers, a security researcher said Thursday”

They are right but this has been known about for well over two years…

Basicaly the mobiles web browser includes either the phone number or one of the electronic identities of the phone.

It is why using a “web enabled” mobile phone as the “side channel” for user and transaction authentication not the good idea it was 10years ago. Because the chances are the phone user will use the same phone for both browsing to the “phishing site” and getting the SMS etc authentication token…

And still the industry does nothing about it.

@ Bruce,

Oh and something else about the IP address of mobile users, which web site owners SHOULD know and TAKE NOTE OF it’s “unreliable” as a method of tracing back you need to record all the port numbers used in the logs as well as the time.

The reason for this is the phone companies have a very limited number of IP addressess so they use “Super NAT” and overload a single IP address by as much as three hundred concurrent users…

It has also been said (but I’ve not seen evidence of) that the “Super NAT” can also cause a mobile phone to have two or more different IP addressess if they are going to two or more sites at the same time (that is the IP addresses are handed out on a transaction basis as part of a “round robbin hunt group” as each IP address reaches capacity.

For obvious reasons this may well cause some interesting side effects for web pages that get a users browser to download page parts from different servers etc…