Slashdot Mirror

Everyone is whining about "security through obscurity". Well, sorry, the other forms of security are already gone -- that's what it means that there's a security bug. Security through obscurity is better than nothing.

Unlike closed source projects, even a general description of the problem might be enough to find the exact bug, and to develop an exploit for an open source project. This means that it's even more critical that the nature of the bug isn't leaked until a solution or work-around is known.

What if someone found a hole in Apache? Should they post it far and wide, or should they quitely pass it along to the main developers so that the hole can be closed before half the world's websites are replaced by "ThiZ Site HAXed by KeWl d00d"?

Bruce Schneier addressed this in a recent cryptogram. See: http://www.counterpane.com/crypto- gram-0001.html

Of course, there is the possibility of Netscape taking the microsoft approach -- just ignore it until actual damage is caused -- but I think this is unlikely. They are already agreeing that the bugs need to have a distribution other than netscape only. I think it's pretty unlikely they would let security bugs be swept under the rug.

--Kevin

The Street Performer Protocol has potential to be an excellent distribution model. If you haven't read it before, Joe Bob says check it out.

The full paper is available from http://www.counterpane.com. <rant>Unfortunately, Bruce Schneier hasn't yet realized that PDF and Postscript are only appropriate for printing, not publishing on the Web</rant>.

The full paper is available from http://www.counterpane.com. <rant>Unfortunately, Bruce Schneier hasn't yet realized that PDF and Postscript are only appropriate for printing, not publishing on the Web</rant>.

As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice.

And the common "their encryption sucks, it's their fault" argument is trash. If someone breaks into your house because they could smash down your door, is it your fault that you didn't have steel bars?

I don't think this analogy quite sticks. Cyberpatrol isn't analogous to one person's house -- it's a product that's being marketed as secure but really isn't, as Skala and Jansson have demonstrated.

If a company was marketing a "break-and-enter-resistant" house, but someone exposed a flaw in the design that allowed intruders to get in through a basement window, it would be prudent to publish those findings so that consumers would be warned about this weakness.

The last few issues of Crypto-gram, Bruce Schneier's monthly cryptography newsletter, have discussed the ethics of the publication of security flaws. Back-issues can be found at www.counterpane.com.

I liked the posts on "Ideas are not the same as Expression" and "Private Property" ("... Economic systems derive from the fact that resources are limited.") below. New songs are Expressions, so (making loads of assumptions about capitalist worldviews etc.) it makes some sense to copyright them -- people had to make an effort to create them. OTOH, each CD of a song takes very little effort to create, so doesn't fit into the "scarcity economics" model.

Not that I've got all the answers(!) but how about finding a way to pay people for creating something rather than for getting a (cheap) copy to you? The Street Performer Protocol (previously seen on /., I'm sure) suggests one way to do this: in brief, lots of readers pay authors a tiny advance on their next work. Several unresolved issues, and I don't recall it addressing the question of how an artist becomes "known enough" that people would be willing to make such an advance, but interesting anyway.

As for doing "honest" work as well: I've nothing against people doing all "honest" work or all "creative" work but personally I think I might like to do a bit of both; e.g., work 3-4 days a week and write free software (or whatever) for the other 1-2 days (and however much of my weekend it took up ;-). I suspect (i.e., completely guess ;-) this is how most free software has been written -- people need to make at least enough to live on.

Hugh Greene, q@NOSPAM.tardis.ed.ac.uk

As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice.

I think your comments are on-target. According to current published technology, 128-bit encryption (and by this I mean TwoFish and other 'strong' algorithms) is tough. Who's to say what the NSA has cooked up, though. Mr. Schneier is far more qualified to comment. I would recommend http://www.counterpane.com/pitfalls.html for his assessment.

Your understanding of #2 is correct, I believe.

I'm pretty sure that all Public Key Crypto systems work the same way. A session key is generated (if this isn't random, it's a place to attack) and encrypted using public key crypto. The message itself is encrypted using a symetric algorithm. Thus you can do 2 things to try to read the message:

1. Brute force the key for the symetric algorithm.
2. Try to crack the public key/private key pair. This will then allow you to decrypt the session key for all communications, not that particular conversation.

Ideally the determining the private key is much harder than brute forcing the symetric algorithm (since it allows you to decrypt *all* messages).

Cheers,
Slak

Also, there are several related links on the Personal Security page of the Center for the Study of Technology and Society.

Finally, if you want the wire version of the story, click here.

Yours,
A. Keiper
The Center for the Study of Technoloy and Society

• The designers of the cryptosystem seem to think that 64 bits is enough for general use. This does not bode well.
• The spec does not mandate a known-good random number generator. It has been shown in the past that designing one is a very difficult task that few people do right the first time. This opens the way for lame randomnumber generators in devices.
• I have not been able to find any good references to the crypto algoriythm used. This, again, is not a good sign. Remember GSM anyone?
• The spec claims Bluetooth uses a modified SAFER for authentication. Bruce Schneier has this to say about SAFER: SAFER was designed for Cylink, and Cylink is tainted by the NSA. I recommend years of intense cryptoanalysis before using SAFER in any form.

These things do not fill me with confidence.

Disclaimer: I am not a cryptographer. Someone with more clue than me is more than welcome to show me the errors of my ways

Bruce Schneier mentioned something like this while covering the DVD encryption hack in the November Crypto-Gram (monthly newsletter). See here

" 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."

Do recall that I am *not* supporting mixter's action. I am, however,
arguing that sometimes publishing tools that make it painfully obvious
that certain security vulnerabilities can be exploited *can* be a good
thing. I note that Bruce Schneier's latest Cryptogram
comes to pretty much the same position as I. He's come from the
opposite direction to me, though: I used to think it was always
irresponsible to publish such code, until the CDoC's BackOrifice was
published.

Yes, it's just marketing, but it's not as orchestrated as it might seem. In these cases, the news agency that publishes the story is often not "in on it"; they simply haven't put in the journalistic effort to separate news from marketing.

Bruce Schneier wrote about this marketing tactic a month ago in his Crypto-Gram. You can read the details there, but here's the gist: nCipher has a product that solves an insignificant problem, issues a press release about how horrible the vulnerability is, and the New York Times publishes an article about the vulnerability and nCipher's solution. I doubt that the NYTimes did this for the sake of advertising nCipher; they probably just didn't have the experience to see that the suggested attack was nothing remarkable.

The fact that Computer Currents just pulled the article indicates that they came to their senses:

Due to flagrant inaccuracies this article has been pulled and is being re-written.

Occasionally one of these slips through the editorial process. Computer Currents regrets the error.

There are (of course) security risks, but not as you describe it.

Let's see what happens if X publishes my public key, without having my private key. If X encrypts a document with his own private key and someone else tries to decode it with my public key, the result will be garbage, thus proving that X is not related to me.

However, there still are some problems. If X gets hold of my private key, he can indeed identify himself as me.

Another related point: with some math and some tools I can create my own private/public keypair, and announce that it is the pp keypair of my neighbour. So, in order to verify that the pp keypair is really mine, a third party must guarantee that the keypair belongs to me. (Just like the government guarantees that I'm me by issuing passports.) However, a while ago there was an article on /. by Bruce Schneier, where he argues that we're not yet ready to have such third parties.

I think one solution that has been overlooked in this discussion is that there are ways of (at least somewhat) validating people's identities for the purpose of corresponding on email with a congressional staff.

If it is the goal of the office to cut down on the spam they recieve, why not set up a system where you can fill out a form, and the rep will send a snailmail letter to the address (obviously in the rep's district) with a user/pass for a web-based email system or something similar. I suggest this not because I think it is the most efficient or even what I would prefer, but congresscritters seem to have a desire to attach identity to a meatspace address.

Similar, systems could be created using PGP and the associated 'web of trust' that can be assigned to key signatures. (This is extremely unlikely to happen until I'm old and gray(er) as it is a bit too technical for the average critter's staff to deal with.)

To illustrate this, the last time my congressional rep (Sam Johnson) came to town for a 'town hall' meeting, I queried his aide that was supposed to be 'point' on tech issues and he had no idea what PGP is. Considering the legislation that has been submitted ojn the topic, one would think he would at least know about the most popular encryption program outside of DES

Some congrescritters have something similar to this set up off of their house/senate webpages. I actually got what appeared to not be a form letter from a query I made to one of these systems. Admittedly, such a system is a hell of a lot more trouble to use than regular email, but I suspect this is considered by the office as it weeds out those not willing to take the time to set up an account with them. I have a couple of these set up, but it's been so long since I used them I forgot how I signed in :( This is where a program I recently started using would have come in handy. Hope I won't get slammed for this, but I'd like to recommend 'gpasman' as a linux program that will help you to keep track of user/pass combos for websites or other systems. You can find it at http://gpasman.nl.linux.org/. It is similar to a (win) tool offered by Counterpane Systems called Password Safe (binaries and source). I use them both. Too damn many accounts and passwords to keep up with these days!

Z

First off, there are profound performance differences that can be acheived simply by optimizing for the Pentium Pro and not the Pentium, see The Twofish Implementations. This is mainly just instruction ordering issues- possible to do in a JIT. There's more to optimization anymore than simple cycle counting.

Second, memory management is a different beast under object oriented programming than under procedural programming. The holy grail of object oriented programming (as it were) is black box reuse- allowing a class maintainer to modify how a class works without those using the class needing to change their code. Not having garbage collection in an OO language either disallows true black-box reuse (which is a maintainability issue), forces the object to implement it's _own_ garbage collection (such as the C++ STL template basic_string does- and this is generally the worst sort of garbage collection, such as basic_string's reference counting), or forces the program to leak memory like a seive. If those are the options, then garbage collection is not too high a price to pay.

Especially when you consider that GC isn't that high of a cost. _Every_ memory management scheme that isn't static in nature that I've seen is O(n). Either on the allocation or on the free. Sooner or later you have to search for a hole. GC doesn't remove this penalty, but instead it allows you to _defer_ it until a better time. Since most programs spend most of their time waiting for input, there are lots of places where garbage collection can be free because the program isn't doing anything else.

Last, but not least, I'd like to point you at the The GC FAQ, a good resource for all things GC related. Highly recommended reading- after it, it was "intuitively obvious" that the world was flat, that the sun went around the earth, and that time didn't slow down as you went faster.

last week there as talk about Bruce Schneier's article "Key Finding" Attacks and Publicity Attacks. Newspapers. I guess neither M. Kaspersky doesn't read /.

Yes, but have they ever cocked it up quite so spectacularly as MS did with their implementation of PPTP ? I would be hard pressed to trust any company who produced something like that and called it a security feature, (feature in the opposite sense to "feature").

If a company is so massively incompetent as to implement a protocol so that it transmits a weaker hash along with a secure hash of the same password string by design, without even allowing the user to turn it off, I think I'd have doubts about that company. If the weaker hash had no salt, and converted all characters to upper case, making a dictionary attack trivial beyond belief, I'd start pointing to them and being generally derisory. And this is only part of the monumental failure that was MS-CHAPv1.

For the full (and more than slightly amusing) details, check the paper here

Coerced votes are not unique to online voting. Absentee ballots have the same potential for coercion, for the same reasons, and it has turned out not to be too much of an issue. See the letters at the end of the last issue of Crypto-Gram here.

In short, absentee ballots account for as much as 35-50% of the vote in some elections, certainly enough to change the outcome of an election, and they continue to be used despite the possibility of coercion.

Of course, online voting has many, many other problems. I just don't think coercion is one of them.

In Bruce Schneier's latest Cryptogram, he says online voting scares the hell out of him.

Speaking of Blowfish and block ciphers, Bruce Schneier has some very interesting comments on the convergence of stream and block ciphers in his newest monthly Crypto-Gram.

-------

Reading this article, I got a very anti-programmer feeling. The author seemed to be saying that any moderatly decent coder should ba able to make secure code. Anyone who writes on internet security should be forced, at gunpoint, to read this essay, lest they take the same attitude. The fact is, writing code that works is hard, and writing code that is secure is an order of magnitude more difficult. However, there are reasonably secure packages out there, so if anyone is to blame for these lost credit card numbers, it is the administrators and managers responsibility. It just seems clear to me that the fault lies not even with MS SQL, but the administrators.

TWINKLE - The Weizmann INstitute's Key Locating Engine

You people need to learn about smartcards. Start at Schlumberger and Litronic (they have a good intro to smartcards.) and go from there. The people at ZeitControl have this cool programmable card that you should look into.

Even if the algorithms used in CSS were perfect in every way, it would never have worked.

I was going to have a go at explaining why but it turns out Bruce Schneier has already written a wonderful explanation, so I'll just quote him.

... even if [the encryption scheme] were all perfect, the scheme could never work.

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.

In the end, it's nothing that spectacular: it's about identifying public and and unencrypted secret key data in a stream of bits with lots of other data. Although it seems as if nobody has thought about this kind of attack before, other forms of attack, based on additional characteristics of the key (for example, that it is contained in an OpenPGP packet), were certainly known, and it is quite likely that systems designed to be immune against this kind of attack (i.e., by employing tamper-proof hardware or storing critical key material on a strongly protected separate server) will resist the new (old) one as well.

Of course, only few people in the modern e-commerce world care about security on their sites, so some media attention, although a bit late and a bit exaggerated, is always a good thing.

Would the team of R, S, and A (I don't remember the names offhand) have bothered to make their public-key algorithm, and then to publish it so that the rest of us could check for weaknesses, if they didn't have the promise of profit by license royalties?

You might also want to check out some of Bruce Schneier's work to see if he's patented his encryption algorithms. A quick check of counterpane.com turns up this page on Blowfish, indicating that it is now part of OpenBSD (and almost certainly not patented). Even if RSA did patent theirs, it doesn't mean that they set the standard.
--

Sure, it'd be great if authors were paid for the service of writing a book, rather than for the book itself, but who will do the paying?

Readers. It hasn't taken off yet, but people are working on it. Street Performer Protocol is one attempt to work out a way of doing it. Buskware is another. Popular mainstream author Stephen King attempted a variation on this a few months ago, but it failed (although there is quite a bit of debate over the reason it didn't work.)

The point is, people are working on this problem and trying out ideas. It's still young. There are definately plans being drawn up for getting the bell onto the cat, and even a few abortive attempts. It'll get better with time.

Why not use binary builds of the executable files digitally signed by the builders, and have the servers check the signatures against a trusted certifying authority?

Because signing binaries doesn't work. (Not for this problem.) How does the server know what the signature of the client-side binary is? Because the client told it. Carmack's suggestion of using a loader to checksum the binaries, rather than having them checksum themselves, also doesn't work: that just adds another level of indirection and changes the problem from "hack the client" to "hack the loader."

This stuff is easy. People have been cracking harder copy-protection than this for years. And in fully closed-source environments.

Like I said yesterday,

When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender.

To oversimplify: you can know who I am, but you can't know that I'm telling you the truth.

Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using.

This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption.

Why not use binary builds of the executable files digitally signed by the builders, and have the servers check the signatures against a trusted certifying authority?

Because signing binaries doesn't work. (Not for this problem.) How does the server know what the signature of the client-side binary is? Because the client told it. Carmack's suggestion of using a loader to checksum the binaries, rather than having them checksum themselves, also doesn't work: that just adds another level of indirection and changes the problem from "hack the client" to "hack the loader."

This stuff is easy. People have been cracking harder copy-protection than this for years. And in fully closed-source environments.

Like I said yesterday,

When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender.

To oversimplify: you can know who I am, but you can't know that I'm telling you the truth.

Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using.

This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption.

For example, using PGP you can sign an email message and others can then verify that the message really came from you. Obviously the same thing could be done for an executable file

Unfortunately, this isn't true.

When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender.

To oversimplify: you can know who I am, but you can't know that I'm telling you the truth.

Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using.

This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption.

For example, using PGP you can sign an email message and others can then verify that the message really came from you. Obviously the same thing could be done for an executable file

Unfortunately, this isn't true.

When you receive a signed message/packet/whatever, the recipient can verify that the sender of that packet had access to the private key that corresponds to a particular public key. That doesn't say anything about the integrity of the message, only about the set of secrets known to the sender.

To oversimplify: you can know who I am, but you can't know that I'm telling you the truth.

Where do the private keys come from? If they are embedded in the Quake executable, then anyone can extract them and use them to sign anything. If they come from PGP's web of trust, then still all you've done is verify the identity (or pseudonym) of the player -- not of the software that they are using.

This is all very similar to the general copy-protection problem as well as the fundamental impossibility of DVD encryption.

Barring the device driver based hack, the situation you have with the networked game is much like a distributed computing situation. In fact, the network game could be considered to be just a large distributed computer for putting pixels on the right place on each player in the system's (game's) screen. Most of the distributed computing projects (distributed.net, seti@home etc) do suffer from the same problem of people cracking the protocol and lying to the coordinating servers about what is actually going on, and it does seem that most of them end up relying on closed protocols and source code to keep it from being a problem. Distributed.net seems to use the same tactic for spotting cheaters as I use on my local Quake server, ie "they are too good".

However, a lot of work does seem to have ben done, at least in theory, on making distributed computing truly secure, so it might provide a place to start. A quick search through Counterpane's list of crypto papers gave quite a number of hits on the subject. I doubt you could create a truely secure protocoll today (for speed reasons) but this is a problem that is only getting worse as time and technology advances...

-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.

Of course as Bruce Schneier points out, PKI ain't such a secure and necessary deal as it's made out to be, so to a certain extent Verisign is just smoke and mirrors.

I've always thought that Thawte did
a better job than Verisign. They are cheaper
too, I believe..(though it's been a while)..

They do NOTHING for you! They don't even
make your site more secure...
They are snake-oil salesmen, at best.

Watch as Bruce Schneier gives these jerks a firm talking-to: here

I'm interested in hearing for people with better insight then myself into this sort of programming, if it is plausible to write a program where the key cannot be retrieved from the memory when the encryption is going on?

Not only is it implausible, it is theoretically impossible without tamper-proof "black box" hardware to help.

Read Bruce Schneier's latest Crypto Gram for a better discussion of this topic than I could give you, but here's a thought experiment or two to get you started:

People are going to want to play DVD Audio with their existing DVD-Rom and sound card (albeit at "only" CD quality levels), without getting a special "DVD audio card", right? So that means that DVD Audio players will have to come out that use existing Windows sound drivers. What's to prevent someone from writing a dummy sound driver that simply stores unencrypted audio to disk? Or from hooking up the digital output on their high end sound card to the digital input, and recording while they play?

Even if Windows 95/98 didn't let you pretty much bypass the kernel (Check out the Wine devel lists for info on Bleem's naughty tricks) to get a complete memory dump at any point in time, you could always do just that with Win9x running on a virtual machine in VMWare; just suspend the VMWare process and dump /proc/processid#/mem to examine at your leisure. (or dump /dev/kmem if necessary; doesn't VMWare require kernel patches or some similar weirdness?)

Anyway, they're fighting a losing battle. Computer systems aren't black box hardware, and they're going to stay that way.

But the reason that the keys could be shorter may now be invalidated with the proving of this conjecture, I don't know enough of the math but to quote from the latest Crypto-gram newletter:
'All of the fastest algorithms for calculating discrete logs -- the number field sieve and the quadratic sieve -- make use of something called index calculus and a property of the numbers mod n called smoothness. In the elliptic curve group, there is no definition of smoothness, and hence in order to break elliptic curve algorithms you have to use older methods: Pollard's rho, for example. So we only have to use keys long enough to be secure against these older, slower, methods. Therefor, our keys can be shorter. ... Whether this recommendation makes sense depends on whether the faster algorithms can ever be made to work with elliptic curves. The question to ask is: "Is this lack of smoothness a fundamental property of elliptic curves, or is it a hole in our knowledge about elliptic curves?" Or, more generally: "Are elliptic curves inherently harder to calculate discrete logs in, or will we eventually figure out a way to do it as efficiently as we can in the numbers mod n?" '
Does the proving of this conjecture open the way for a 'smoothness' function to be defined? Crypto-gram can be found at: http://www.counterpane.com/crypto-gram. html
Brian Haskin

There is a public-key system called "Blum-Blum-Shub" (I believe) that does pure public-key stream encryption. It is provably as secure as factoring, unlike RSA. See AC by Schneier for details. This, like all good stream ciphers also makes an excellent pseudo-random number generator.

Answer number two: As other posters have indicated, known public key algorithms are too slow to be of much use in encrypting large amounts of data. If you look at existing implementations, nobody does bulk encryption with a public key algorithm. Generate a random session key, send it to the other end encrypted with your public key algorithm, then use a stream cipher of your choice to do the bulk of the work.

This means, as hinted at above, that you don't just need an algorithm you need a protocol. Your protocol must address questions about how you generate your keys, how once side informs the other, who gets to generate them, how often (or if) they change, etc. It is possible to keep your protocol quite simple, but you need to at least think about such things.

Answer number three: In a word "modes". There are various ways to apply block encryption algorithms such that you can use them as stream algorithms. Because the public key algorithms are slow, this application will be slow, but it does work and is generally considered an OK cryptographic practice to apply the various modes where appropriate. So, what are the modes? What are their pros and cons? See chapter 9 of Bruce Schneier's Applied Cryptography.

If you are interested in this stuff, then you should really get a copy of Schneier's book and check it out. It's chok full O' cryptographic goodness. If your local bookstore doesn't have it, then fatbrain.com or your favorite online bookseller will.

One final thought. Messing around with crypto is a lot of fun, but it is harder than it might seem. There are a lot of implementation pitfalls that can render your crypto worthless or nearly so. When you are doing something really important, stick to existing algorithms and implementations.

I use entirely random means of generating passwords. Computer programs generate most of my passwords; Diceware works well for passphrases, and a modified form can be used for simple passwords as well. During the time it takes for me to memorize the passwords, I place them in a PGP-encrypted file on a floppy; after they're safely locked away in my mind, I burn the disk, grind the ashes up, and throw them into running water. Although I'm not sure exactly how secure it is, Password Safe on Windows is good for managing low-security website logins.

But if I didn't use entirely random schemes, I wouldn't be telling anybody. Why are so many people here giving away their schemes?

Sure, I may be paranoid; if the scheme is good, describing it only reduces its efficacy, and not many crackers will take the time and energy to analyze a scheme of that sort to attack one person. But then again...

-- Rene

Excellent Windows utility to keep all passwords... http://www.counterpane.com/passsafe.html

I use password safe at work. Bruce "Applied Cryptography" Schneier came up with it. It works like all the others I guess and it uses a blowfish somehow!
But I am losing the Win95 machine I use at work (yea!) so I need one that will work on an iMac. Ideas anyone?

I agree with you that two-factor authentication is necessary for any real security. However, if you can't get that, insist at least that real password security is used, and that means using Secure Remote Password or SRP. This protocol is not patent encumbered and has an open source implementation; it provides a remote password login protocol immune to dictionary attacks, various forms of spoofing, and password equivalence problems.

I believe it is the *only* way to do networked passwords without nasty security flaws.

Also, passwords should always be subject to key stretching: see Schneier et. al., Secure Applications of Low-Entropy Keys.

SRP can be securely combined with two-factor authentication for best security. Good luck - and don't look to the banks for examples of how to do things right!
--

Actually, I'm sure that China has been thinking about the very same question, in reverse. They can't see the source to Windows, and for all they know, the NSA has put back doors into every Chinese-language version of Windows. (Those of you who think that the NSA doesn't do this kind of thing, please read this link).

That is, the Chinese know that they can't trust Windows. But the Chinese can't sneak hacks into Linux either, since they have to provide source code and it has to pass review by Linus and the other kernel hackers.

I'm sorry, their spin on this really sucks. All of the articles they've done have been thoroughly hysterical. The "piracy" issue has been argued to death here and elsewhere with mp3's. DVD video is much the same.

It's hardly a surprise that the scrambler was broken. One of the things the author of the wired article keeps misrepresenting is that XING somehow "forgot to encrypt" their decryption key. The CSS license requires implementations to obfuscate the algorithm (this is security through obscurity, after all). This is what XING failed to do, which made dissassembly much easier. It's quite possible to obtain the keys from other players--it just takes more work. In any case, the scrambler quite weak and would have been broken anyway. In fact, Bruce Schneier mentions in this cryptogram that the DVD cipher was broken "within months of [its] disclosure." What's new here is public documentation, unencumbered by NDA, not that news the the algorithm is fundamentally flawed.

As this new article briefly mentions, many of us are working on this just so we can watch the damn movies we've bought. Please see the livid project for a good collection of current open source work in this direction. The list archives have some intelligent discussion of the CSS crack, including "That was too easy!" hypotheses for the conspiracy theorists. :)

There's still a lot of work to be done. We can unscramble encrypted movies now, but there's still the byzantine navigation file format to figure out...which actually seems to be a much harder problem.

You just hit on the dirty little secret, the big flaw in all these supposedly secure copy protection schemes. At some point, the information is decrypted and available in plaintext on your machine so you can view it. The method for decrypting is on your machine too. There's no way around it, which is why Bruce Shneier says all copy-protection is doomed. (He also provides an alternative.)

The plaintext key just made it easier. If it hadn't been for that, brute-forcing the 40-bit keys was the next step--in fact they did that too, and got a bunch of keys. If the government lets them put strong encryption in everything, it will still be breakable--because at some point, no matter what the format, the content has to be translated into plaintext so you can see/hear/read it. Copy protection is just the wishful thinking of dinosaurs. Bruce Schneier says the same thing--and the future is probably something like his street performer protocol.

Coercion is a problem that is shared by most remote authentication techniques. It is impossible (almost!) to coerce a voter when he/she is required to show up at the poll booth as opposed to letting him/her vote remotely. Similarly, it is difficult to coerce someone to withdraw huge sums of money at a bank as opposed to the ease with which you can hold someone at gunpoint at an automated teller machine.

Now, don't argue that ATMs have security cameras and such. You wouldn't want those cameras installed in the privacy of your home (where you will be voting remotely from), would you? But note that I said "most" remote authentication techniques suffer from this problem, not all. I suppose authentication that is based on biometrics that vary depending on stress levels could work remotely. If it can be argued that a person's voice pattern differs noticeably when he/she is being threatened, and if such a threatening situation can be identified and recorded, then it would work. But using biometrics has risks too.

So, before jumping onto the online voting bandwagon, politicians and states need to consider the possibility of voter coercion adequately.

Sreeram.

Coercion is a problem that is shared by most remote authentication techniques. It is impossible (almost!) to coerce a voter when he/she is required to show up at the poll booth as opposed to letting him/her vote remotely. Similarly, it is difficult to coerce someone to withdraw huge sums of money at a bank as opposed to the ease with which you can hold someone at gunpoint at an automated teller machine.

Now, don't argue that ATMs have security cameras and such. You wouldn't want those cameras installed in the privacy of your home (where you will be voting remotely from), would you? But note that I said "most" remote authentication techniques suffer from this problem, not all. I suppose authentication that is based on biometrics that vary depending on stress levels could work remotely. If it can be argued that a person's voice pattern differs noticeably when he/she is being threatened, and if such a threatening situation can be identified and recorded, then it would work. But using biometrics has risks too.

So, before jumping onto the online voting bandwagon, politicians and states need to consider the possibility of voter coercion adequately.

Sreeram.

Bruce's main site.
Information on Skipjack
Information on impossible-differential cryptanalysis
Information on attacks unknown to the NSA
About the Windows NSAKEY flap
Probable NSA backdoors
Information on the Blowfish algo
Information on the Twofish algo
Speed comparison of known algos
Speed comparison of the AES candidates
Summary of attacks on various algos
Breaking crypto isn't the best way to beat security. Article 1 Article 2
Information on the Solitare algo
Information on the Yarrow algo
Importance of peer-reviewed crypto
Comments on propriatary encryption
Dismissal of cracking contests
You say you can't break it; well, who the hell are you?"
Twofish team's published papers
David Wagner's published papers
So you wanna become a cryptographer?
Information on side-channel attacks
Information on power-analysis attacks
More information on side-channel attacks
Article on Quantum computing
The problems with the public-key infrastructure
The problem with longer keys
l0phtcrack
Biometrics as keys?