]]>
Lost hand truck]]>
Is bad luck
But mimic
Is comic.
The Carol of the Cultural Cringe The drover rides across the plains. Westward on he leads his flock, Through bushfires, droughts and flooding rains, Past billabongs and deep red rock. At night by fire he lays his head, The Southern Cross shines overhead... Oh, by the way, it's Christmas. Deep in the bush, the wombats play, While serenaded by the crow. The kangaroos, they hop all day. I emphasise: There is no snow! The ground is parched; the Sun' harsh rays Have beaten down for days and days... And, by the way, it's Christmas. While here in town, we gather 'round The barbecue and burn some meat. In laundry tub the salad's found, We swat at blowflies as we eat Together, the Australian way... And almost I forgot to say That, by the way, it's Christmas. Copyright 1999 Andrew BromageMerry Christmas!]]>
]]>
COLOSSUS was the world's first programmable electronic computer, so this is considered something of an achievement. However, COLOSSUS was really only built to do one job.
Read on for details.
]]> Message integrity The BBC article notes:Speaking to the BBC, Andy Clark, one of the founders of the Trust for the National Museum of Computing, said radio problems had stopped the challenge getting under way on time. "The radio path has not been particularly good between Germany and here," he said. "We are at a bad point in the sunspot cycle."This highlights one of the trickier problems in information theory: ensuring that a message gets from Alice to Bob without loss. In the digital world, we use redundancy coding: Sending as small an amount of redundant information as necessary to at least detect message corruption (e.g. checksums, hashes, digests). If Bob finds an error in Alice's message, he can send an automatic repeat request (ARQ), and Alice can repeat the message. Some fancier schemes attempt to correct the error. This is useful in situations where ARQs are infeasable or otherwise undesirable. One example is real-time signals (e.g. mobile phones), where a retransmission would come too late. Another is stored media, such as CDs and DVDs. An exotic application is deep space probes: The last telemetry signal from Pioneer 10, for example, was at about 80AU. A round-trip signal would therefore take 21 hours or so, and that's assuming that the probe could even hear you at that distance. So if you're ever designing spacecraft, you really want to avoid ARQs if you can. If it's not important that you get all of the information just so long as you get enough of it, then another option is to use synchronising codes. If a symbol does not depend on the symbol before it, then you can drop symbols (and timing can tell you that they've been dropped), and you'll get at least some of the message. So while you may not (deleted) everything, the (deleted) can be often be (deleted) from the context.
Consider the following problem: What is the probability that any two symbols chosen at random are the same?
A moment's thought shows that it's just this:
We call this quantity the index of coincidence (or IC) for the probability distribution.
You can estimate the IC for a distribution by looking at a stream of symbols that follows the distribution. Consider, for example, the following text:
YOUCA NESTI MATET HEICF ORADI STRIB UTION BYLOO KINGA TASTR EAMOF SYMBO LSTHA TFOLL OWSTH EDIST RIBUT IONCO NSIDE RFORE XAMPL ETHEF OLLOW INGTE XTThe message contains 8 A's, 4 B's, 3 C's and so on. Denote the number of instances of A as [tex dpi=72]n_A[/tex], and the length of the message as [tex dpi=72]n[/tex]. The number of pairs of symbols in the message is given by [tex dpi=72]n(n-1)/2[/tex]. Similarly, the number of pairs of A's is [tex dpi=72]n_A(n_A-1)/2[/tex]. It follows that the IC for the message as a whole is:
Which comes out at approximately 6% for this message.
The reason why the IC is interesting for cryptographers is that it is invariant under a number of common transformations. If you apply a simple substitution cipher to a message, for example, or permute the symbols arbitrarily, the measured IC of the message is the same. It's also approximately the same if you take a random sample of the symbols from the message.
Moreover, the IC is approximately constant for a given language. English messages have an IC of around 6.6%, and German messages have an IC of around 7.8%. Compare this with the IC for a 26-symbol alphabet where the probabilities are equal (i.e. random noise), which is 1/26 or 3.8%. Friedman's Law states that for natural Roman alphabet-based languages, the ratio of the IC for the language to the IC for a flat frequency distribution is approximately 2. (For English it's 1.73, and for German it's 2.05.)
One particularly interesting property of this is that you can often tell if you've "almost" cracked a cipher by looking at the IC. If it's close to 3.8%, you're not there yet. If it's close to 6.6%, then you might still need to undo a permutation and substitution, but you know the message is probably in English. Indeed, it's sometimes easier to tell what language some cipher is written in than to decode the message.
Stream ciphers have the property that given the same position in the same stream, two plaintext symbols are encrypted to the same ciphertext symbol. It follows that if you take two different messages, written in the same language, encrypted using the same key sequence, then the proportion of symbols which match at the same positions should be roughly the same as the IC for the language.
Here's an example. Two messages encrypted using the same stream cipher using the same key sequence. Message 1:
MUAOQ OPOAY GQTSS YDJEL QQNLS ZPZVS XGTOI YLCYN BKBKU CJNAT IQXPE LMSKM KPRJF GDWBA WCRYZand message 2:
XYPND HJMSM MGKSP NZYTC WDUUW VTGVV XRJSK FSYJR BNFUB IQGBH OCPIV MIUBD QHOSZ JTEFF HFUJXThe measured IC of message 1 is 3.3%, and of message 2 is 3.4%: both close to what you'd expect from a flat distribution. But if you line them up against each other, and look for places where the ciphertext letters are identical:
MUAOQOPOAYGQTSSYDJELQQNLSZPZVSXGTOIYLCYNBKBKUCJNATIQXPELMSKMKPRJFGDWBAWCRYZ
XYPNDHJMSMMGKSPNZYTCWDUUWVTGVVXRJSKFSYJRBNFUBIQGBHOCPIVMIUBDQHOSZJTEFFHFUJX
^ ^ ^ ^
The messages are 75 symbols long, and there are 4 coincidences. That gives an estimated IC of 4/75 = 5.3%. That's not a great result because the message is so short, but it's certainly closer to a natural language than to random text, so this is good evidence that the two messages were encrypted with the same stream cipher.
If you're curious, I encrypted them with an ENIGMA emulator. In the very early 1930s, mathematicians at the Polish Cipher Bureau noticed that if you took two German ENIGMA messages, intercepted on the same day, which began with the same six letters, the IC of the rest of the messages (i.e. after the first six letters) was very close to that of German. They concluded that the first six letters specified the key, and the rest was a polyalphabetic stream cipher. This was the first break in ENIGMA. But that's another story.
We're more interested in TUNNY.
This one isn't Haskell-specific, but it is based on a perennial Haskell discussion: The efficient computation of Fibonacci numbers.
So without further ado...
Original photograph by MyRabbits
]]>The executive summary: Andy's reasoning is 100% correct, and so is Shamir's assertion (in the paper) that the method does not leak information.
Read on for details.
]]> First off, if you haven't read the paper, please do it. It's extremely short, and quite readable. You'll also need to have read Andy's article before reading further.Essentially, the problem is this: You have a secret number, [tex dpi=72]A_0[/tex], that you want to share. You want to split it into [tex dpi=72]n[/tex] pieces such that you need at least [tex dpi=72]k[/tex] of those pieces to reconstruct [tex dpi=72]A_0[/tex]. If you only have [tex dpi=72]k-1[/tex] pieces, you can discover nothing at all about [tex dpi=72]A_0[/tex].
Shamir's method solves this problem by generating random numbers [tex dpi=72]A_1 \ldots A_{k-1}[/tex] and forming a polynomial:
The "pieces" are [tex dpi=72]n[/tex] distinct points on this curve, but not zero. Given [text dpi=72]k[/tex] points, you can reconstruct the polynomial and hence determine [tex dpi=72]A_0[/tex].
So far, so good. However, does this method guarantee that given fewer than [tex dpi=72]k[/tex] points, you can't determine anything about [tex dpi=72]A_0[/tex]?
Andy points out that using the example on the Wikipedia entry, you can find out something about it.
Andy is right. If anything, it's the Wikipedia page that's misleading.
Here's the relevant part of the Wikipedia example, which has a problem in it:
Suppose that our secret is our ATM code: 1234 (S=1234) [ed: that's [tex dpi=72]A_0=1234[/tex] in our notation]. We wish to divide the secret into 6 parts (n=6), where any subset of 3 parts (k=3) is sufficient to reconstruct the secret. At random we obtain 2 numbers: 166, 94.
Did you spot the problem?
No? Here's that last sentence again:
At random we obtain 2 numbers: 166, 94.
This is an instance of the famous two envelopes problem. Essentially, the problem here is that for Shamir's system to be secure, you need to pick two positive integers completely at random. The problem is that it's not possible to pick two arbitrary positive integers in such a way that every integer is equally likely to be chosen.
The reasoning is simple: Suppose I pick x and y completely at random, and each positive integer has an equal probability of being chosen. There are a finite number of positive integers less than or equal to x, and an infinite number greater than it. So with probability 1, y is greater than x.
But by analogous reasoning, with probability 1, x is greater than y. This is a contradiction, so the assumption that it's possible to choose integers in such a manner is false.
The Wikipedia page misses a very important point in the paper:
To make this claim more precise, we use modular arithmetic instead of real arithmetic. The set of integers modulo a prime number p forms a field in which interpolation is possible.
In fact, this condition is overly-restrictive and, in fact, impractical. If the secret is a number between 0 and N, then we need to find a prime number bigger than N to use as our modulus. If N is large, then finding a prime is hard. (Probabilistic techniques exist for finding large things that look enough like primes for RSA to work, however, if you turn out to pick a non-prime, then you get a non-field, and interpolation doesn't work.) However, thanks to Galois, we can easily construct finite fields with at least as many elements as we need. In particular, you can always form a field with [tex dpi=72]2^b[/tex] elements for any [tex dpi=72]b[/tex]; for computer implementations, this is invariably the most convenient finite field to work in. (It's what they use in Diffie-Hellman key exchange, for example.)
So let's look at this again, this time using a smaller example.
Suppose that we're working modulo 5 (which is a prime), and the secret that we want to share is 2. We want to split this into three parts, such that you need two parts to reconstruct the secret.
We pick a random number between 0 and 4 (because we're working in a finite range, the two envelope paradox doesn't apply). Let's say it's 1.
So we form our polynomial:
Let's suppose that we know the value of [tex dpi=72]f(1)=3[/tex]. What do we know about [tex dpi=72]f(0)[/tex]?
The answer is: Nothing.
Why? There are five possible polynomials that satisfy [tex dpi=72]f(1)=3[/tex], all of which have different values at 0, and they're all equally likely.
Work it out and see.
The same reasoning works for any finite field, but for the moment, we'll stick with "sufficiently large prime".
Andy argument contains, in part:
Because [tex dpi=72]g(0)[/tex] is a positive integer, we know that [tex dpi=72]D_1 > 1000[/tex], and that [tex dpi=72]D_1[/tex] is a multiple of 2.
It should now be obvious why Andy's argument doesn't apply in arithmetic modulo a sufficiently large prime: All sufficiently large primes are odd, and when working in such a modulus, just because a number is multiplied by 2, that doesn't make it even. In our example, we used modulo 5. What's 3 times 2 modulo 5? Is it even or odd?
It gets more complicated in arbitrary fields (and I wish I had the time to go into Galois fields a bit further), but this is basically all you need to know: When working with fields, the concept of "divisibility" doesn't come up. In a field, every number can be divided by any other non-zero number. Using the most familiar example of a field, the rationals, you can see that It doesn't even make sense to ask if 2/3 is even or odd. The same thing is going on here.
Anyway, it's 2am. I hope this helped. Feel free to ask any questions.
And I expect that somebody will probably fix the Wikipedia example soonish.
]]>