Slashdot Mirror

Is there any way to do this securely w/o a physical record of the vote?

Yes.

In Applied Cryptography, Bruce Schnieir describes several possible protocols for secure elections.

None are perfect though, something we should remember before we go installing MicroSoft Vote v2.04 everywhere and end up with more problems than we started with.

The most interesting variant is "Voting without a Central Tabulating Facility" where each voter does some cryptographic gymnastics on their vote, and passes the result around so everything is counted in the open, no secret counting agency necessary. No one can tell who voted for who, it will tell you if someone tries to vote twice, or if you try to change someone else's vote. Incredible!

In another example, each voter encrypts their vote with a random serial number such that when the vote is over, each voters # is published and individual voters can confirm who they voted for, but who anybody else did, and the Central Counting Agency cannot identify voters from their vote.

Again, the protocols are not perfect, but they're an excellent starting point if you're interested in secure voting.

I have to take issue with some of your points: There are several issues that make online banks easy targets: 1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure.

In actual fact, you will find most banks Core Banking Systems i.e. the bits that actually process banking transactions, whether online or offline, are extremely secure, and running on legacy mainframe platforms.

They do exactly the same thing as they have always done (i.e. move money about), and thus are not usually subject to massive development projects, or huge leaps in technology. Because they don't have to. Online banking merely provides another interface to the core systems, and unfortunately it is the interfaces which are providing easy targets for malicious users.
This happens because:
a: The core system is written in something like COBOL or mainframe assembler, by 40 year old programmers who resist change and have many years of experience, using strong development methodologies
b: The whizzy new web front-end was written by a group of 20 year old graduates who are shit-hot tech-wise, but lacking any discipline, and the whole development is being driven by eager managers who have to commit to the Bank's marketing department ("we wanna go oline NOW!!")

I have years of personal experience of working with Banking systems (as one of those un-disciplined twenty-somethings :-) and until strong web-development methodologies are implemented, including bomb-proof testing, this problem will continue.

Your comment:
3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections.
is also flawed. Most new web servers incorporate "step-up" technology, which will "pull" the client crypto up to the level of the server (don't ask me how ... I'm no Bruce Scheiner!)

Online Banking is a joke (Score:3) by trog on Wednesday November 08, @12:14PM JST (#25) (User #6564 Info) There are several issues that make online banks easy targets: 1. Extreme conservitism - Oftentimes, their internal systems are quite old. While this tends to make their systems quite stable, it also means that they are generally insecure. 2. Sensitivity to bad press - online banking systems, when compromised, are often hushed up quickly, due to the fact that the publicity will scare clients away. 3. browser ssl - it doesn't matter if the site's key is 128-bit; if the browser functions at 40-bit, then that's the key size used for encryption. This is a problem with all ssl-based connections. 4. user passwords - people in general are dumb about choosing passwords. They often choose easy to guess passwords. It doesn't matter what security mechinisms you have in place; if a password can be compromised, the cracker has access.
Yes, but you can develop screening algorithms, which will force the user to use a god password. And if I find a bank with the old "answer this dumb-ass question to reset your password" option, then I'll walk away.

5. poor sysadmin training - this is the plague of the industry. Most sysadmins don't know much of anything about security. The one's that do are rare.
Exactly! Online banking systems need two things: 1) penetration testing, and 2) more penetration testing to ensure the site is *still* secure.

Unfortunately most institutions (not just banks) have an initial pen-test done to satisfy the financial regulators (as in the UK), and then presume their site will remain secure for ever!!

Anyway: enough rambling!
As I said earlier, most of this comes down to Bank development teams not testing their interfaces thoroughly. This can be proven by the timings of most security breaches: in the UK, it's almost always after a new code upgrade went in!!

See Here and here for some gory details!

LinuxSecurity.com: What applications do you forsee it being used?

Vincent Rijmen: Many many applications. Protection of sensitive files
of the US government (mandatory). Email encryption. Mobile phones.
Smartcards.

Interesting to note that the NSA didn't say they would use AES. Schneier's last cryptogram speculated that they won't be using Rijndael for classified documents in the next few years.

Estonia is also planning to issue smart cards as national ID cards starting from 2002. The project's website has very limited information in English, but the card will feature asymmetric cryptography (as it is designed to be main instrument to implement the digital signatures passed into law on March 8, 2000) and currently the project is in stage of tendering offers from smart card producers.

Since I was involved in the initial research, I have a couple of useful links:

• Kömmerling's & Kuhn's paper Design Principles for Tamper-Resistant Smartcard Processors is probably something everyone has to read before speaking up on the issue of physical security of these things.
• Schneier's & Shostack's paper Breaking Up Is Hard To Do: Modeling Security Threats for Smart Cards is a good read on the logical security issues.

So I could say scan the card into a computer terminal and buy/sell with the money I have on the card and build something similar to a trust rating (karma points) based on the id I had on the card but there'd be no way to track my identity back to who I was irl from that card even if I had done business with you in person.

This type of scenario would call for something known as anonymous digital cash. The protocol that allows for authenticated but untraceable messages is somewhat complicated, but it is nicely outlined in Applied Cryptography by Bruce Schneier in section 6.4. Those wishing to explore this can start here. A couple of interesting things to note about Digital Cash:

1. It would be possible to commit the perfect crime with such a tool. Truly untraceable money???

2. A Dutch company, DigiCash, owns most of the digital cash patents and has implemented digital cash protocols in working products.

3. Elizabeth Hurley is HOT. OK -that's off topic, but I just saw the remake of Bedazzled, and wow!

So I could say scan the card into a computer terminal and buy/sell with the money I have on the card and build something similar to a trust rating (karma points) based on the id I had on the card but there'd be no way to track my identity back to who I was irl from that card even if I had done business with you in person.

This type of scenario would call for something known as anonymous digital cash. The protocol that allows for authenticated but untraceable messages is somewhat complicated, but it is nicely outlined in Applied Cryptography by Bruce Schneier in section 6.4. Those wishing to explore this can start here. A couple of interesting things to note about Digital Cash:

1. It would be possible to commit the perfect crime with such a tool. Truly untraceable money???

2. A Dutch company, DigiCash, owns most of the digital cash patents and has implemented digital cash protocols in working products.

3. Elizabeth Hurley is HOT. OK -that's off topic, but I just saw the remake of Bedazzled, and wow!

Encryption of structured data (eg text, pictures, etc) increases its randomness (ie lowers the entropy)

It is rumoured that the [NSA|GCHQ|etc] can search for encrypted data on a hard drive by computing a sort of "entropy index" for blocks of data.

Similarly, one of the reasons for using long keyphrases to protect your secret key in PGP is that English has about 1.3 bits of entropy ("key strength") per character:

From October 15, 1999 Crypto-Gram:

Many keys are generated from passwords or passphrases. A system that accepts 10-character ASCII passwords might require 80 bits to represent, but has much less than 80 bits of entropy. High-order ASCII bytes won't appear at all, and passwords that are real words (or close to real words) are much more likely than random character strings. I've seen entropy estimates of standard English at 1.3 bits per character; passwords probably have less than 4 bits of entropy per character. This means that a 6-character passphrase is about the same as a 32-bit key, and if you want a 128-bit key you are going to need a 98-character English passphrase.

I highly recommend the Crypto-Gram newsletters. Also, searching cryptome.org (use host:cryptome.org on Altavista et al) for information on detecting low-entropy information (no URLs handy, sorry!) should yield some useful pointers / links.

Al

"Biometrics also don't handle failure well. Imagine that Alice is using her thumbprint as a biometric, and someone steals the digital file. Now what? This isn't a digital certificate, where some trusted third party can issue her another one. This is her thumb. She has only two. Once someone steals your biometric, it remains stolen for life; there's no getting back to a secure situation."

Biometrics is a bad idea over any kind of public network.

Well, at least until genetics advances to the point where we can clone new thumbprints. But then that just opens the door to a new kind of identity theft.

The fact is, I've never bought into the two Big Ideas of the OS movement. I simply don't agree with the Stallman argument that software "ownership" is an Extremely Evil concept. (No, I don't want to get into that argument right now. That would be very Off-Topic.) Nor do I agree that the Bazaar is always going to produce better software than the Cathedral.

That being said, it's pretty clear to me that some projects absolutely must be open-source. For one thing, OS software methods do work better some of the time. The Cathedral has dicked around with GUIs for decades and given us the Xerox Star, Microsoft Windows, OpenWindows, and the ultimate in unprogrammable bloatware, CDE. The Open-Source community has been around for a few years, and has almost absent-mindedly given us KDE, GNOME, Englightenment (which I personally find esthetically appealing even though my brain isn't wired to use it), etc.

Even the closed-source Mac is an example of this. Even if you accept all the fancy usability design principles the Mac is based on (and I personally feel that the Mac is overrated in this respect -- benefiting from the absence of competing usability design principles) you have to admit that Apple is doing a lousy job of maintaining them.

A more important consideration is simple security. Bruce Schneier has convinced me that the only way to secure system software is to expose the source code. That enables the user community to verify security claims. The alternative is to rely on the untestable assertions of closed-source developers.

__________

There's also lokmail.

You'd probably do well to read this article from counterpane if you want some analysis of web based encrypted email.

Dave

SOAP could be a good idea, but I'm not exactly sure that I like the security holes that it opens up. Counterpane points out that Microsoft's own security analysis faults SOAP for being able to "hide" protocol commands from firewalls. That basically means that you either prevent SOAP from at all functioning across your firewall, or go without a firewall. Granted, firewalls aren't the best security policy in the world, but I'd rather be assured that they'll work as advertised than have to worry about a brand new hole.

The Tyrrany Begins....

And RC6 and MARS did not. In fact, MARS takes up more than 200 bytes of RAM : more than is on most 'smart' cards. Although you might be able to adjust to algorithm to get this down the ~100 (the same as RC6), Twofish, Serpent, and Rijndael are all 50-60.

There's a really interesting paper on AES candidate performance here: http://www.counterpane.com:80/a es- comparison.pdf

Check out this link. Cryptanalysis has already begun to reduce the complexity considerably.

The commentary by folks over at Counterpane (Bruce Schneier, et al) seems quite good. They say good things about Rijndael, regardless of whether they really wanted their own Twofish to win out.

If you run Windows, one program I trust to store password's is Bruce Schneier's Password Safe. Store your passwords in a passphrase-protected database using Blowfish encryption.

Similar (but incompatible) software using Blowfish is available for macintosh, and Palmtops.

I'm still looking for an X11 equivalent.

If you run Windows, one program I trust to store password's is Bruce Schneier's Password Safe. Store your passwords in a passphrase-protected database using Blowfish encryption.

Similar (but incompatible) software using Blowfish is available for macintosh, and Palmtops.

I'm still looking for an X11 equivalent.

I dunno... ever since that mistake in the code for Blowfish in the April 1994 issue of DDJ, I've kinda wondered who actually ghost-writes his code. IIRC, 32 bit addition ignoring overflow is what was called for, and in the listing it ended up being 32 bit addition and a mod(32) or some such, which set most of the bits of the register back to 0. That couldn't have helped... Anyone else catch that? In another implementation I saw, it became mod(232) which is truly strange. I guess that came from this where 2^32 becomes simply 232 if your browser doesn't render the SUP tag.

Free and unpatented algorithms are great to have around though, and I expect to see blowfish/twofish products even after the AES winner is revealed.

Hushmail has had secure, encrypted email for a long time now. It uses a Java applet to do the encryption in your browser, without having to download and install any application. The Java source is available for everyone to check for security holes. Hushmail never actually sees your private key. It looks pretty secure, overall - it's been around for a couple of years and I haven't heard of any holes in it.

Bruce Schnier has even reviewed it. He has some problems with it, but there's no glaring security holes. Still, you're probably better off with GPG, storing your private key yourself.

So SafeMessage is nothing new. Of course, the more the merrier. Everyone should use encryption all the time, and competition is a good thing.


Torrey Hoffman (Azog)

Nobody has cracked RSA with 128-bit keys -- and for that matter nobody has *cracked* RSA, they've only done it through brute force key attacks!

They did it with 40-bit quite a while ago on cheap hardware. 56-bit was done by distributed.net back in 1997. And they're still working on 64-bit. What you have to realize is that there are 2^128 (in base 10 that's 3.4 * 10^38) unique possibilities for the key - and only 1 of them will produce the correct decrypted data. It's going to take decades for the computing power to get to the point where that can be cracked in a sufficiently useful period of time (at least using silicon based computers and not some funky organic system).

And to top it off there are pleny of newer, free, encryption algorithms - try Blowfish for one. We need RSA because everyone else in the world uses it... most of the https web servers out there don't speak anything else -OpenSSL/mod_ssl is a nice free exception to that.

I think there is a business behind this - at least that's the impression I get from Counterpane's site. They provide outsource "monitoring services" that seem like they'd cover the detection and response parts of your security program.

It sure does. The article says that "outsourced Managed Security Monitoring" is the answer. Now click Our Solution at the bottom of the page to read about Counterpane's "outsourced Managed Security Monitoring".

This sort of thing protects against script kiddies, not serious attackers who are trying to steal something of value.

Bruce Schneier made a pretty good argument argument against cracking contests, in general, in one of his Cryto-Grams. In particular, he notes that "Contest prizes are rarely good incentives.... Taken at a conservative $125 an hour for a competent cryptanalyst, a $10K prize pays for two weeks of work." The contest runs three weeks, and you only get paid if you win. Of course, the contest isn't targeted at "competent cryptanalysts," but isn't that a point worth making?

If you're looking for more ammo for a Slashdot post ridiculing a cracking contest (did I say that out loud?), Bruce links to commentary by Gene Spafford in Electronic CIPHER.

Actually, this month's episode, which came in the mail this morning, talks about the same windows of exposure.

I can hartly recommend this newsletter to everyone!

Ivo

The flaw is in the security model. The software player eventually gets the decryption key, decrypts the DVD, and displays it on the
screen. That decrypted DVD data is on the computer. It has to be; there's no other way to display it on the screen. No matter how
good the encryption scheme is, the DVD data is available in plaintext to anyone who can write a computer program to take it.

And so is the decryption key. The computer has to decrypt the DVD. The decryption key has to be in the computer. So the decryption
key is available, in the clear, to anyone who knows where to look. It's protected by an unlock key, but the reader has to unlock it.

The DVD software manufacturers were supposed to disguise the decryption program, and possibly the playing program, using some
sort of software obfuscation techniques. These techniques have never worked for very long; they only seem to force hackers to spend
a couple of extra weeks figuring out how the software works. I've written about this previously in relation to software copy protection;
you can't obfuscate software.

It might be a bitter pill for the entertainment industry to swallow, but software content protection does not work. It cannot work. You
can distribute encrypted content, but in order for it to be read, viewed, or listened to, it must be turned into plaintext. If it must be
turned into plaintext, the computer must have a copy of the key and the algorithm to turn it into plaintext. A clever enough hacker
with good enough debugging tools will always be able to reverse-engineer the algorithm, get the key, or just capture the plaintext
after decryption. And he can write a software program that allows others to do it automatically. This cannot be stopped.

If you assume secure hardware, the scheme works. (In fact, the industry wants to extend the system all the way to the monitor, and
eventually do the decryption there.) The attack works because the hacker can run a debugger and other programming tools. If the
decryption device and the viewing device (it must be both) is inside a tamperproof piece of hardware, the hacker is stuck. He can't
reverse-engineer anything. But tamperproof hardware is largely a myth, so in reality this would just be another barrier that someone
will eventually overcome. Digital content protection just doesn't work; ask anyone who tried software copy protection.

His method is somewhat like street performer protocol. It combines public performance with voluntary payment. If no payment is made, then neither is next performance. King releases chapter at a time. There is a British ( I think ) band that funded their studio time through the same concept. They also interviewed the creators of SPP on the subject an NPR. Good listen.

This is exactly the conclusion Bruce Schneier reached while writing Secrets & Lies. His eventual response (in full here) was that security is not about preventing all attacks (which is a hopeless and impossible goal), but rather about managing the risk of an attack. Just because you can't prevent every possible attack on your computer doesn't mean it isn't worth some effort to lower the risk of an attack (or to lower the probability that an attack will cause damage).

"Central clearinghouse" PKI is what SSL uses. SSL certificates are signed by Certificate Authorities (CAs), such as VeriSign. CAs are trusted entities who verify an applicant's identity before issuing them a certificate. A certificate is the same as a public key except that it has more information about the owner - usually the x.509 Distinguished Name which consists of a "common name" (CN), "organizational unit" (OU), "organization" (O), "locality" (L), "state" (S), "country" (C), and sometimes email. For instance, Microsoft's DN is CN=www.microsoft.com/OU=mscom/O=Microsoft/L=Redmon d/S=Washington/C=US. How do you know which CAs to trust? Web browsers typically have a built-in list. Anyone can act as a CA, but when someone views a website which is using one of that CA's certificates, the user's web browser should (and most do) display a warning. Go to Fortify's SSL test page and my HTTPS website. Fortify's certificate was issued by Thawte (who I believe is now owned by VeriSign), a widely-known CA whose certificate is in most/all browsers. My certificate is signed by the "Zevils CA", which doesn't really exist. Your browser should display a warning when accessing the zevils site but not when accessing the Fortify site.

The other popular method of PKI is known as the "web of trust." This is what PGP and GPG use. If you know someone in real life, you have proof of their identity (such as a driver's license), and you both have GPG/PGP keys, you should sign each other's public keys and upload the signed keys to the keyserver. Here's how the web of trust works (with help from the GNU Privacy Guard Handbook):

Alice knows Bob in real life. They both use GPG. Alice knows with absolute certainty that a certain key is Bob's key, and that Bob is who he says he is, so she signs Bob's key with her key. Alice and Bob discuss PKI every day at lunch and Alice knows that Bob has excellent judgement on when to sign a key, so she tells GPG that she trusts Bob's signature on a key as much as her own (she can also give Bob marginal trust or no trust - see GPG documentation for details.) Bob has signed Charlie's key. Thus, Alice trusts Charlie's key. The web of trust, at least in the GPG implementation, is quite flexible and does extend to a depth of more than one. See the GPG handbook for more information.

Of course, PKI is not a magical security fairy that sprinkles security dust on your keys while you're asleep at night. Bruce Schneier and Carl Ellison have written an excellent paper, Ten Risks of PKI (Computer Security Journal, v 16, n 1, 2000, pp. 1-7)

"Central clearinghouse" PKI is what SSL uses. SSL certificates are signed by Certificate Authorities (CAs), such as VeriSign. CAs are trusted entities who verify an applicant's identity before issuing them a certificate. A certificate is the same as a public key except that it has more information about the owner - usually the x.509 Distinguished Name which consists of a "common name" (CN), "organizational unit" (OU), "organization" (O), "locality" (L), "state" (S), "country" (C), and sometimes email. For instance, Microsoft's DN is CN=www.microsoft.com/OU=mscom/O=Microsoft/L=Redmon d/S=Washington/C=US. How do you know which CAs to trust? Web browsers typically have a built-in list. Anyone can act as a CA, but when someone views a website which is using one of that CA's certificates, the user's web browser should (and most do) display a warning. Go to Fortify's SSL test page and my HTTPS website. Fortify's certificate was issued by Thawte (who I believe is now owned by VeriSign), a widely-known CA whose certificate is in most/all browsers. My certificate is signed by the "Zevils CA", which doesn't really exist. Your browser should display a warning when accessing the zevils site but not when accessing the Fortify site.

The other popular method of PKI is known as the "web of trust." This is what PGP and GPG use. If you know someone in real life, you have proof of their identity (such as a driver's license), and you both have GPG/PGP keys, you should sign each other's public keys and upload the signed keys to the keyserver. Here's how the web of trust works (with help from the GNU Privacy Guard Handbook):

Alice knows Bob in real life. They both use GPG. Alice knows with absolute certainty that a certain key is Bob's key, and that Bob is who he says he is, so she signs Bob's key with her key. Alice and Bob discuss PKI every day at lunch and Alice knows that Bob has excellent judgement on when to sign a key, so she tells GPG that she trusts Bob's signature on a key as much as her own (she can also give Bob marginal trust or no trust - see GPG documentation for details.) Bob has signed Charlie's key. Thus, Alice trusts Charlie's key. The web of trust, at least in the GPG implementation, is quite flexible and does extend to a depth of more than one. See the GPG handbook for more information.

Of course, PKI is not a magical security fairy that sprinkles security dust on your keys while you're asleep at night. Bruce Schneier and Carl Ellison have written an excellent paper, Ten Risks of PKI (Computer Security Journal, v 16, n 1, 2000, pp. 1-7)

No geek's bookshelf is complete without this one. It's an approachable and practical coverage of encryption technology with a focus on application and use.

Is ssh or apache ssl based on the RSA algorithm or the BSAFE software?

Oh, and ssh is based on RSA algorithms, tho' it also has Blowfish available. To get around the licensing restrictions around RSA, the OpenBSD guys have you download OpenSSL first and build ssh by linking to the OpenSSL crypto shlibs .... The newer version of ssh (Version 2) doesn't use RSA crypto, BTW.

Check out the OpenBSD crypto pages

Schneier's 8/15 Cryptogram newsletter touched on these issues weeks ago.

Namely, if capability like the US government's Tempest technology (reads electro magnetic pulses, CRT, keyboard radiation, etc. - spy craft stuff) is available, it's a matter of time before such tactics are _readily_ used on commonplace bluetooth devices doing private or delicate matters in public. After all, reading your OpenSSH-downloaded, and GnuPG encrypted email privately to yourself in the back booth might seem secure, but, what if a black hat type is capturing your radiating emissions quite easily? Illusory protection. Treat Bluetooth as a broadcast protocol, because that's what it is, says Schneier.

What amazes me is the dearth of information about the security of this protocol. I'm sure someone has thought about it, a team designed some security into Bluetooth, and that those designers believe it to be secure. But has anyone reputable examined the protocol? Is the implementation known to be correct? Are there any programming errors? If Bluetooth is secure, it will be the first time ever that a major protocol has been released without any security flaws. I'm not optimistic, continues Schneier.

Check out some of these articles on Bluetooth, and it's lack of discussion on it's possibly inherent security shortcomings.

Bluetooth

A list of Bluetooth articles, none of them about security

One mention of security

An essay about the Bluetooth hype

Recent article on TEMPEST

Me pican las bolas, man!
Thanks

In you followup post, you seem to infer that the code you write is exempt from the emperical rule that every thousand lines of quality code will have three bugs on average. Of course, I've not read any of your code, but if you write error free code I've got a job for you. I think I'm a pretty good coder, but I come across the "how did I ever overlook *this*" kind of bug more often than I care for.

The article obviously was not written with coders as the primary audience, so you'll have to read through some of the parabole that's just to get peoples attention. As Bruce explains in his latest CRYPTO-GRAM newsletter, his biggest eye opener was that attaining perfect security (even if the code itself is perfect, which it is rarely if ever) is impossible, and therefore we (as coders and sysadmins alike) should focus more on detection and damage control, and less on perfection. I cannot fault any of his reasoning.

Anyway, when judging his work, I'd suggest to look more at his freely available writings and less on the secondhand hype like on Salon. Counterpane has a pretty complete history of his musings. They're free, and very entertaining to read (my favorite is his "doghouse" column), and it paints a much better picture of what to expect from the book.

I believe the moral of the book (which I gather from Bruce's comments in Crypto-gram) is that security breaches are inevitable, and therefore it's imperative to have a recovery plan.

He doesn't claim that since perfect security is impossible we should stop trying to attain it. He says that we need to stop assuming our efforts will always protect us and make sure we're prepared for the alternative.

What is being sold today under the Intrusion Detection System label usually is a cobbled together set of attack signatures that spuriously trigger thousands of times per day. The ones I've seen do not have the flexibility to do things like suppress the check for ".asp." if a word consituent character follows it. And needless to say, the way they work, chances are that successful attempts to break in are overlooked.

This of course if yet another instance of false security. A lot of work has to be done still to make IDS systems work reasonably out of the box, and that is not even taking issues like training into account.

Mind you, people who actually read the book will know better, but I've lived in corporate hell for much too long to know just where this IDS thing will end. "Do we have a firewall? Check. Do we have an IDS? Check. Hey, what's this guy doing on our systems? Call legal and sue the IDS vendor."

That's one of the reasons Schneier rocks as hard as he does. He's a down-to-earth kind of renaissance man and he's pretty much always been like that in the years I've known him. Not only is he one of the best 10 or 50 cryptographers in the world (of which about 40 are probably NSA), but he's a regular guy. I had the good fortune to see Richard Thieme speak and he's similar in that regard (though he's more of a humanities guy than a science guy).

I read something recently describing a self-proclaimed epiphany he experienced a few years ago that set him in the direction of holistic security versus the crypto-heavy approach he favored since he entered the field. I'd be curious to know more about it because I felt he's always had a hint of that approach. Just go back and read his essays "Why Cryptography Is Harder Than It Looks" and "Security Pitfalls in Cryptography"... substitute "cryptography" for "computer security" or "network security" and you'll see what I mean.

In 1996 I think it was, Bruce, Niels Ferguson, and I were working on the problem of creating a file system offering plausible deniability of the existence of any files the user wanted to keep secret. We came up with some really neat ideas on how to avoid creating proof that certain files existed. I think it would have worked, but I made the realization that it wouldn't work successfully with technology of the day. Microsoft Word (heck, the Start -> Documents listing broke us too) will list the last several documents accessed: what if one of them was supposed to remain secret? If it's hidden, but the attacker sees you modified it and they can't find it, the game is over--you can't deny it exists and the system is broken.

Why is this such a big problem? Because if we were to create a special OS and set of applications that didn't track that stuff, the only people who would use it were those with something to hide (this wasn't a court of law--we couldn't assume you were innocent until proven guilty). So, the user loses the game before it even started simply by having that special OS and application set.

Keep on "keeping on", Bruce.

That's one of the reasons Schneier rocks as hard as he does. He's a down-to-earth kind of renaissance man and he's pretty much always been like that in the years I've known him. Not only is he one of the best 10 or 50 cryptographers in the world (of which about 40 are probably NSA), but he's a regular guy. I had the good fortune to see Richard Thieme speak and he's similar in that regard (though he's more of a humanities guy than a science guy).

I read something recently describing a self-proclaimed epiphany he experienced a few years ago that set him in the direction of holistic security versus the crypto-heavy approach he favored since he entered the field. I'd be curious to know more about it because I felt he's always had a hint of that approach. Just go back and read his essays "Why Cryptography Is Harder Than It Looks" and "Security Pitfalls in Cryptography"... substitute "cryptography" for "computer security" or "network security" and you'll see what I mean.

In 1996 I think it was, Bruce, Niels Ferguson, and I were working on the problem of creating a file system offering plausible deniability of the existence of any files the user wanted to keep secret. We came up with some really neat ideas on how to avoid creating proof that certain files existed. I think it would have worked, but I made the realization that it wouldn't work successfully with technology of the day. Microsoft Word (heck, the Start -> Documents listing broke us too) will list the last several documents accessed: what if one of them was supposed to remain secret? If it's hidden, but the attacker sees you modified it and they can't find it, the game is over--you can't deny it exists and the system is broken.

Why is this such a big problem? Because if we were to create a special OS and set of applications that didn't track that stuff, the only people who would use it were those with something to hide (this wasn't a court of law--we couldn't assume you were innocent until proven guilty). So, the user loses the game before it even started simply by having that special OS and application set.

Keep on "keeping on", Bruce.

A cryptographic hash takes an exact set of bits to result in the hash, a very exclusive operation. It's excluding all of the wrong values. If any of the bits in the configuration are slightly off, then there's a very high likelyhood that the hash will be completely different.

I believe common sense will tell you it is easier to do that than to loosely define a large set of bits that will result in the same hash. And furthermore, the boundary for the bit bag is defined by human intuition (psychoacustics) and empirical research (trial and error).

Granted, lots of hashes are created by people tinkering with an algorithm, but there are excruciatingly detailed and highly refined tests that'll tell how good the algorithm is. The development of the algorithms and tests are based on information theory and statistics.

What are the tests for the audio fingerprinting based on? The answer appears to be our grossly underdeveloped understanding about how the human mind processes sound all the way through to making comparisons between different samples of music. I seriously doubt that something hinging on human intuition and interpretation as part of the algorithm can overcome the fact we don't understand how people's mind work to any acceptable degree.

I spent some time thinking about a way to fingerprint music, and it is a very hard problem to come up with something that captures the essense of our perception of music. Simply doing that is a huge accomplishment. It involves distilling down human methodology for sound recognition, something that is based on a massivly parralel biochemical neural network, or at least something we can only crudely model as a neural network, into a mathematical formula that can be implemented efficiently on a processor.

It is much more likely this won't work because there's a fundamental difference in the platform these two tasks are done on: subjective analysis by a person of some music as to what is and is not the same and some convoluted algorithm attempting to approximate that process on a von-neuman style computer. I won't hold my breath, no matter how cool the idea is. And it is very cool.

They would probably have better luck building a neural network and training it against a large set of people to attempt to capture their collective equality operation

I doubt they will reach their goal, but if they can come up with an algorithm that reasonably sorts music the way people do and to satisfactorally compare music, it will still be very powerful. I personally would love to see such technology be successful.

The ability to emulate how people discern music and to detect differences between samples is tremendous. If nothing else I can finally catalog my music intelligently and to seek new music that will be something I very likely will dig.

Imagine listening to a song that really scratches an itch, taking the fingerprint of that song, even if it is from the radio and getting songs that scratch the itch the same way from a database. How cool would that be?

Not only that, but we'd need that sort of technology in order to find musicians and bands (there is a distinction) that we like if there isn't a huge mega-media-greedy conglomerate driving the mindshare and play time. Combine that with reputation certificates and something like SPKI and you've got a very successful way to implement the Street Performer's Protocol (see the recent /. story)

A reputation certificate is similar in concept to what eBay does with its sellers in capturing the history of the person to create a mark of how reputable that person or entity is, but it goes one step further and cryptographically binds that information to to an identity. See the SPKI document above for detailed information.

This is stuff that needs to be worked on and I salute tuneprint for working towards that goal.

I refuse to follow ads that simply say "Click Here!" My time is worth more than that.

"Click Here" really is bad form. A link is supposed to describe where it goes to. You should be able to rip out all of the links on your web page and list them, with the linked text, and have a handy list of links - just like Slashdot does. It only takes a few seconds worth of creativity to come up with a meaningful link.

Also, "click here" assumes that you're using a mouse. That may be true now, but it shouldn't have to be so. How do you suppose a voice interface to the web will work? Most likely, if you want to "click" on a link, you will say the underlined phrase. For example, when viewing this post with a voice-capable browser you should be able to simply say "Google" or "Crypto-Gram" or "Big Ball of Mud" and be taken to the appropriate place. It's better than having to say "'click here' number 8... no, the one in the seventh paragraph... not that one, go left, up, up, click!"

Really - the people who created hypertext actually did think of this stuff. HTML was supposed to be device-independant, not "optimized for a box on a desk running browser-of-the-week with an 800x600 screen on a 15" monitor and a default font size of 'tiny'".

</RANT>

Looking beyond the specific case to the general question...

It's surely news to nobody that traditional approaches to copyright don't mix well with the net. What possible solutions to this are there?

We can abandon the notion of copyright. That raises the question of how creators are to be compensated. Personally I give some of the software and fiction I've created away - but not everyone is happy with this, and I wouldn't be happy if some of my favourite authors (say) had to gave up writing because they couldn't make a living from it.

The Street Performer Protocol will doubtless be familiar. That's one approach that might be useful. Another approaches might be for the state to support artists - this already happens to an extent anyway in some countries, but has the difficulty that you end up with a bias towards whatever the state (or its agents) prefer. (But would that be worse than a bias towards what the record companies prefer?) You have to collect the money, too, and new taxes are rarely popular.

We could do it through voluntary donations - charity, essentially - but that could be a bit hit-and-miss.

If we want to keep the notion of copyright, we could enforce it very strictly. But that would be expensive and intrusive even to do badly, and is surely impossible to do well.

We could all fit hardware-supported digital rights management subsystems to our computers, but that would again be intrusive and may be hard or impossible to do well; it'd only take one "chipped" PCs for the copyrighted cats to get out of the bag.

One can imagine a system where the content provider distributes (via the net, radio, etc) encrypted content to a tamper-proof player (hifi, TV, walkman, toaster, etc) in your home that they've sold, rented or just given you, and charges micropayments for each performance. The infrastructure costs would be hideous, though, as would be the impact on individual choice of playback equipment, and again once unencrypted versions of the content becomes available the whole systems falls apart.

We could just ignore the problem, and trust that unauthorized copying isn't such a huge problem after all. This might even be true; I still buy music CDs despite knowing that digital copies are often (illegally) available for nothing, for example.

Any other suggestions?

... is here. It includes the preface of the book.

Perhaps something like Bruce Schneier's Street Performer Protocol would work for sites like this?
--

1. a right, which can only belong to the author, over the first release of their work (not over subsequent copying &c) and to stop others using their creation for profit.

Can't make money? Bollucks. See the Street Performer Protocol and Stephen King making it happen

2. A short time-limited non-transferable patent where the application is made public for a real search for prior art (not half an hour in the patent office). A development period of, say, 12 months and then a limited revenue period to re-coup costs and, say, 20% profit.

After that it's public domain.

Cheers
James

The only digital-media distribution systems that make sense are RMS's tax-based proposal, the Street Performer Protocol, and the electronic tip jar. All of these schemes share two traits:

1. they don't prevent people from copying a digital work and not paying
2. over 90% of the money that the customer pays or gives in these schemes goes directly to the artist

1. includes some form of copy protection or watermarking
2. maximizes the baksheesh that record companies can get from the blockbusters they push

This isn't another generic Freenet-will-kill-intellectual-property article. The Uprizer project will sell music. The description is vague (and the spec is secret until December), but evidently it will use some form of Street Performer Protocol. Anyone want to guess how this will work?

Maybe artists will release two songs and "threaten" to sign with an RIAA distributor unless they get enough contributions to live on.

Maybe they'll release the really catchy refrain to a song, and withold the rest (so you can't get it out of your head by singing it).

Maybe they'll play half a fugue and request payment before returning to the tonic...

- Michael Cohn

Focusing on the cryptographic algorithms while ignoring other aspects of security is like defending your house not by building a fence around it, but by putting an immense stake into the ground and hoping that the adversary runs right into it. Smart attackers will just go around the algorithms.

If they wish to limit themselves to watermarking, then they'd have to design a watermark that doesn't leave audible artifacts but is robust enough to survive transmission through analog air. I sure wouldn't want to bet my livelihood on them coming up with one.

Because the PC platform will never be a trusted client. Bruce Schneier has written about this here.

I prefer a model like the "Street Performer Protocol" recently utilized by Stephen King. I'm also fond of voluntary contributions to artists and other creators. What I would not like to see is a huge bazaar where Joe Average gets 5 bucks for trading the latest Harry Potter and J.K. Rowling gets nothing for writing it.

--

Applied Cryptography has a good overview of the protocols required to handle digital money.


...phil

Microsoft has improved PPTP to correct the major security weaknesses described in [SM98]. However, the fundamental weakness of the authentication and encryption protocol is that it is only as secure as the password chosen by the user.

Microsoft has improved PPTP to correct the major security weaknesses described in [SM98]. However, the fundamental weakness of the authentication and encryption protocol is that it is only as secure as the password chosen by the user.