Julian Assange on Cryptographically-deniable Block Storage Device (aka Marutukku)
THE original page of the archive has not been online for years, but it was captured by the Wayback Machine and the Internet Archive is now at risk due to litigation. So today we reproduce a message sent nearly 25 years ago by Julian Assange, proposing secure transmissions:
From: Julian Assange <proff@i...> Subject: call for ocaml volunteers
For some time now, our group has been working on a cryptographically-deniable block storage device (aka Marutukku), on which regular file-systems can be mounted, targeted at the human/activist community. We expect to release a developers code set at the Usenix Security Symposium in Denver next week.
This is like a regular encrypted disk except that it supports multiple keys, where it is computationally infeasible given some of those keys to show that there are more keys, or that particular blocks of data are being used to store something other than unallocated space. Even for the legitimate user.
This mitigates against coercive interrogations and legal compulsion. Only "safe" information need be revealed. It isn't possible to show that additional information exists. Nor is it possible for the subject of a coercive demand to show that they have revealed all information. Thus a rational coercer can never demand proof of full co-operation, as its provision is computationally infeasible.
We have assorted kernel modules for Linux, NetBSD and FreeBSD. Although these modules are designed to abstract away OS primitives and provide a fast kernel<->userland messaging layer so the effort involved in porting to other operating systems is minimised.
However there are ways to protect against coercive interrogations that can be layered on top of cryptographic deniability and this is where Ocaml comes in. Keying schemes can be chosen that have beneficial psychological or psychological properties. These novel keying schemes are often graphical in nature and so Ocaml's ability to produce simple portable stand-alone graphics executables are spot on.
At the moment we have a passphrase-based keying feeding into a sophisticated key set up routine (that enforces 1 second of original cpu time per attempted key). However, passphrase based keying is non-optimal under many circumstances that the target group (human rights workers) might encounter, because passphrases can be quickly conveyed by speech or writing. That is:
1) Interrogations can take place in room101 and not the computer room. It's nicer, particularly given the frequency of equatorial despotism to be tortured in the computer room.
2) Revealing a passphrase only requires (some of) the brain and jaw or hand to be left functional.
3) Revealing a passphrase is quick and requires few higher cognitive functions, thus it is vulnerable to peak pain, hallucinogens and `truth drugs' such as schopolomine.
4) A single observation of a passphrase is enough grasp the whole keying state. Keyboard sniffers are cheap and in Australia at least, video bugging is not uncommon.
A good keying system prevents revealing of the key, placing the subject of interrogation in a hostile environment (i.e not the computer room), damage to as many parts of the subject's body as possible, retardation of the subjects mental faculties and retardation of the subject's free will. The keying system should also be practical enough to be used and adopted by real life people, and not require expensive or hard to find hardware.
Where a group of co-operating individuals is concerned, keying schemes should discourage defection against the group of individuals being coersively interrogated. Marutukku cryptographic deniability discourages defection due to the subject's inability to show that they have fully compiled with the interrogation (thus the incentive to defect, or at least defect completely, is minimised), but perhaps novel keying schemes can augment this.
It is important to understand that maru requires keying and not authentication. However any authentication method can be turned into a keying method, provided sufficient information for the authentication isn't held on the "server". For an example, maru could issue n challenges, each of which which the user's authentication algorithm authenticates or fails to authenticate; the hash of the concatenated authenticated challenges then forms the key. However schemes like this require n to be >=48, which seems practical only for automated methods, or combined with another method which presents more bits of key entropy per iteration.
Some possible alternatives to passphrase based keying (we have some more notes on these ideas, but no code or concrete design documentation):
1) interactive transposition matrixes. This is a simple method to prevent keyboard immediate keyboard sniffing. The user keeps their passphrase in their head, and a for each letter a transposition matrix is displayed on the screen.
2) Maze walking. A maze with several "landmarks" is drawn on the screen. The user must "visit" and move past these landmarks in a particular order and direction. 3) Enhanced face recognition. Several arrays of faces are displayed. The user must choose the numbers next to each face, perform a simple mathematical operation on them and input the number.
4) Constraint/simile problems. The user is presented with several secret knowledge problems of A is to B as C is to in different forms which test areas of cognitive function and or visual function which would be affected by drugs or severe pain.
5) Grid drawing. The user draws shapes within a n x n matrix. The direction of boundary crossing forms the key. For a similar idea, see "Graphical Passwords", a paper presented at last years usenix security symposium.
6) Colour contrast discrimination. It has been shown that individuals see slightly different hues due to visual cortex and cone cell / retina retina variation. It maybe possible to design moire or other tests on 24 bit displays which are recognisable by one party but not another. Just hope no-one runs a magnet over your monitor :)
7) Forward Error Correction based biometric keying. Traditionally signature and individual biometric variation tests have failed to provide good alternatives for keying, for two reasons. 1) the bio-authorisation template is "secret", hence useless for something like marutukku, where *all* secrecy is derived from the key. 2) quantitisation by the template of the inherent analog variability in the biological source in order to match with the template dramatically reduces the keyspace. A FEC based approach may resolve these issues.
Our current designs for plugable keying mechanims, simply introduce saved state on stdin and expect output state (which is subsequently hashed to form the key) on stdout.
What follows is a proto-type of 5.
As novel keying methods are an intresting problem that requires lateral thinking rather than specialist cryptographic expertise, I thought it may be of interest to ocaml coders in general.
(* keygrid (c) 2000 Julian Assange <proff-copyright@iq.org> *)
open Graphics open Pervasives
let win_x = 400 let win_y = 300 let pi = 3.1415926951 let divisions = 6 let fdivisions = float_of_int divisions let sub_xy (x,y) (x',y') = (x -. x', y -. y') let scale x s = int_of_float(x *. (float_of_int s)) let scale_xy (x,y) = (scale x win_x), (scale y win_y) let rscale x s = (float_of_int x) /. (float_of_int s) let rscale_xy (x,y) = (rscale x win_x), (rscale y win_y) let cell_of_xy (x,y) = int_of_float (x*. fdivisions +. (floor (y *. fdivisions)) *. fdivisions ) let xy_of_cell cell = ((float_of_int (cell mod divisions)) /. fdivisions), ((float_of_int (cell / divisions)) /. fdivisions) let openwin () = open_graph (":0 " ^ string_of_int win_x ^ "x" ^ string_of_int win_y) let line xy0 xy1 = let (x0',y0') = scale_xy xy0 and (x1',y1') = scale_xy xy1 in Graphics.moveto x0' y0'; Graphics.lineto x1' y1'
let drawgrid () = let f x = (float_of_int x) /. (float_of_int divisions) in for n = 1 to divisions do line (0.0,(f n)) (1.0,(f n)); line ((f n),0.0) ((f n),1.0) done
exception Restart
let vectorise (x0,y0) (x1,y1) = let len = sqrt ((sqr (x0 -. x1)) +. (sqr (y0 -. y1))) in let angle = pi /. 2.0 +. asin ((x0 -. x1) /. len) in (angle, len)
let rec bordercross xy stat = let mstatus = Graphics.wait_next_event [Mouse_motion; Button_down; Button_up; Key_pressed] in let stat' = if Graphics.button_down() then `Following else `NotFollowing in let xy' = rscale_xy (mstatus.mouse_x, mstatus.mouse_y) in if mstatus.keypressed then if mstatus.key = ' ' then raise Restart else [] else let cell = cell_of_xy xy in if stat = `Following then let cell' = cell_of_xy xy' in line xy xy'; if cell != cell' or stat' = `NotFollowing then let (theta, len) = vectorise (xy_of_cell cell) (xy_of_cell cell') in (cell,cell') :: bordercross xy' stat' else bordercross xy' stat' else bordercross xy' stat'
let rec print_xovers = function | [] -> [] | (a,b)::tl -> print_string ((string_of_int a) ^ "->" ^ (string_of_int b) ^ " "); print_xovers tl
let main () = openwin(); let rec loop() = Graphics.clear_graph(); Graphics.set_color (rgb 0 0 200); drawgrid(); Graphics.set_color (rgb 200 0 0); Graphics.moveto 8 15; Graphics.draw_string "Draw secret. Press return when complete, or space to start over."; Graphics.set_color (rgb 0 0 0); try bordercross (0.0,0.0) `NotFollowing with Restart -> loop() in let xovers = loop() in let xovers' = List.stable_sort (fun (a0,a1) (b0,b1) -> a1 - b1) xovers in let xovers'' = List.stable_sort (fun (a0,a1) (b0,b1) -> a0 - b0) xovers' in print_xovers xovers'' ;;
main()
That was the year 2000.
How time flies. I was a student at the time and "war on terror" was not yet going on in Iraq. No 9/11 (yet), either. No PATRIOT Act. █