Etc network Blog and News

 Fri, 12 Mar 2010

I am using an iphone (I am forced to by my company) and I can't jailbreak it (I am kept from doing so by my company, and I don't really want to start fighting with Apple over the control of their own products; android or nokia linux phones let you do that without a fight).

But there is a way to use an iphone as a linux modem without jailbreaking them: install windows in a VMWare or VirtualBox jail, hand the iphone to it, let itunes do the dial-up, and share the network with the host. Here is how: [pdf], [odt].

I played a while with VMWare network setup, and I found out that bridging is a dead end: There is no reason why the Windows guest shouldn't be DHCP client and default gateway to the Linux host at the same time, and bridging is messy, whereas host-only and NAT work out of the box. So... don't do anything like this:

vmnet-netifup -d /var/run/vmnet0.pid /dev/vmnet0 vmnet0
ifconfig eth0 192.168.137.2 up
route add default gw 192.168.137.1

It worked, and I learned a lot about bridging, but I'm still not sure this is how it's supposed to be done, and it's easier to make windows an ordinary gateway instead of one end of a bridge.

 Fri, 06 Mar 2009

Worried about the exploding complexity of distributed computer applications? About the desastrous quality of the code that is used, and the breath taking track record of exploit incidents and gaping security holes? The solution is very simple: Get some more money, and then plug in yet another layer of complexity, route all your data in the clear through a company that is not only yet another point of failure, but an extremely juicy target for those people who didn't even want to attack you before.

 Wed, 04 Feb 2009

Sometimes, when im am searching freashmeat.net or when I play with stuff from there, or when i see debian further diffuse formerly somewhat clean abstraction layers into one big hairy smelly mess (greetings to the dbus team :), I think that closed source software is no worse than open source in terms of robustness and usability. But right now I think there is this: If a piece of software is open source, it's more likely that the people who wrote it had fun, which usually doesn't happen in software companies that think they are manufacturing cars in 1940ies Detroit. And fun seems to be more crucial when it comes to writing software than when it comes to assembling cars (because writing software is more like inventing cars, which also should be fun or just won't work). You can probably buy five books in three minutes that make that claim, and I've probably read it somewhere myself. But now I bring you newly collected support.

I have compiled a check list for software engineers who are about to build scroll bars into their user interface. It doesn't look like deep insights to me now, but I found all seven points violated in a single application. In places where inventing cars is confused with assembly line work, it's just state of the art.

  1. length of scroll bar: make it arbitrary, but make sure that most of the time (not all the time, that would be consistent) it misleads the user about the length of the window that she can scroll with the bar. if the window is very long, make the scroll bar very long, too, and vice versa.
  2. make the window much longer than the content by adding lots of empty space.
  3. play with superflous horizontal scroll bars for windows that have only two lines of text that both easily fit into the visible part of the window. make those scroll bars very very short, so they more the window very slowly. or combine with the last point.
  4. too much direct feedback is bad: do not build scroll bars that move the window while the user moves them. make sure moving the scroll bar has only an effect on the window after you release it in a new place. this makes it tedious to scan through the entire window without skipping anything and without too much overlap. (CAVEAT: some users try to deal with non-interactive scrollbars by using the page up/down keys, or the buttons you provide at the ends of your scroll bar. don't forget to check that those don't auto-repeat if you hold them down, and that they have steps that are either to wide (1.7 pages, or 1.1) or too narrow (1 line). if the user decides to hit a key and you decide to honor it, make the GUI stall for at least one second afterwards, and swallow all key strokes during this time. same rules apply to the mouse wheel.
  5. if the window contains a list, give some thought to search and sort functions. never provide both, occasionally provide none, where you provide it make sure it's messy. example for messy: On pressing the search button, make the user enter a search term into a popup window, then open another popup-window with the search results, make the user click on one of those, and then move the scroll window to three lines above or below the location where that result would actually be visible. default sort should always be the most useless and counter-intuitive possible, not just something random or arbitrary. reset to that counter-intuitive default state as often as possible.
  6. nest several windows that all have their own scroll bars, and make each of them slightly smaller than the one containing it, so the user has to move all scroll bars simultaneously to scan with her eyes through everything. make some of the contained windows much smaller than the containing window, with no possibiltiy to expand it, so that a lot of space is wasted while you have to scroll through a tiny spot in the upper left corner of your screen.
  7. remember to forget to provide scroll bars altogether every now and then. sometimes, only being allowed to browse with page up/down keys or buttons is painful, too, especially when you are using a web application on a java portal that has response times of over 10 seconds.

 Tue, 03 Feb 2009

requirements:

 - api: "add " (register stuff for backup), delete path
   (unregister stuff), drophistory path (delete all obsolete versions
   of stuff in the backup system to save space), sync repo (bring
   backup up to date), recover (you should never forget that part :-).

 - network connection may be slow (hotel-dsl-to-home-dsl, or worse),
   sync may be interrupted.

 - server is not trusted and can only see encrypted content.

 - files may be large and immutable (movies) or small, plenty, and
   volatile (source code)

 - backup is versioning: if you don't call drophistory, nothing will
   ever be forgotten.


tools allowed:

 - mtn (www.monotone.ca), apso (aleph0.info/apso)
 - cryptsetup (linux crypto images)
 - openvpn
 - rsync
 - nfs (bah!)
 - anything, if the solution is elegant.


ideas:

1. mtn/apso repository on 300GB usb drive.  sync from laptop to that
   drive, then on to the net whenever convenient.  checkout and commit
   scripts that feel like you copy stuff from external drive to laptop
   and back.  this lets you store roughly 300GB of data on the drive,
   minus what you change.  (don't change movies!)

   MISSING:
    - understand apso.
    - checkout and commit scripts.
    - delete movie file from repo so that repo actually forgets it and
      shrinks.  (more general, but probably needed: forget change
      history of path.  see api requirent above.)

   PRO:
    - very simple, nearly done.

   CONTRA:
    - backup server needs to run monotone.  this probably makes
      abusing gmail harder.
    - apso security lower than cryptsetup?  perhaps not.
    - requires 300GB space somewhere.  something more fine grained and
      easier to distribute would be nice.

   DECISION:
    ?


2. store crypto image on 300GB usb drive.  backup to that and make
   sha1 index for additional sanity checks.  (good if your hard drive
   is cheap and fucks up.  the reason i am writing this is that that
   is happening to me.)  rsync the encrypted image to backup server
   with --backup and --inplace.  this means server needs 600GB memory,
   but rsync to server is robust and fast.

   MISSING:
    - 600GB server.  (-:
    - answer this: what happens if the rsync is interrupted, the usb
      drive is changed, and the rsync is resumed on the obsolete
      state?

   PRO:
    - very simple, nearly done.

   CONTRA:
    - waste of space.
    - if usb drive gets corrupted (and it can get corrupted rather
      badly cause it's usb), server backup gets corrupted.

   DECISION:
    nope.  consistency is too important.


3. hm...  could we compute the diff of the 300GB crypto image somehow
   without having a copy of the server version?  then we could upload
   diffs.  yes, we could keep two 300GB usb drives, use bsdiff(1) to
   compute the patches, and then rsync to keep them in sync.  (and a
   simple script and sha1 to keep paths marked as "immutable" from
   being fucked up by stupid usb bullshit.  fuck.)

   MISSING:
    - the immutability script (easy: drive A is updated, drive N
      contains previous state.  refresh sha1 index file on A.  diff
      with sha1 index file on N.  intersection of hits with list of
      immutable paths must be empty.)

   PRO:
    - very simple, nearly done.

   CONTRA:
    - is bsdiff good?

   DECISION:
    ?


4. after I got that far, I called "apt-cache search" and found these:

   duplicity - encrypted bandwidth-efficient backup
   pdumpfs - a daily backup system similar to Plan9's dumpfs

   afbackup - Client-Server Backup System (Server side)
   amanda-client - Advanced Maryland Automatic Network Disk Archiver (Client)
   backup2l - low-maintenance backup/restore tool for mountable media
   backup-manager - command-line backup tool
   backup-manager-doc - documentation package for Backup Manager
   backupninja - lightweight, extensible meta-backup system
   backuppc - high-performance, enterprise-grade system for backing up PCs
   bacula - network backup, recovery and verification - meta-package
   boxbackup-client - client for the BoxBackup remote backup system
   cedar-backup2 - local and remote backups to CD or DVD media
   chiark-backup - backup system for small systems and networks
   chiark-scripts - chiark system administration scripts
   dirvish - Filesystem based backup system using rsync
   faubackup - Backup System using a Filesystem for Storage
   flexbackup - Flexible backup tool for small to medium sized installations
   multicd - Backup your data to CD-R/CD-RW
   nilfs2-tools - Continuous Snapshotting Log-structured Filesystem
   partimage - backup partitions into a compressed image file
   rdiff-backup - remote incremental backup
   rdup - utility to create a file list suitable for making backups
   rsnapshot - local and remote filesystem snapshot utility
   shrinkta - DVD backup tool
   slbackup - Skolelinux Backup system

   PRO:
    - completely done.  :)

   CONTRA:
    - must read documentation of other people's code...

I think i will look into duplicity first, then pdumpfs, then perhaps a few more to see if anything allows for untrusted servers. Then I will get back to my own brilliant ideas.

 Fri, 14 Nov 2008

I don't know where else to publish this, so I reactivate my blog. (Google, listen up! -- umts 3g modem linux debian wvdial ppp smartone vodafone hong kong hk huawei e620 e220 usb.)

Useful links:

http://wwwu.uni-klu.ac.at/agebhard/HuaweiE220/    [english]
http://ubuntu.frankenberger.at/Huawei_E220.html   [german]

The Story: Smartone Vodafone in Hong Kong sells UMTS modems with sim card for 188 HKD / month flat. The connection rates are not great, but ok, and it works on Debian Linux pretty much right away (if you don't get distracted and start learning how to turn your windows laptop into an OpenVPN server. :-)

The most interesting bit first. Here is my /etc/wvdial.conf (a bit arbitrary and messy, but it works) -

[Dialer Defaults]
Dial Attempts = 1
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = ATE0V1&D2&C1S0=0+IFC=2,2
Init4 = at+cgdcont=1,"ip","web.vodafone.hk"
Modem Type = Analog Modem
ISDN = 0
Stupid Mode = 1
Baud = 460800
New PPPD = yes
Modem = /dev/ttyUSB0
Dial Command = ATDT
Phone = *99***2#
Username = anyusr
Password = anypass

... and a bit of debugging output:

# lsusb | grep Hu
Bus 005 Device 037: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem

this is what the kernel had to say:
Nov 14 20:30:53 yo kernel: [126072.726442] usb 5-4: new high speed USB device using ehci_hcd and address 36
Nov 14 20:30:53 yo kernel: [126072.869116] usb 5-4: configuration #1 chosen from 1 choice
Nov 14 20:30:53 yo kernel: [126072.875916] scsi60 : SCSI emulation for USB Mass Storage devices
Nov 14 20:30:53 yo kernel: [126072.882170] usb 5-4: New USB device found, idVendor=12d1, idProduct=1001
Nov 14 20:30:53 yo kernel: [126072.882183] usb 5-4: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Nov 14 20:30:53 yo kernel: [126072.882190] usb 5-4: Product: HUAWEI Mobile
Nov 14 20:30:53 yo kernel: [126072.882194] usb 5-4: Manufacturer: HUAWEI Technology
Nov 14 20:30:53 yo kernel: [126072.882227] usb 5-4: USB disconnect, address 36
Nov 14 20:30:53 yo kernel: [126072.882878] usb-storage: device found at 36
Nov 14 20:30:53 yo kernel: [126072.882887] usb-storage: waiting for device to settle before scanning
Nov 14 20:31:01 yo kernel: [126080.472060] usb 5-4: new high speed USB device using ehci_hcd and address 37
Nov 14 20:31:01 yo kernel: [126080.615229] usb 5-4: configuration #1 chosen from 1 choice
Nov 14 20:31:06 yo kernel: [126085.248255] usb-storage: probe of 5-4:1.0 failed with error -5
Nov 14 20:31:06 yo kernel: [126085.248255] option 5-4:1.0: GSM modem (1-port) converter detected
Nov 14 20:31:06 yo kernel: [126085.248255] usb 5-4: GSM modem (1-port) converter now attached to ttyUSB0
Nov 14 20:31:06 yo kernel: [126085.252113] usb-storage: probe of 5-4:1.1 failed with error -5
Nov 14 20:31:06 yo kernel: [126085.252148] option 5-4:1.1: GSM modem (1-port) converter detected
Nov 14 20:31:06 yo kernel: [126085.252248] usb 5-4: GSM modem (1-port) converter now attached to ttyUSB1
Nov 14 20:31:06 yo kernel: [126085.256469] usb-storage: probe of 5-4:1.2 failed with error -5
Nov 14 20:31:06 yo kernel: [126085.256497] option 5-4:1.2: GSM modem (1-port) converter detected
Nov 14 20:31:06 yo kernel: [126085.256582] usb 5-4: GSM modem (1-port) converter now attached to ttyUSB2
Nov 14 20:31:10 yo kernel: [126089.264190] scsi64 : SCSI emulation for USB Mass Storage devices
Nov 14 20:31:10 yo kernel: [126089.266130] usb-storage: device found at 37
Nov 14 20:31:10 yo kernel: [126089.266139] usb-storage: waiting for device to settle before scanning
Nov 14 20:31:14 yo kernel: [126093.264190] scsi65 : SCSI emulation for USB Mass Storage devices
Nov 14 20:31:14 yo kernel: [126093.266334] usb 5-4: New USB device found, idVendor=12d1, idProduct=1001
Nov 14 20:31:14 yo kernel: [126093.266346] usb 5-4: New USB device strings: Mfr=2, Product=1, SerialNumber=0
Nov 14 20:31:14 yo kernel: [126093.266353] usb 5-4: Product: HUAWEI Mobile
Nov 14 20:31:14 yo kernel: [126093.266358] usb 5-4: Manufacturer: HUAWEI Technology
Nov 14 20:31:14 yo kernel: [126093.268378] usb-storage: device found at 37
Nov 14 20:31:14 yo kernel: [126093.268388] usb-storage: waiting for device to settle before scanning
Nov 14 20:31:15 yo kernel: [126094.265349] usb-storage: device scan complete
Nov 14 20:31:15 yo kernel: [126094.267337] scsi 64:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
Nov 14 20:31:15 yo kernel: [126094.297157] sr1: scsi-1 drive
Nov 14 20:31:15 yo kernel: [126094.297319] sr 64:0:0:0: Attached scsi CD-ROM sr1
Nov 14 20:31:15 yo kernel: [126094.297400] sr 64:0:0:0: Attached scsi generic sg2 type 5
Nov 14 20:31:19 yo kernel: [126098.269374] usb-storage: device scan complete
Nov 14 20:31:19 yo kernel: [126098.271272] scsi 65:0:0:0: Direct-Access     HUAWEI   MMC Storage      2.31 PQ: 0 ANSI: 2
Nov 14 20:31:19 yo kernel: [126098.291558] sd 65:0:0:0: [sdb] Attached SCSI removable disk
Nov 14 20:31:19 yo kernel: [126098.291648] sd 65:0:0:0: Attached scsi generic sg3 type 0

BEWARE! -- don't get the phone number wrong, or you will end up with behaviour that very clearly mimiks the ppp bug found here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445711 (i think it's fixed in debian's 2.4.4rel10), and you will end up searching forever for the reason. just use the phone number you find in the connction manager when plugging the modem into a windows box. (sometimes at least windows makes reverse engineering a bit easier. :)

 Fri, 23 Feb 2007

Yes, this is taken completely out of context, and picture and headline have actually nothing to do with each other (the picture is about riots in Paris, and the article about the Ifo-Index that just came out). Also, it's very out-dated. Anyway I still liked it. :-)

"Economy increasingly optimistic". (Source: Financial Times Deutschland, March 29, 2006.)

 Thu, 22 Feb 2007

and I also fear I am getting more and more off topic, but I have to link this.

A German group of activists dedicated to fight nazis as the dominating subculture in rural Germany has announced a concert featuring anti-fascist bands. Public prosecution and police authorites announced in turn that all persons wearing a crossed-out swastica logo (I am not displaying it because I do not have the time to fight my right to do so through in court, but you can see it here), or anything that might provoke right-wing persons will be arrested.

Last time this logo was in the news, an anti-fascist activist was sentenced to pay 3600 EUR legal fees because he was distributing a photograph of an demonstration against nazis that showed it. He was found violating the German law that criminalizes propagating nazi symbols, which was installed in Germany shortly after it lost some war a while ago. (Here is the link to an article about this in another newspaper I detest.)

So appearently a logo can at the same time propagate nazi ideology and piss off nazis, and must be banned from the public for both reasons. WTF?!

 Mon, 22 Jan 2007

I am scared now...

 Thu, 16 Nov 2006

Second Life has a problem: Somebody has realized that the laws of thermodynamics only apply to cyberspace to the extent that people have thought of implementing them, and written a need tool called CopyBot that allows for, well, not stealing, but let's say pirating objects from others (because pirating is a so much lovelier concept:) The vicitim won't loose it, but the pirate will come out of the process with a clone of it.

This is intriguing because it allows a new perspective on the developments in copyright legislation in recent years. People are so incredibly productive that already in our lousy economic system we can have so many things we want, and even more things nobody wants. Also, people will always be more productive if they can enjoy a task enough to fully put their mind to it. So is it really a good idea to drive reproduction of culture by starving the creative minds dedicated to the task if they are not successful on the market? Would culture stop being produced if there was no direct monetary reward in it?

Of course I don't know how to fix things to do it that way. It just a nagging feeling that a free market culture industry is perhaps only the second best mode of production for things like movies and novels and records. And now we can gain new insight in the alternatives on SL. Since I have encountered the Oekonux people, I have been wondering what happened if we could stick BSD or GPL licenses to laundry machines, and loafs of bread, and sacks of rice. Now they are doing just that on SL.

I know too little about SL, and I can't spend the day figuring it out, but I would love to understand why people are getting irritated about this instead of excited. Rigorous countermeasures are set in place to re-establish un-copyability of things instead of just seeing how things change in a differently structured nature. But I guess it changes so many things that some people are bound to be worse off. Or then, it may be that more laws of physics (and more likely of sociology) need to be changed to take the new situation into account properly. Or it's just the mindset. (Is this thing even about competition?)

Linden Lab is considering allowing its citizens to attach Creative Commons licenses to their goods, but they are also threating CopyBot users with DMCA lawsuits. But the further I go with this text, the more I realize I have no idea what I am talking about. I just think it's really cool.

Write me an educate me! (-:

 Wed, 15 Nov 2006

Two remarkable things popped to my attention today. The German minister of justice, Brigitte Zypries, demonstrated her opinon on civil rights by publishing a draft of the new German telecommunications act. Her plan is to force e-mail service provider to verify the identity associated with a new account by having the user present a valid ID, and to criminalize anonymisation services such as TOR and ANON, unless they keep logs that allow prosecution to de-anonymize every user of the last six months.

I don't know where to begin.

The lawyer's perpective on reality is known to suffer from limitations that few exceptions in the business have ever overcome. Two of the most common misconceptions are these: (1) If we pass a law that makes something illegal, people won't do it any more; and (2) the state is above corruption, or at least the level of corruption is constant and tolerable, and unaffected by the power it holds over its subjects.

(1) A law is only effective if you get the incentives right: The police needs an incentive to investigate, courts need incentives to prosecute and convict, and ideally the subject should have an incentive to act according to the law. The former enforces the latter to an extent, given that breach of a law can be detected and proven. Bad laws are laws against trade of recreational drugs (people are willing to spend big money on it), laws that regulate the labor market against the will of the employer (it won't make unemployable people employable all of a sudden), laws that criminalize spam and telemarketing (you have to prove they called in order to sue them, and you have to bring up the determination to sue them merely because they stole you one minute of your life), and laws that tell the police not to use the tools they are given to intrude the privacy of others (they will, because either you won't know, or you are a criminal and you have no right to restrict the powers of the police against you). For counter-examples of (2) consult the history book of your choice. The level of corruption changes with the level of power an organization holds, and there is no metaphysical difference between the state and the people it governs. The German police forces are the good guys because there are good laws in place in Germany, not because they are the guys who wear the uniforms and criminals aren't. I feel stupid even writing it down, but I think I am hitting the core of the problem with the new telecommunications legislation.

Instead of making the internet a more secure place by improving technology and advancing cryptographic and usability countermeasures againts cyber crime, the solution of our government (not that any party in the opposition would ever have displayed more wisdom) is to pass laws that make it illegal to fool around with a technology that screams for fooling around with at the top of its lungs. This can only have the effect that innocent bystanders are harrassed not only by criminals, but also by the authorities. It certainly won't have the effect that crime diminishes.

The other remarkable thing is more entertaining. It is exceedingly violent, and when a friend showed it to me he developed the picture of killbots roaming Frankfurt airport and making big holes into people with invalid or broken RFID passports. I can't help but think that's funny. And I am coming more and more to the conclusion that the problem is not technology, but Dilbert's law: The fact that nobody has a clue about it. Or about anything else.

 Fri, 27 Oct 2006

A few days back, I was trying to explain how public-key crypto makes confidentiality and integrity possible without referring to the underlying mathematics. Afterwards I got involved in some interesting discussions with a few friends, which convinced me that I have hit a very deep limitation of everyday life phenomena as metaphors for cryptography. I hope this rewrite is coming a little closer to a convincing (if not satisfactory) conclusion.

PKC (public key crypto) is done with handles, that need to be exchanged in a secure way. Encryption makes sure the message you create is only read by the legitimate recipient, and digital signatures prove that the message you received is really from the sender you think it is from, and that it wasn't modified since it was sent.

Encryption is easier to explain: The handle for encrypting is a machine that produces open vaults that, once closed, can only be opened with a secret key. As long as the secret key is safe with the legitimate recipient, all is well. An adversary will fail to examine one of the vaults and reproduce the key from her findings.

Digital signatures are a little weirder: The vault manufacturing machine (VMM) and all open vaults now stay safely with the sender of the message. Furthermore:

  • The vaults are made of glass. A digitally signed message can still be treated as a normal message. It can be copied, and the copy can be modified, only the original message inside the vault remains intact.
  • They have a signet imprinted on the front. The signet enables everybody to verify the true origin of the message.
  • They have no doors or keys, but remain sealed until they go away. If we still need a message, but no more proof of integrity, we produce a copy of the message by looking through the glass walls.

Digitial signatures seem to be pretty much sealed letters in the medeaval ages, only that one can look into them without breaking the seal. And that they are much safer. However, this safety is hard to motivate: The only concievable way of verifying the signet on a glass vault (short of using cryptographic theory, of course :-) is to have a copy of the signet, and match the two. But the copy of the signet can be used to craft a signet ring, and imprint fresh glass vaults with forged messages. Similarly, there is no way to make sure that opaque vaults won't be reverse engineered to recover the secret key to open them, instead of being used for encryption.

And yet. If you try to reveres engineer a not-yet sealed encryption vault, you will hit a barrier that is impossible to overcome, and that barrier can only be explained by magic. Conversely, if you try to forge a signet, and imprint it on a glass vault that you produced with your own VMM, it will always magically turn out wrong.

By now I am convinced that this is how far mechanical metaphors can carry us. They require magic in order to work. If you have ever read a fantasy novel, you know that real magic is not arbitrary, but has its own mechanics and laws of nature. And somehow, the laws of the magic suitable for protecting vaults and signets turn out to be peculiarly mathematical.

Which brings me to a point from which in order to go further, I would have to find metaphors involving numbers and symbols to explain vaults. But then we would loose what little elegance we have gained from trying a short-cut around the domain of numbers and symbols.

If anyway is willing to turn this gibberish into a novel graphical user interface for a generic cryptographic API, and I will think of a bounty. Let the negotiations commence! (-:

Somebody has mentioned ruby quiz on the haskell-cafe list, and started a discussion on implementing one of the challenges in Haskell. This is my first contact with ruby, and although I am skeptical about the lack of rigorousness, I must admit the code is exceedingly elegant.

Very quickly, a wiki page was set up to cannibalize from rubyquiz, and if people don't get bored soon, we will have a handful of different solutions for every one of the almost 100 challenges (and counting) in a few weeks.

The cool thing (which also helps to tell this event apart from WWE ;-) is that nobody has started a crusade to defend the holy language of all that are righteous yet. Instead of trying to take territory from the hostile camp, the crowd is just peacefully creating code. And since by studying the results one can learn by example how problems are expressed and solved in two very different of the best languages ever made up, I think the haskell-ruby quizz can keep up with a lot of tutorials. And it's certainly more fun.

 Sat, 14 Oct 2006

Public-key encryption is considered to be a mind-bogglingly abstract and confusing concept by a wide range of people, which hinders its deployment on the one hand (eg., for securing e-mail), and erodes security on the other (eg., when a user cannot make an informed decision whether to accept an unverfiable certificate or not).

(This article is somewhat obsolete.)

A while back I spent a few days worth of idle time on subways and under the shower trying to find good metaphors for crypto primitives, and failed to find one for digital signatures or MACs. Now, the blindingly obvious answer came to me in a dream. Of course it was one of those dreams where you invent a device to advance civilization by a hundred years, but once you are fully awake you don't remember the technical details and have to start all over again. But at least it made me start all over again. Here is what I came up with. (I also googled for the subject real quick, but couldn't find anything. I will post any pointers you send me as a PS below).

If you encrypt a message, what you do is you put it into a vault that nobody can open without the right key. (More often, the notion of sealed envelope is used, but I like vault better because it makes it more plain that penetration is hard. If you want to get sophisticated, you can imagine a mechanism that breaks an acid flask inside the vault and destroys the message if you try to force it open. The idea is attributed to DaVinci, although I suspect it to be older, and became widely known recently by a poorly written and exceedingly famous novel on the wrong-doings of the catholic church.) If you decrypt it, you put use the right key to open the envolop, and take out the plaintext message.

Now, from our experience with door locks, we expect there to be two identical copies of the key; one is used to close the vault by the sender of the e-mail, and one is used to open it by the recipient. However, it turned out that what we want to do can be restated as follows: The recipient gives the sender a machine that produces vaults (let's call it vault-manufacturing machine and give it an acronym: VMM). These vaults come out of the machine open, the door can be closed without a key, and only the sender can open the vaults with her key (and discard them after having taken out the message).

The VMM is better known as the public key, the key to open vaults is called private key. If you configure a cryptosystem like PGP or S/MIME, you generate a pair of VMM and key to the vaults. Then you hand over (a copy of) the key to anybody who wants to send you a message in private, and only you can open any incoming vaults with your private key.

Math: The VMM is called K_pub, and the vault-key is called K_priv. Encryption, ie., producing a vault, putting a message M in, and closing the door, yielding a securely closed vault C, is written C = E(K_pub, M). (Non-metaphorically, C is called the ciphertext.) Opening the vault, yielding the plaintext message again, is written M = D(K_priv, C). A cryptosystem consists of three methods: One for generating key pairs (K_pub, K_priv), one for encryption called E, and one for decryption called D. RSA and ElGamal are the most prominent representatives of public-key encryption methods. Products like PGP, S/MIME and SSL all can use varying methods, depending on the configuration, but the structure is always the above.

Data integrity (or the equivalent, message authenticity) means that nobody can mess with your data or, in other words, that the vault is transparent. A digital signature method is that similar to a public-key encryption method, but somehow the other way around: The VMM is kept private (as are all vaults that haven't been sealed / closed yet), and the key to open the vaults is published for everybody to open the vault and take out the message.

Hm. This is still a little too simple to be useful. Signature vaults have two important features:

  1. A vault can only be opened once, by breaking it; it is never shut again with a new message inside, but discarded. (The only person who can sign messages is the one in posession of the VMM, because it is the only source of vaults that have never been closed yet.)
  2. It is infeasible to build a vault that opens on a given key, if you haven't generated the key together with the VMM.

Hm. The second one is where the metaphor breaks. Up to this point, I was hoping to be able to break both digital signatures and public-key encryption down to security against lock-picking, but this only works with encryption. For digital signatures, we need a signet ring that is so intricate that nobody can realistically forge it. This signet ring is part of the VMM, and each glass vault is embossed with the signet. The VMM-holder publishes an inverse signet that can be pressed into the vault's door, and you can see whether the two match or not. If you get a match, you know that what's in the vault is authentic, and you can decide to open it or not. As long as you leave the vault sealed, the message is intact. As soon as you open it, the message become just a piece of unreliable data to anybody who receives it from you; only you still know about its origin and integrity.

This is not entirely satisfactory either: Nowadays, signet rings are as good as signets, because a signet can be turned into a ring to produce more signets easily. However, signet forgery used to be an obstacle few adversaries where capable of overcoming. Hence, it used to be a valid method for enforcing message integrity. So maybe this is a good way of explaining it after all? I am not as sure any more as I was this morning.

Metaphors are vital for making cryptography accessible to a wide range of people in a robust way. Many people have made the (seemingly obvious, but nevertheless important to mention) point that security without usability is no security; insert your favorite link here. However, metaphors for digital signatures suck. Legislation and administration have been on the project of making digital signature technology widely available to society for many years, and with disappointing success. I claim that there is a good reason and a bad reason for this:

  1. Many technical issues with the wide deployment of digital signatures have not been satisfactorily addressed, most of them about key management and secure key distribution. However, I don't believe that would keep the technology from being a success: If you look at PC operating systems, you will notice a strong correlation between vulnerability against malicious code and popularity. This is a perfect example that usability is the key to success of new technology.
  2. And then there is usability. This may be considered the bad reason. One might hold the opinion that bad technology that is easy to use should be less popular than good technology that is challenging and complicated to use. But it is the reason that hinders deployment of digital signature technology.

The glass vault with signet is a disappointment. It is clumsy and complex to understand, and dubious to trust, given the experiences of our world as opposed to that of a medieval king. But at least it's a little different from all the other explanations that I have heard of so far. I have posted it anyway in the hopes of inspiring somebody (me?) to finally come up with the perfect, simple-and-stupid, straight-forward explanation that captures aspects of usage as well as of security.

And if this should ever happen, good metaphors are still missing for a vast number building blocks. Start with blind signatures: You can hand over an opaque vault to somebody who wraps it into a glass vault, and then you remove the opaque vault without opening the glass vault that contains it and can basically not be opened without destroying the glass signature. This is quite far from intuitive.

 Fri, 08 Sep 2006

... I am now officially tired of Ubuntu, my most recent favourite linux distro. Here is why:

  • 6.06 forced me choose a hostname with 3 characters or more. (Why should ubuntu care? How can this not be made a non-binding recommendation? 5.10 still considered 1-character hostnames perfectly legal, which they are!)
  • When I had an xfs root fs, 6.06 made a half-hearted attempt to use lilo as boot loader (grub doesn't like xfs images), which made the installer crash. Many people have reported this (more or less clueless about what's going on, because the error message is a Python stack trace), but last time a checked a few weeks ago nobody seemed to be interesed in fixing the problem. Or understanding it.
  • After I had set up a /boot partition to make grub happy, 6.06 still crashed, with another Python stack trace. This is where I got bored. And decided to upgrade from an installation of 5.10.
  • During this upgrade, my Mozilla was silently replaced with Firefox.
  • There is a very. weird. problem with my Thinkpad wireless card. Ask, I am happy to talk about it. It's at least the third weirdest glitch I ever encountered. Or heard of.

So as soon as I have the time, I will start complaining about OpenBSD. Wait, I am already there: If you install it from the 5MB cd39.iso image, it doesn't do any consistency checks on the packages it downloads from the ftp server of your choice. No comment...

The Onion Router network is a system that gives users who run a socks proxy server on their local machine TCP anonymity by routing their traffic over hard-to-predict hosts elsewhere. A most fascinating side-effect is that you look at the web from random perspectives. Even if physically in Germany, you occasionally read things like this:

Great fun.

Today, prosecution in south Germany has started to harvest tor routers that are run by individuals on a voluntary basis: Heise and the TOR mailing list took notice. And yes, it's about child porno. No controversy on whether they are chasing the good guys.

Still, this is curious. I don't believe they are trying to extract traffic logs, which is quite impossible. There are a few attacks against the TOR protocol that work if the adversary has a large enough number of nodes under her control. Only the traffic needs to occur on those nodes during the attack --- there are no traffic logs that could be used after the hard drives have been taken away to an LKA lab. Nor do I believe that they don't know what they are doing: I have talked to some of them in the past who struck me as non-stupid. There are two explanations I can think of.

They may simply try to intimidate people who are running anonymizers and thus decrease service quality and make the world more transparent for them. Bad idea: Those who are serious about anonymity will keep finding ways to get it, and those not-so-serious about it usually are not really doing anything wrong. Nobody who plans to commit a criminal offense is aware of the existence of anonymity services, but is still leaving traces that lead to a successful identification because those services are too clumsy (or too risky) to use.

The other is that they hope to find the criminal contents of a hidden web server on one of the routers they captures by chance. This would be a long shot: There are around 800 routers, they are distributed all over the planet, and the hidden server does not even need to be one of them.

Am I missing anything? Calling prosecution and trying to figure out what is going on here is another thing I would love to have the time to do...

 Thu, 07 Sep 2006

(Markus: Read on, I have done it right this time. :) The sieve of Eratosthenes is an algorithm to compute prime numbers. Here is the basic idea:

sieve = s 2
    where s i = i : [ j | j <- s (i+1), j `mod` i /= 0 ]

How does it work? --- The term s 2 generates a list of integers in increasing order, but some of them are missing. The first, obviously, is 2. Then, the constraint j `mod` i /= 0 makes sure that all other numbers in the list are odd. The recursive invocation of this constraint in recursive calls to s makes sure that all other divisors are checked for larger numbers, too.

This is horribly inefficient: generating the first 2000 primes takes 310s on my laptop with ghci, because of the many checks for divisors. But at least it is very short. Now for a slightly more efficient and far uglier variant of this code, a little closer to an algorithm using mutable arrays (see below). Instead of filtering out all divisible numbers while we create the primes, we start by enumerating all numbers that are multiples of other numbers:

infix 5 \\\
xs \\\ ys = filter (not . (flip elem' ys)) xs

-- (elem' can afford to be more lazy than elem because its
-- arguments are in increasing order)
elem' x [] = False
elem' x (y:ys) | y <  x  = elem' x ys
                         | y == x  = True
                         | y >  x  = False

nonPrimes i = (2*i) : sortMerge (map (*i) [3..]) (nonPrimes (i+1))

sortMerge [] ys          = ys
sortMerge xs []          = xs
sortMerge (x:xs) (y:ys)
    | x < y              = x : sortMerge xs (y:ys)
    | x == y             = sortMerge (x:xs) ys
    | x > y              = y : sortMerge (x:xs) ys

sieve' = [2..] \\\ (nonPrimes 2)

Generating the first 2000 primes now takes 268s instead of 310s. Not a big improvement, but at least it's ugly.

Finally, this is the way you would do it in C: Figure out how many primes you need before you start the computation, then initialize an mutable array (and hope that it fits into your main memory), delete all multiples, and collect what is left. sieve'' runs in a little less than 1 second, as opposed to 4-5 minutes for sieve and sieve':

sieve'' :: [Int]
sieve'' = filter (> 0) (elems ((runSTUArray (a >>= f)) :: UArray Int Int))
    where
    x = 2
    y = 17389

    is = [x..y]

    f :: (STUArray s Int Int) -> ST s (STUArray s Int Int)
    f a = do
          init a
          sequence . map (sieve a) $ is
          return a

    -- malloc
    a :: ST s (STUArray s Int Int)
    a = newArray_ (x, y)

    -- init
    init :: (STUArray s Int Int) -> ST s [()]
    init a = sequence [ writeArray a i i | i <- is ]

    -- sieve
    sieve :: (STUArray s Int Int) -> Int -> ST s [()]
    sieve a i = sequence [ writeArray a q 0 | q <- takeWhile (<= y) . map (*i) $ [2..] ]

Or, a little more concise:

sieve'' :: Int -> [Int]
sieve'' y = filter (> 0) (elems ((runSTUArray f) :: UArray Int Int))
    where
    is = [2..y]

    f :: ST s (STUArray s Int Int)
    f = do
        a <- newArray_ (2, y)
        sequence [ writeArray a i i  | i <- is ]
        sequence [ s a i             | i <- is ]
        return a

    s a i = sequence [ writeArray a q 0 | q <- takeWhile (<= y) . map (*i) $ [2..] ]

Exercise 1: How can you cut the run time of the sieve step in the last program in half again?

Exercise 2: Why are the type annotations necessary?

 Thu, 17 Aug 2006

Haskell is cool, and I have just made the practical experience that (as I always suspected) it really is a better language for talking to an operating system. I just did a quick and dirty re-implementation and re-design of the Unix command find(1) that already feels much more powerful and flexible than the original.

I am using a very primitive tree data structure to represent the output, and depth and breadth first search functions to transform trees into lists. First, find mutates each node in the file tree twice: once before, and once after its children have been collected. Then, it constructs a tree from the mutations (which are possibly gone, leaving holes in the tree). If a mutation removes an element before the children are collected, the tree is chopped in the corresponding node, and the subtree is never touched. A posteriori vanishing mutations do not affect the tree structure, just single nodes.

import qualified List as L
import Directory
import Maybe
import Monad
import IO


-- Tree

data Tree a = Node (Maybe a) [Tree a]
            deriving (Show, Read, Eq, Ord)

dfs :: Tree a -> [a]
dfs (Node Nothing ts)  = join (map dfs ts)
dfs (Node (Just a) ts) = a : join (map dfs ts)

bfs :: Tree a -> [a]
bfs t = roots t ++ f t
    where
    f (Node _ ts)  = map root ts ++ join (map f ts)

root :: Tree a -> a
root (Node Nothing _) = error "root of tree is empty."
root (Node (Just a) _)  = a

roots :: Tree a -> [a]
roots (Node Nothing _) = []
roots (Node (Just a) _)  = [a]


-- Find

find :: [Mutator] -> [Mutator] -> FilePath -> IO (Tree FilePath)
find thinning pruning = f
    where
    thin, prune :: Mutator
    thin = muxCompose thinning  -- (leaving all subtrees intact)
    prune = muxCompose pruning  -- (if mutator deletes node, chop off subtrees, too)

    f :: FilePath -> IO (Tree FilePath)
    f path = do
             mp  <- prune path
             dir <- maybe (return False) doesDirectoryExist mp
             p'  <- maybe (return Nothing) thin mp
             if dir
                then do
                     children <- getDirectoryContents (fromJust mp)
                     let dots = filter (\child -> not (L.elem child [".", ".."])) children
                     subtrees <- sequence [ f (path ++ "/" ++ child) | child <- dots ]
                     return (Node p' subtrees)
                else do
                     return (Node p' [])


-- Mutators

type Mutator = FilePath -> IO (Maybe FilePath)

muxCompose :: [Mutator] -> Mutator
muxCompose = foldl (\ s t path -> s path >>= maybe (return Nothing) t) muxId

muxId :: Mutator
muxId = return . Just

The most obvious mutators are those that remove paths from the tree if they satisfy certain predicates:

muxFilter :: (FilePath -> Bool) -> Mutator
muxFilter f path = return (if f path then Just path else Nothing)

muxFilterIO :: (FilePath -> IO Bool) -> Mutator
muxFilterIO f path = do v <- f path; return (if v then Just path else Nothing)

muxDirectoriesOnly :: Mutator
muxDirectoriesOnly = muxFilterIO doesDirectoryExist

muxFilesOnly :: Mutator
muxFilesOnly = muxFilterIO doesFileExist

muxSuffix :: String -> Mutator
muxSuffix s path = return (if L.isSuffixOf s path then Just path else Nothing)

muxNotSuffix :: String -> Mutator
muxNotSuffix (...)

find [muxSuffix "~"] [] "." returns the tree of all writeable files and directories that end with a tilde, whereas find [] [muxSuffix "~"] "." only returns files and directories that end thusly and all the parent directories of which up to "." end thusly, too. ("Thusly" is one of the many wonderful words I owe to Charles Montgomery Burns.) Yes, the applicability to everyday situations of the latter is less obvious. But in general, the need for both some way of pruning subtrees before they are traversed and for processing nodes without pruning them is obvious.

muxRemoveFile :: Mutator
muxRemoveFile path = system ("rm -f " ++ path) >> return Nothing

muxRemoveDir :: Mutator
muxRemoveDir path = system ("rmdir " ++ path) >> return Nothing

muxRemoveDirAll :: Mutator
muxRemoveDirAll path = system ("rm -rf " ++ path) >> return Nothing

Now we can remove all files (not directories) on the tree that end on "~" by running find [] [muxNotSuffix "~", muxRemoveFile]. First, all nodes that are not to be deleted are dropped by muxNotSuffix, then muxRemoveFils takes care of the rest.

It's not thought through at all. To achieve linear complexity and make optimal use of lazyness, the type of find may need to be changed. Something like .. -> Tree (IO FilePath) comes to my mind, but doesn't strike me as right. Also, support for symlinks is missing. More filters are needed. But it's a proof of concept.

Two pointers to related issues: Ralf Hintze has written a simple command line parser that execs unix commands typed in by the user. It is not much of a paradigm shift, but it would be a good starting point for a more dedicated attempt at a lazy, functional shell. On Jul 16, Brian Smith triggered an extensive discussion on algebraic type-safe representations of path names on the haskell-cafe mailing list. This would make the above approach even more appealing in comparison to the existing unix implementations.

 Fri, 21 Jul 2006

The 7/2006 issue of IEEE Spectrum features a long article on biometric security for credit card clearance systems by Jain and Pankanti. The authors propose a biometrics-enhanced transaction technology they claim is suitable to drastically reduce identity theft. I am not going to argue that point. It is hard to come up with a system easier to break than the current one. But I couldn't resist a quick ad-hoc analysis.

The current system. (Actually, I never confirmed this, it's more the way I always thought it works; please mail me if you know better.) A terminal receives the CC number from the magnetic strip, the pin number from the key pad, and the transaction data (amount and target account information) from the counter. All three data items are transmitted to the issuer, which acknowledges or rejects the transaction. Alternatively, the signature substitutes the pin number, and a phone call the automatic clearance process, but the security properties of these two variants are quite similar.

Problems:

  • Physical theft: If the card is stolen and the pin number is written on the back (you think that's rarely the case? -- I thought so, too, but read on!), the thief can use it as her own.
  • Virtual theft: A rogue terminal operator can harvest CC numbers and pins and use them for transaction that are not authorized by the card holder, without the card holder having a chance to know. Considering that it is (a) very simple to become a terminal operator and (b) very hard to track the occurrance of fraudulent transactions to the terminal that stole the data during a legitimate transaction, I suspect that a considerable fraction of CC fraud works like this.
  • Privacy issues: Even if all terminal operators are honest, user profiling is encouraged by the flow of plaintext account information every time a chocolate bar is purchased. (Yes, I consider privacy an important design objective, not merely another customer preference. But even if you beg to differ, you might still see a virtue in more privacy-preserving schemes: Having anonymous CC payment schemes doesn't rule out opt-in customer loyalty schemes.)

Jain and Pankanti's system is similar, but has several improvements:

  • The link between card and terminal is encrypted and authenticated (I think the authors imply x.509-based PKI).
  • If the card is reported stolen, the transaction is canceled with a warning. (This is not anything special, though: If you are going over your limit too far, or if you report your card stolen, even in the system currently in use when you attempt to pay your lunch you risk being returned your card cut in two halfs by the waiter.)
  • The card checks the holders fingerprint with a built-in biometrics device. Only if the check succeeds, a time-stamped and digitally signed copy of the account information is passed to the terminal for forwarding to the CC issuer. The transaction data is added by the terminal, and not digitally signed by the card.

This solves two of the three problems nicely, to a certain extent. If the card is stolen, the biometrics device needs to be hacked, which is expensive and time-consuming, and time stamps make stealing the credentials (virtual theft) harder.

But rogue readers may still collect customer profiles, although strengthening the system againts malicious readers is quite simple: Encrypt account information, not only sign it. And there are probably reliability issues with the biometrics device. The authors claim the false positive rate is 1% and the false negative rate 0.1%, which may be acceptable or not. But I don't think those are uniformly distributed over all thumbs out there.

Modification: Building a display for the transaction amount into the card might be less expensive than the biometrics device, and it would allow for the card to sign and encrypt the full transaction. To be more specific, reader sends amount to card, card has holder confirm amount (the reader won't cheat about the recipient), card sign and encrypts account number, time stamp, amount, recipient and sends it to the reader for forwarding to the holder, and the holder sends a confirmation message to the reader containing amount and recipient. Again, the reader has no idea who it is doing business with, but the user can be certain about the full transaction.

But a more serious problem is not touched by all these improvements, and it might be another instance of the same abstract problem as the notoriously striving global narcotics market: The profit margins of CC fraud are so high that it doesn't matter whether the investments required to harvest the profits go up by several orders of magnitude. If an attack is very expensive to launch for a criminal individual, but scales almost as well as software production, then the costs might be far from prohibitive even with advanced biometrics.

I think it was Bruce Schneier who I saw first explain the difference between physical and virtual security, i.e. between breaking a firewall system or implementing a phishing scheme, and breaking into a tool shed or a bank. If somebody reverse engineers a lock that is used to secure tool sheds and publishes a method to open the lock without a key, there is still a lot of manual work involved in every future instance of penetration. On the other hand, a successful phishing scheme ideally needs to be set up only once to attack every single computer user on this planet. And so does the laboratory to read out the secret credentials from stolen credit cards in order to produce fake ones. One has to be very careful about the economics involved here before making claims about the reduction in fraud caused by new technology.

Modification 2: The biometrics may be done in both the reader terminal and card. If the terminal checks for the correct biometrics data, the attack of recovering the cryptographic keys from the smart card doesn't help the adversary, because the terminal will still block the transaction. This helps as long as the adversary cannot find a colluding terminal.

The reason why a system of that scale with that bad security has survived for so long is a combination of (a) bankers being pathologically conservative, and (b) economic incentives. The issuer knows the proportion of fraud best, and can calibrate the cost of using a card to compensate the resulting damage. Biometrics, if properly implemented, are likely to prevent some fraction of the fraud, so it might be worth a shot despite the privacy concerns. But the real challenge is not technical, but political, and consists in holding the issuer responsible for fraud that could have been prevented by using better technology. And I don't have any brilliant ideas there either.

Btw, the article contains three intriguing figures: 30% of all CC holders write their pin numbers on the back of their cards. And 0.08% of all off-line revenues (0.25% on-line) are caused by cases of fraud. If would have estimated the latter two higher and the former MUCH lower.


P.S.: Oops! And there, in the last section of the article, which I almost skipped because I thought the online case was so straight-forward I could invent it myself, finally the big screwup: ... each time you made an online purchase, you would touch the fingerprint sensor, the plug-in would confirm your identity, and your PC would send the digital signature to your credit card company, authorizign i to release funds to the vendor. This means there is a piece of software on my PC that can trigger transaction WITHOUT asking the card for credentials. It just asks anyway because it is nice. I admit it's possible to be more optimistic about malware than I am, but the worrying thing is this is utterly unnecessary. Why doesn't the program request a digital signature from the card?! I think this still would be a rich hunting ground for new forms of fraud, but it would considerably weaken the position of the adversary at no cost at all.

 Wed, 12 Jul 2006

Ever wondered what TRUSTe and friends are worth really? Finally somebody has done the probing. Benjamin Edelman has created a number of unique e-mail identities, handed them over to an equal number of sites, and counted the incoming spam. It turned out that the risk of being exposed to spammers is significantly higher if you give your address to a site that has spent a lot of money on a TRUSTe audit. Which even makes sense: If you are a certified good guy, why make an effort? People will like you either way. (-:

I particularly like this because it clearly invalidates P3P and trust-based smart home solutions, and probably teaches us a lot about the risks of having trust in administrative bodies in general, whether national police bodies, courts, or privately constituted online privacy-police non-profits.

[workshop program]. [pdf of the paper].

 Thu, 08 Jun 2006

During our work in this paper, we found a curious security model that I can't resist mentioning here. (In fact, I heard of the paper earlier in a thesis presentation and the resulting discussion there was one of the motivations for thinking this through a little more.) This is how the argument goes.

RFID chips are cool, but there is a privacy problem if any reader, whether legitimate or not, can produce a list of all the things you are carrying with you (underwear, purse, newspaper, chocolate bar, mobile phone, artificial hip, etc.). But because some readers are supposed to be able to see some chips, we need a lot of policy. The policies are stored in a PDA (mobile phone, or the like), and reader obey the following protocol: (a) Probe; (b) for each chip that responds, start a search for the PDA that holds the privacy policy attached to it; (c) ask PDA for policy; (d) selectively delete collected data according to policy. If a reader doesn't obey to this protocol, the owner of the reader is put to jail.

Exercise: If you are only allowed to point out five obvious reasons why any system based on this idea is certain to become a by far more glamorous failure than the German Toll Collect(TM) system, which ones would you choose?

 Wed, 29 Mar 2006

There is an ongoing discussion among pedantic people in IT security whether or not authenticity and integrity should be two independent security goals, or even whether or not they should be two different concepts at all.

A few people have tried to clear this up (the earliest record I know of is by Phil Rogaway), but I still know a few usually smart people who refuse to take my standpoint, so here it goes again, for those not bored to death with the subject yet.

A message is authentic if the recipient holds a sender ID together with the proof that the sender with that ID actually sent it. It is intact if, no matter who sent it, nobody else modified the document after it was sent on its way. The basic argument why there cannot be a reasonable distinction between the two is quite simple: If a message is not authentic, integrity looses all meaning, because integrity now means that the message arrives exactly in the state in which it left the adversary, not the legitimate sender. A message that is not intact is not authentic because it does not apply to the message as it was sent, but to whatever the adversary makes of it. In both cases, there is an adversary that can mislead the recipient about what the sender wrote or not.

Subtle and esoteric differences could be made: An authenticity-preserving scheme may under additional assumptions prevent an adversary from sending messages without the legitimate sender having sent one first. If the message is a physical object like a CD or a Prada purse, some may argue that the CD itself is still authentic, even if the contents is overwritten with data by an adversary. Or that the purse is still authentic, even if somebody patched it with a non-brand piece of cloth. Or one could simply argue that the department of homeland security would see the difference between an adversary originating the message and another one messing with it on the way.

Or, one could consider delay or replay attacks, in which an intercepted message is sent too late, or again, by the adversary. A adversariral message still looks exactly like the authentic, intact, counterpart, and yet there is something wrong with it. Should we say a replayed message is intact, but not authentic? I don't think this a good idea. The two requirements meant here have names, which are liveness and freshness of messages. We don't need to mix them up with authenticity.

But I cannot think of any real reasons why the two concepts should be distinguished in a requirements analysis of an IT system. Nor could any one I asked. If one wants to reason about a system as experienced by its users, there is just no more suitable world-view than the construtivist one.

On the other hand, there are very good reasons to get rid of the distinction: Designing secure systems is a messy task, and usually it is screwed up, no matter how brilliant the involved engineers may be. Fighting complexity is essential to minimize risks. And leaving two redundant concepts dangling there is a good recipe for desaster. Engineers and decision makers will eventually start talking about which of the two should be given up in favour of the other, or just plain forget one of them, and thus unknowingly sacrifice the other.