.General homomorphic encryption (16 Jun 2009)
If you've heard of Hal Finney, the following quote should be enough to get you to read: his explanation of the recent homomorphic encryption paper:
This is IMO one of the most remarkable crypto papers ever. Not only does it solve one of the oldest open problems in cryptography, the construction of a fully homomorphic encryption system, it does so by means of a self-embedding technique reminiscent of Godel's theorem.
Linux sandboxing with LSMSB (07 Jun 2009)
Chrome Linux got a dev channel release and I'm very happy with it. It's now my primary browser.
However, one of the big selling points for Chrome on Windows is that the renderers (which deal with decoding the HTML, CSS, image files etc) are sandboxed. We've had exploitable issues in the renderers which which have been stopped by the sandbox. It's a Good Thing.
However, we don't have a sandbox on Linux! The Mac team have been talking about how nice their sandbox is (and I expect we'll get some official documentation about it after WWDC this week). We have to hack around with SUID binaries, chrooting, seccomp and one-size-fits all SELinux solutions.
(I don't wish to discount the good work that the SELinux folks have done: we'll probably use something like that sandbox on Fedora, but Chromium was very carefully written to be sandboxed and we should aim higher.)
So, as part of the exploration of what we could do with sandboxing on Linux, longer term, I have a prototype implementation of LSMSB. It's another literate program of mine, so you can usefully read the source too. The README is included below:
This is LSMSB, a sandboxing scheme for Linux based on the ideas of the OS X
sandbox (which, in turn, was inspired by TrustedBSD and FreeBSD).
Imagine that you're working on a university computer and you get a binary which
promises to do some fiendishly complex calculation, reading from a file ./input
and writing to a file ./output. It also talks to a specific server to access a
pre-computed lookup table. You want to run it, but you don't want to have to
trust that it won't do anything malicious (save giving the wrong answer).
This code is incomplete, but currently you can take a sandbox specification
like this:
filter dentry-open {
constants {
var etc-prefix bytestring = "/etc/";
}
ldc r2,etc-prefix;
isprefixof r2,r2,r0;
jc r2,#fail;
ldi r0,1;
ret r0;
#fail:
ldi r0,0;
ret r0;
}
... and use it to remove access to /etc.
*** This code functions, but is incomplete ***
It's written in a literate programming style, but the derived sources are
included so that you don't have to bother with that in order to build. You'll
need a recent (> 2.6.30-rc1) kernel in order to apply the included patch. Once
you've applied the patch, drop lsmsb.c into security/lsmsb and rebuild.
You can assemble a sandbox file with:
./lsmsb-as sandbox-input.sb > sandbox
And then run a shell in the sandbox with:
./lsmsb-install sandbox
To read the code, see http://www.imperialviolet.org/binary/lsmsb.html
Chrome for Linux (04 Jun 2009)
Myself and the rest of the Chrome Linux team have been working hard over the past few months to get Chrome ported to Linux. It's certainly very rough still, but it runs and the first development release just got released.
I'm very happy with this and we should be pushing new releases frequently from now on. If you're in the San Francisco office tomorrow, feel free to pop by the office as I'll be bringing in champagne.
Just to be clear, here are some of the things which don't work:
- Plugins (so, no Flash)
- Complex text (this is my TODO, I just got distracted)
- Printing
- Much of the options UI!
W2SP and Seccomp (21 May 2009)
I gave a talk today at W2SP about opportunistic encryption. You would have to ask someone in the audience how it went to get a real answer, but I feel it went OK.
The talk was based on a paper that I wrote for the conference.
Also, LWN covered some recent work that I've been doing at Google with Linux sandboxing.
Moved to GitHub (09 May 2009)
I've finally manged to move IV off heeps, a server which it's been ticking along on for the last half decade.
In the process, I've moved to GitHub using their Pages system. We'll see how well it works out!
In the process I've cleaned out a lot of stuff and probably broken lots of links. I trust that the search engines will figure it all out soon enough.
I'll be at CodeCon this y... (09 Apr 2009)
I'll be at CodeCon this year.
Thanks to Alexander Sotir... (15 Mar 2009)
Thanks to Alexander Sotirov to pushing me to check that the carry chains in donna-c64 were sufficient. I don't know if I realised something when I wrote it which I'm currently missing, or if I just screwed up, but I now believe that they're wrong.
I wrote this Haskell code to check it:
This Haskell code has been written to experiment with the carry chains incurve25519-donna-c64. It's a literate Haskell program, one can load it into
GHCI and play along.
> module Main where
>
> import Data.Bits (shiftR, (.&.))
There are two constants that we'll need.
Our five limbs are, nominally, 51 bits wide, so this is the maximum value of
their initial values.
> twoFiftyOneMinusOne = (2 ^ 51) - 1
2^128 - 1 is the limit of the range of our temporary variables. If we exceed
this at any point, our calculations will be incorrect.
> two128MinusOne = (2 ^ 128) - 1
Now we define a type which mimics our 128-bit unsigned type in C. It's a
disjuction of an Integer and the distinguished value 'Overflow'. 'Overflow' is
contagious: if we try to perform any operations where one or both of the
operands is 'Overflow', then the result is also 'Overflow'.
> data U128 = U128 Integer
> | Overflow
> deriving (Show, Eq)
We make U128 an instance of Num so that we can perform arithmetic with it.
> instance Num U128 where
> (U128 a) + (U128 b) = mayOverflow (a + b)
> _ + _ = Overflow
> (U128 a) * (U128 b) = mayOverflow (a * b)
> _ * _ = Overflow
> (U128 a) - (U128 b) = mayOverflow (a - b)
> _ - _ = Overflow
> negate _ = Overflow
> abs a@(U128 _) = a
> abs _ = Overflow
> signum (U128 _) = 1
> signum _ = 0
> fromInteger = mayOverflow
> instance Ord U128 where
> compare (U128 a) (U128 b) = compare a b
> compare _ _ = EQ
This function lifts an Integer to a U128. If the value is out of range, the
result is 'Overflow'
> mayOverflow :: Integer -> U128
> mayOverflow x
> | x > two128MinusOne = Overflow
> | x < 0 = Overflow
> | otherwise = U128 x
Our field elements consist of five limbs. In the C code, these limbs are
actually uint64_t's, but we keep them as U128's here. We will convince ourselves
that we don't hit any 64-bit overflows later.
> data FieldElement = FieldElement { m0 :: U128, m1 :: U128, m2 :: U128,
> m3 :: U128, m4 :: U128 }
> deriving (Show, Eq)
Now, two helper functions:
This function takes only the bottom 51-bits of a value
> clamp :: U128 -> U128
> clamp (U128 a) = U128 $ a .&. 0x7ffffffffffff
> clamp _ = Overflow
This function drop the bottom 51-bits of a value
> topBits :: U128 -> U128
> topBits (U128 a) = U128 $ a `shiftR` 51
> topBits _ = Overflow
This function simulates the 'fsquare' function in donna-c64, including its carry
chain. If the carry chain is sufficient, then iterating this function for any
valid initial value should never overflow.
> square :: FieldElement -> FieldElement
> square e = result where
> t0 = m0 e * m0 e
> t1 = m0 e * m1 e +
> m1 e * m0 e
> t2 = m0 e * m2 e +
> m2 e * m0 e +
> m1 e * m1 e
> t3 = m0 e * m3 e +
> m3 e * m0 e +
> m1 e * m2 e +
> m2 e * m1 e
> t4 = m0 e * m4 e +
> m4 e * m0 e +
> m3 e * m1 e +
> m1 e * m3 e +
> m2 e * m2 e
> t5 = m4 e * m1 e +
> m1 e * m4 e +
> m2 e * m3 e +
> m3 e * m2 e
> t6 = m4 e * m2 e +
> m2 e * m4 e +
> m3 e * m3 e
> t7 = m3 e * m4 e +
> m4 e * m3 e
> t8 = m4 e * m4 e
>
> t0' = t0 + t5 * 19
> t1' = t1 + t6 * 19
> t2' = t2 + t7 * 19
> t3' = t3 + t8 * 19
>
> t1'' = t1' + topBits t0'
> t2'' = t2' + topBits t1''
> t3'' = t3' + topBits t2''
> t4' = t4 + topBits t3''
> t0'' = t0' + 19 * topBits t4'
> t1''' = clamp t1'' + topBits t0''
At this point, we implement two carry chains. If 'currentChain' is true, then we
implement the carry chain as currently written in donna-c64. Otherwise, we
perform an extra step and carry t1 into t2.
> result = if currentChain
> then FieldElement (clamp t0'') t1''' (clamp t2'') (clamp t3'')
> (clamp t4')
> else FieldElement (clamp t0'') (clamp t1''') t2''' (clamp t3'')
> (clamp t4') where
> t2''' = clamp t2'' + topBits t1'''
This is the maximum initial element: an element where all limbs are 2^51 - 1.
Inspection of the 'fexpand' function should be sufficient to convince oneself of
this.
> maxInitialElement :: FieldElement
> maxInitialElement = FieldElement twoFiftyOneMinusOne twoFiftyOneMinusOne
> twoFiftyOneMinusOne twoFiftyOneMinusOne
> twoFiftyOneMinusOne
This function takes two field elements and returns the worst case result: one
where the maximum of each limb is chosen.
> elementWiseMax :: FieldElement -> FieldElement -> FieldElement
> elementWiseMax x y = FieldElement (f m0) (f m1) (f m2) (f m3) (f m4) where
> f :: (FieldElement -> U128) -> U128
> f accessor = max (accessor x) (accessor y)
We now define a series of values generated by squaring the previous element and
setting any limb that is less than the maximum to the maximum value.
> maxSeries = iterate (elementWiseMax maxInitialElement . square)
> maxInitialElement
This value controls which carry chain is used in 'square', the current one or
the one with the extra carry
> currentChain = True
By running this, we can see that the current carry chain is insufficient for
this simulation:
ghci> maxSeries !! 4
FieldElement {m0 = Overflow, m1 = Overflow, m2 = Overflow, m3 = Overflow,
m4 = Overflow}
The series overflows after only four iterations. However, if we use the
alternative carry chain, the series is stable far beyound the requirements of
the Montgomery ladder used in donna-c64:
ghci> maxSeries !! 100000
FieldElement {m0 = U128 2251799813685247, m1 = U128 2251799813685247,
m2 = U128 2251799813685247, m3 = U128 2251799813685247,
m4 = U128 2251799813685247}
Additionally, these values are small enough not to overflow the 64-limb limbs.
Packet sizes in DNSSEC (08 Mar 2009)
Even when the DNS root hasn't started signing records, one can still use trust-anchors to employ DNSSEC for those TLDs which support it. Follow the links from Ben Laurie's latest blog post on the matter.
The .se ccTLD is one of those TLDs which support DNSSEC. You can test it with: dig +dnssec -t any se @a.ns.se. You'll see lots of NSEC, RRSIG and DNSKEY records. (DNSSEC is very complicated.)
However, the size of that reply is 3974 bytes long! All that from a request packet of 31 bytes. That's a very easy to use 100x DoS amplication. Of course, if you use mirror amplication like that, you cannot forge the source addresses of the flooding packets, making the flood easier to filter. However, DNSSEC may well bring DoS floods into the reach of many more attackers.
When I wrote curve25519-d... (08 Mar 2009)
When I wrote curve25519-donna I implemented many of the critical functions in x86-64 assembly. It was a lot of code, even using the C preprocessor! This got a good 20% boost in speed. This was clearly very important because it made donna-x86-64 faster than djb's version 
.
However, djb just pointed out that the 64-bit C implementation of donna was now as fast as my hand coded version. Turns out that GCC 4.3 greatly improved the quality of the code generation for this sort of code and now equals my hand crafted efforts! Well done to the GCC team because the C code is vastly smaller and easier to understand. Thus, the x86-64 of donna has been removed from the repo.