When I plug my cell phone into it, it generates a one time pad and
distributes it over the line to the cell phone. Now the phone can talk to the computer using the pad
with perfect encryption and little processing overhead.
The OTP must be the same length as the data itself - which limits you to the amount of data that can be stored on the phone at a time. I guess you could extend this by keeping OTPs on CF, but still.
The thing is, once you get a cell phone intelligent enough where you want to transmit significant data traffic to and from it (I'm assuming you don't want to encrypt voice traffic - think of the size of your OTPs then!), it is probably also fast enough to use other encryption methods. I haven't benchmarked it, but I've heard that ssh with blowfish needs only marginally more CPU than the plain r* utilities. (That's one argument made against adding a "cleartext" crypt method to ssh for when you need the authentication but not the secrecy.) And I understand one of the criteria for the AES contest was that the alg had to be practical on a smart card.
Protect employees who are work for hire. We need standard labor laws that allow
the employee to revoke the license due to unfair treatment by the corporation, for instance termination
without compensation, or warning.
Nah, let them work this stuff into their contracts. The corp will want to have something in the contract like "licensed for free for the entire duration of copyright if you continue to work for us, or five years after termination of employment if you don't". Employee would negotiate for "corp pays xx% license fee to me whether or not I work for you, and if employment terminated, I have the right to revoke the license entirely". They'd find a middle ground.
No need to involve the government here. Presumably if the artists felt too screwed they would unionize.
Retroactive copyright might disenfranchise someone who just published a recent album though
If the purpose of copyright is to encourage creation of new works (my understanding of the matter, at least as originally framed), then who cares? The work has already been created. The act of limiting copyright to 14 years (or 14+14) and thus disappointing current copyright holders might deter future art, but only if future artists have an expectation that the term might be further shortened. I would consider this fear largely unjustified - it would be miracle enough for copyright term to be shortened once. (:
The demand to restrict the copyright to 14 years is pretty naive. It's a well known fact that the US
enlarges the duration of the copyright every 10 years or so just to make sure that Disney still has it's
copyright on Micky Mouse & co.
Perfect answer: immediately restrict copyright to 14 years, retroactive to all existing works, but with one lone exception: any existing work that includes the character of Mickey Mouse. Such works get their existing coypright protection until that runs out.
What's not to like? None of us really care about whether the Mouse is public domain or not, right? And it's not like Disney can complain, since Mickey is the obvious reason they keep getting extensions.
For the record, hard drive serial numbers are rather trivial to change.
Granted.
And an awful lot of equipment nowadays either allows dynamic MAC changing, or ways to spoof it.
AFAIK you generally can't change the boot-time MAC address, only the address(es) your card listens to when it runs.
(Of course, this is often good enough. I recently had an episode with a software package from PTC - they sent me a license generated from the wrong host ID. To verify that the software itself worked, I changed the MAC address of the machine. Sure enough, that fooled the license manager. This was on HP-UX.)
How exactly can you change a hard wired CPU serial number?
By not giving access to it. I believe the specific CPUID level that gets the PSN can be made privileged, so only the OS kernel can read it.
If you have an OS kernel that will conspire with your web browser to use your ID to track you and "destroy your privacy"... then you have bigger problems than a PIII serial number. Because that same OS could just as well use your original MAC address, or your hard disk serial number, and store it in some other location - we'll call this location a "registry" - and henceforth it doesn't matter what you change. For that matter, the same browser, in collusion with the OS (for the purpose of argument we'll say the browser is "part of the OS"), can just as well use a unique registration number which was printed on your OS install media and which you typed in during the installation.
Not that any company would ever produce such an OS or such a browser, of course, but work with me here. And if you had no way of independently verifying the workings of said browser - say, if it were closed-source - then worrying about the effects of a mere PSN would be rather absurd. Much like driving a car off a bridge into a lake and worrying whether your paint is sufficiently rust-proof.
Certainly, a one time pad is only a one time pad if it is *truly* random. Unless the machine generating
it has a true source of randomness---like a chunk-o'-radium or a pop-a-matic bubble---then they've just
pushed the encryption somewhere else, and gained no security.
An encryption scheme is only useful if a message can be decrypted by the receiving party. So if you make use of the chunk-o'-radium, how is another machine ever going to reconstruct the original message? Obviously, the remote machine has to have access to the same bits of randomness as the original machine. Which means you have to transmit the key.
In this case they generate a "key" from a "random mathematical equation". Essentially, the equation is the key, and what they call the "key" is actually just an intermediate data structure.
OK, say the "equation" in question is a polynomial function of order 10. You generate 10 16-bit random numbers to use as coefficients, and then use the polynomial function to come up with your "one-time pad", which you XOR with the message. Then you send me the 10 coefficients using some ASAD (all-singing-all-dancing) key exchange protocol like Diffie-Hellman or the Prescient ASAD Protocol. Now I construct that "one-time pad" using the order-10 equation, and decode the message.
Essentially the key strength is 160 bits - because the whole thing can be decoded if you know 10 16-bit numbers. The fact that it uses the 160-bit key to generate a stream of other bits makes no difference. Calling that intermediate stream a "one-time pad" is (-1, Just Plain Wrong).
I was under the impression that DeCSS got broken
because a licensee was careless about making a key accessible.
Depends on your sense of causality. That's the immediate reason - it gave the hackers a lever. But when they dug a little deeper, given the clue of the known key, they discovered that the underlying algorithm was quite weak, and subsequently they were able to crack all the other vendor keys (well, from what I recall, they got bored and quit after 200 keys or so).
To me, this means that if a trained cryptographer had looked at DeCSS, he could have cracked it quite easily without the Xing player key being available. IANAC, but I understand that a good cryptographer doesn't need access to the details of the algorithm, although those details make the job easier - but if it's a poor algo to start with, it can be easily cracked with no foreknowledge of the implementation.
Because customers assume that all manufacturers use the same system (which, for clarity, they should).
Are you one of those people who assume an HP 9000 system is 1.5 times as fast as an IBM RS/6000? Do you believe Red Hat Linux 7.2 is over twice as advanced as the (not yet released) Debian Linux 3.0? Does NFSv4 go twice as fast as NFSv2?
For that matter, which is better, a 6-cylinder gasoline engine or a 4-cylinder diesel engine? (Oh, don't talk about that silly "horsepower" number, it's obviously number of cylinders that counts.) Do you believe a 15-inch CRT is bigger than a 14-inch LCD? Which has better acceleration, an 800-cc touring bike or a 600-cc racing bike? Which Ethernet card is faster, a 3Com 905C or a Realtek 8139? How about PC266 DDR-SDRAM versus PC600 RDRAM?
In addition my next system will probably be a dual XP
Careful there - the XP is known to have issues with SMP. You might dismiss it as "AMD wants me to pay more for a chip that says MP on it" but running a dual-XP system is rolling the dice, same as overclocking. (And yes, there are people outside AMD who concur.) You might get a stable system, or you might not. I wouldn't chance it - next new machine it will be with MP chips (well, I don't upgrade often, maybe it will be Hammer chips).
No, AMD isn't
marketing their Athlon 2000+ as a 2000 MHz chip, but many computer stores do sell them that way (I have
seen this personally, so yes it does happen). You don't help your customers by lying to them.
OK then, whine at the computer stores. You said it yourself - AMD is not trying to tell you it's a 2000 MHz chip. They are trying to tell you it runs at least as fast as a 2000 MHz chip from another vendor.
According to SiSoft Sandra, its PR is 1875. But I would have been very pissed if I was being
sold a 1.9 GHz processor and found out that it only ran at 1.4 GHz.
Assume for a moment that you have no way to measure the actual GHz of a processor. Why would you care about the GHz number anyway? It's just a number. Do you have any idea how many factors go into the speed of a system besides the clock rate of the CPU pipeline? If you see a bunch of CPUs on a shelf, labeled "1400", "1500", "1900" - why does it matter if those are GHz or some other rating system determined by the manufacturer?
While you're at it, why don't you whine about Intel selling chips clocked at 600 MHz but "forgetting" to tell you that the on-chip L2 cache only runs at 300 MHz? Isn't that equally deceptive? Or, from another viewpoint, equally irrelevent?
They came out with a superior product, the
K7, for a very reasonable price at the time it was needed most: when Intel released their "serial
numbered" P3s. (Which is the primary reason why I don't respect Intel much anymore.)
Come on, the PIII serial number panic was largely FUD. Workstations have had software-accessible serial numbers on their motherboards for ages. Run 'uname -m' on an IBM RS/6000 - there's the CPU serial number. Even for CPUs that don't have IDs, most high-class machines come with built-in Ethernet, so you can treat the PROM's MAC address as a serial number for the motherboard.
What were your objections to the PIII serial number, again? Did you listen to the trade rag "journalists" who said your web browser would use it as a unique ID to track your movements across the web? Why, pray tell, couldn't your web browser just use your Ethernet address for this purpose? Or, failing that - what about your hard disk serial number? (You do have a hard disk, right? If so, it has a 32-bit serial number.)
If you run the same program on an Athlon and a Pentium they will both execute the same number of CISC instructions...they have to...otherwise one of them is not correct. So as long as the IPC number AMD is using is in terms of number of CISC instructions per cycle, they certainly do have a valid comparison and are not misguided as this guy says.
You are ignoring the fact that many CPU-intensive programs are optimised separately for Athlon vs P4. Vendors often use MMX, SSE, SSE2, and 3DNow! instructions to speed up critical algorithms. The P4 doesn't support 3DNow! and the Athlon doesn't support SSE2.
(OT: Even when a CPU does support a specific extension package, it may or may not provide a benefit. You'll see this if you dig into the internals of the Linux software RAID code, specifically RAID5. A RAID5 array stores not only your disk data but also one copy of "parity" information, which must be tediously calculated for all blocks of all disk writes. Ingo Molnar wrote several RAID 5 parity implementations for MMX etc, and at boot time, the code takes a couple seconds to automatically benchmark which is the fastest for the current CPU. It turns out that (if I remember correctly) the 3DNow! version isn't used on the K6-2 since, oddly enough, the code written for non-MMX Pentium is faster. The 3DNow! code is used on the Athlon, though.)
Re:What's holding back security
on
Can GnuPG Deliver?
·
· Score: 3, Insightful
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
And that's the Rub! When you sign a check, the
burden is on the bank and the vendor to verify that you
signed it...and all it says is that you signed it. That's
good enough for buying some very expensive things (cars,
houses, small countries)
One point: usually when you buy these expensive items,
there are independent ways used to verify your identity.
For buying cars and real estate (at least in Kansas), you
have to have the title notarized, which of course implies
that the notary, who is licensed by the state, is supposed
to check your ID.
This sort of thing doesn't really scale to e-commerce
easily. On the Internet, it is much more difficult to
verify someone's identity than it is in the Real World.
Thus, digital signatures are trying to solve a much harder
problem, in the common case, than ink signatures are.
Unfortunately the hard problems don't go away by throwing
technology and GUI interfaces at them. A command-line
switch for "trust this signature even though we have no way
of knowing if the owner is who he says he is" is just as
bad as a GUI check-box saying the same thing.
One might say that certificate authorities and KDCs are
the digital equivalent of a notary public. The web of trust
is the digital equivalent of a bank asking you for ID when
you open an account, and keeping your signature on file for
later comparison.
Yes, with a digital signature, you get proof of
identity, and along with it, non-repudiation, date stamping,
window of validity, revocation lists and a TON of 'useful'
stuff that you don't get with an ink signature.
Nonsense - most of these features can only be implemented
if there is a trusted third party, aka certificate authority
(CA). How is this different from a notary public? In the
Real World you can get every single signature notarized,
providing the same non-repudiation, date stamping, and so
forth. People don't usually do this because it represents a
lot of time and money.
And then there's the issue of whether you trust the
notary, or the CA. The notary is licensed by the State, the
CA isn't really licensed by anyone but gets credibility from
the number of people who recognise it (rather like the value
of paper currency). In both cases, how do you know for sure
that it can be trusted? You don't, you can only assume.
But if you CAN'T make it as EASY as an ink
signature, you're not going to get much
adoption.
As I've said, if you want the real benefits of PKI and
digital signatures, you either need an extensive web of
trust (hard to achieve) or a trusted third party (CA). This
isn't something you can just hand-wave away with better
interfaces. I really don't see how the ease-of-use problem
can be solved. It's easy to get people to use SSL
with https: web sites. It's hard to ensure that their
e-commerce transactions are actually secure against MITM
attacks and various sorts of spoofing. Without identity
verification (in both directions (sure, the web site
has a CA-issued certificate, but do you?), the great
benefits of PKI and digital signatures are largely a
myth.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
If anyone tried to verify that last message, slashcode
seems to uppercase all the HTML tags, so you have to
convert them back to lowercase (and remove the <BR>s
from the metadata). Oh well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
But the SSL/TLS uses the same ciphers and the
same technologies, only in a different
"wrapper".
Some of the same ciphers and some of the
same technologies. Notable differences:
key exchange: in PGP you exchange keys out-of-band,
usually by means of a keyserver, or mundane means such as
having your public key on a web page or Slashdot user
profile. With SSL you use a Diffie-Hellman exchange,
in-band (i.e. you negotiate a temporary pair of keys for
each transaction).
identity verification: in PGP it is the web of trust,
tied to the public keys themselves. You sign people's keys
which you have personally verified as genuine, and they in
turn sign other keys, until there is an entire network of
"trust relationships". With SSL each party can be certified
by a Certificate Authority, which is a similar process
except that the web of trust only goes one level deep:
everyone implicitly trusts the CA. This is much more like
the Kerberos model. Also, CAs cost money so individuals
don't usually use them. Thus, in most SSL transactions, the
web surfer can verify the web site, but not vice versa.
Also, the CA model relies on a separate certificate which is
not part of the key used for actual data transfer,
but is passed as in-band data.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Without some form of automated (and presumably
secure) key exchange, you can't really send automatically
encrypted email to someone anyway. You first have to get
their public key, which should also imply that they can
accept encrypted mail.
There is - it's called a keyserver, and there are lots
of them (which synchronise their keys periodically). You
can upload your key to one, and set your software to
automatically download a key when needed (to verify a
signature).
The keyserver itself it not secure - the security lies
in a so-called "web of trust". In essence, you can sign
someone else's key once you have verified its veracity by
face-to-face meeting or phone call (assuming you trust your
ability to recognise his/her voice on the phone). If enough
people sign each other's keys, you can trace a path of key
signatures (no pun intended) from you to an arbitrary key
you downloaded, and you know there is some assurance that
the key is genuine. Of course, this relies on everyone in
the chain being very careful only to sign keys they know for
sure they can trust. (That is not something you can build
into a software product - you can only document how the
process works, and the user has to take responsibility to
get it right.)
The advantage of the web of trust is that it is free and
decentralised. The alternative is to use certificate
authorities (CAs) who are centralised and well-known. This
is how SSL web sites usually work. The process is similar,
except that the web is very shallow in that everybody
implicitly trusts those few CAs. And CAs generally don't
sign your keys for free - it's a service they sell. As
such, it is quite practical for e-commerce, but in my
opinion not at all practical for individuals.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Re:What's holding back security
on
Can GnuPG Deliver?
·
· Score: 4, Insightful
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't mean to sound elitist (ok, maybe I do) but....
Easy to use is what its all about. People who say things like PGP
are easy to use for the average user are dreaming(and when I say average Im
talking about grandma here). What you want is something that integrates
seemlessly and is extremely esy to setup and configure.
The problem is that PKI is not easy. Key exchange is relatively
easy, sure - just have the application upload and download from a keyserver.
But what about key signing, and the web of trust? How do you make that part
easy? To maintain security, users must understand exactly how the
process works. Signing a key is a multi-step process and each step must be
done with regard to absolute security. I can't imagine how you could wrap
the web of trust into a slick GUI without completely negating the point.
And what about key revocation? Do you really think that when an office
worker moves from one department to another, and gets a new computer, that he
will think to copy his private key to a floppy and delete it from his original
computer? Or, failing that, will he issue a revocation certificate when he
realises that someone else now has access to the private key? For that matter,
will he encrypt the private key so that he has to type a passphrase every time
he accesses it?
These are not things you can easily abstract away. The user must
understand the whole process, or he will never get it right. In turn, not
getting it right would dilute the web of trust. And remember, the users we're
talking about are the same ones who fail to understand why you don't just
launch untrusted applications out of your e-mail, and why your password really
needs to be at least five characters long. Does anyone think the average
corporate user will have any grasp at all on how and why to use PKI in the way
it was designed (i.e. securely)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Re:Ah, yes, 1 of 3 reasons why I have a dual boot
on
New Clie Handhelds
·
· Score: 1
Palm Pilot
Quicken Topo Maps
What OS doesn't support the Palm Pilot? If you have a serial cradle, I think you can run palm-sync utilities on just about any OS - well, any OS that supports serial port hardware, which is pretty much any OS. If you have a USB cradle, you're probably stuck with Linux or some species of Windows.
As a Canadian, I can honestly say that our two worst exports are bar none: Celine Dion, and Brian Adams.
As an American I would have to agree, though I probably would have spelled it "Bryan". Comparing Enya to Celine is really off-the-wall. I don't understand what anyone thinks they have in common. (Not that I'm a big Enya fan, I prefer her sister Maíre Brennan.)
Can someone explain how the failure of a project to hit a stationary target (the Win95 API has not
changed though implimentation bugs may have) after such a lengthy period of time is anything but a proof
by counter example of the grandiose claims of how much better OSS is for just this sort of development?
There could be a lot of reasons. (I am not intimately familiar with the Wine project, so this is largely speculation.) One popular theory is that Wine is spread too thin. Its original target was 16-bit Windows. After Win95 came out, they started working on the Win32 API as well. When NT became popular with NT 3.51, there were two variants on the Win32 API, both of which were worked on. This situation has only gotten worse, as Wine attempts to be able to account for the quirks in all the various Win32 releases (you can select at runtime which flavor of Windows you want to "be"), which is a lot. Point being, the target is not stationary. The Wine developers did not want to concentrate on getting just Windows 95 right while ignoring other Win32 variants - if they had done that, they may well have painted themselves into a corner and made it nearly impossible to move on to the WinNT line when the time came. The two architectures are quite different and have some very different requirements. (Note that not even Microsoft has attempted to support both lines in one OS release - no version of NT runs every Win95 app.)
Add to that the complexity of the Win32 API. Not only do you have several variations on it, but it's a really complex API to begin with. In Unix, you sometimes have system calls that take three or four parameters, one of which is a structure pointer. In Win32, it is not uncommon for a call to take eight parameters, six of which are structure pointers. I'm not a Windows developer, but from people who have really studied it... well, I've heard it called functional, but never elegant.
Then there are the design decisions. Wine runs as a regular user-space process under the X Window System. Thus they are having to map the fairly low-level Win32 API onto a higher-level X11 API. Efficiently, mind. One implementation decision was to build an entire debugger (I think it is a sort of Win16/Win32/Wine-aware variant of gdb) which is an application unto itself. I imagine the debugger paid for itself in development time, but still. Another decision was to offer two separate window management cases - you can either use your native X11 window manager to manage Wine windows, or you can use a built-in Wine window manager. Which they had to write - yet another application unto itself.
Which brings us to the "paradigm emulations", shall we say. Back to window management - it works quite differently in X11 and in Windows (in X, the window manager handles your window decorations like borders - in Windows, the application does.) The threading model in Win32 is completely different from, and much more complex than, the one in POSIX. It has to be emulated on a much higher level than just translating one function name to another. (I think they ended up rolling their own threads library based on the Linux clone() primitive.) Process creation - also completely different, a spawn model and a fork model. The Windows IPC mechanisms and memory architecture - same story. (Note: architectures, plural. This gets back to the Win9x vs WinNT thing - in Win9x the virtual memory system is much simpler and stupider than in NT/Unix, and some applications rely on this fact, so that has to be emulated as well.) And speaking of IPC, in Windows this largely revolves around an object model, COM/DCOM, which has no real analog in Unix (no, CORBA doesn't count, it's not a standard feature), so the whole OLE/COM/DCOM architecture had to be built up from scratch.
It all comes down to - they're not just implementing an API, they're implementing an OS. Multiple semi-compatible OSes, actually. I can only be surprised that they've done as well as they have.
Oh yeah, I forgot. The above isn't quite right: too many hyphens, too grammatically correct. JonKatz seems to prefer spaces in this post-liberal-arts-education world. So please s/-//g.
Another JonKatz Post-something article! Just what I needed in the morning!
What I think Slashdot needs is a pre- writer. JonKatz can write about post-this or post-that, and someone else could post [no pun intended] equivalent drivel about living in a pre-something world. Just think of the paradigm shifts we haven't gone through yet...
Slashdot Mirror
The OTP must be the same length as the data itself - which limits you to the amount of data that can be stored on the phone at a time. I guess you could extend this by keeping OTPs on CF, but still.
The thing is, once you get a cell phone intelligent enough where you want to transmit significant data traffic to and from it (I'm assuming you don't want to encrypt voice traffic - think of the size of your OTPs then!), it is probably also fast enough to use other encryption methods. I haven't benchmarked it, but I've heard that ssh with blowfish needs only marginally more CPU than the plain r* utilities. (That's one argument made against adding a "cleartext" crypt method to ssh for when you need the authentication but not the secrecy.) And I understand one of the criteria for the AES contest was that the alg had to be practical on a smart card.
Nah, let them work this stuff into their contracts. The corp will want to have something in the contract like "licensed for free for the entire duration of copyright if you continue to work for us, or five years after termination of employment if you don't". Employee would negotiate for "corp pays xx% license fee to me whether or not I work for you, and if employment terminated, I have the right to revoke the license entirely". They'd find a middle ground.
No need to involve the government here. Presumably if the artists felt too screwed they would unionize.
If the purpose of copyright is to encourage creation of new works (my understanding of the matter, at least as originally framed), then who cares? The work has already been created. The act of limiting copyright to 14 years (or 14+14) and thus disappointing current copyright holders might deter future art, but only if future artists have an expectation that the term might be further shortened. I would consider this fear largely unjustified - it would be miracle enough for copyright term to be shortened once. (:
Perfect answer: immediately restrict copyright to 14 years, retroactive to all existing works, but with one lone exception: any existing work that includes the character of Mickey Mouse. Such works get their existing coypright protection until that runs out.
What's not to like? None of us really care about whether the Mouse is public domain or not, right? And it's not like Disney can complain, since Mickey is the obvious reason they keep getting extensions.
Whatever, I just think it would be pretty funny.
Granted.
AFAIK you generally can't change the boot-time MAC address, only the address(es) your card listens to when it runs.
(Of course, this is often good enough. I recently had an episode with a software package from PTC - they sent me a license generated from the wrong host ID. To verify that the software itself worked, I changed the MAC address of the machine. Sure enough, that fooled the license manager. This was on HP-UX.)
By not giving access to it. I believe the specific CPUID level that gets the PSN can be made privileged, so only the OS kernel can read it.
If you have an OS kernel that will conspire with your web browser to use your ID to track you and "destroy your privacy" ... then you have bigger problems than a PIII serial number. Because that same OS could just as well use your original MAC address, or your hard disk serial number, and store it in some other location - we'll call this location a "registry" - and henceforth it doesn't matter what you change. For that matter, the same browser, in collusion with the OS (for the purpose of argument we'll say the browser is "part of the OS"), can just as well use a unique registration number which was printed on your OS install media and which you typed in during the installation.
Not that any company would ever produce such an OS or such a browser, of course, but work with me here. And if you had no way of independently verifying the workings of said browser - say, if it were closed-source - then worrying about the effects of a mere PSN would be rather absurd. Much like driving a car off a bridge into a lake and worrying whether your paint is sufficiently rust-proof.
An encryption scheme is only useful if a message can be decrypted by the receiving party. So if you make use of the chunk-o'-radium, how is another machine ever going to reconstruct the original message? Obviously, the remote machine has to have access to the same bits of randomness as the original machine. Which means you have to transmit the key.
In this case they generate a "key" from a "random mathematical equation". Essentially, the equation is the key, and what they call the "key" is actually just an intermediate data structure.
OK, say the "equation" in question is a polynomial function of order 10. You generate 10 16-bit random numbers to use as coefficients, and then use the polynomial function to come up with your "one-time pad", which you XOR with the message. Then you send me the 10 coefficients using some ASAD (all-singing-all-dancing) key exchange protocol like Diffie-Hellman or the Prescient ASAD Protocol. Now I construct that "one-time pad" using the order-10 equation, and decode the message.
Essentially the key strength is 160 bits - because the whole thing can be decoded if you know 10 16-bit numbers. The fact that it uses the 160-bit key to generate a stream of other bits makes no difference. Calling that intermediate stream a "one-time pad" is (-1, Just Plain Wrong).
You haven't studied quantum mechanics, have you?
Uhhh, obviously I meant "if a trained cryptographer had looked at CSS"...
Depends on your sense of causality. That's the immediate reason - it gave the hackers a lever. But when they dug a little deeper, given the clue of the known key, they discovered that the underlying algorithm was quite weak, and subsequently they were able to crack all the other vendor keys (well, from what I recall, they got bored and quit after 200 keys or so).
To me, this means that if a trained cryptographer had looked at DeCSS, he could have cracked it quite easily without the Xing player key being available. IANAC, but I understand that a good cryptographer doesn't need access to the details of the algorithm, although those details make the job easier - but if it's a poor algo to start with, it can be easily cracked with no foreknowledge of the implementation.
Are you one of those people who assume an HP 9000 system is 1.5 times as fast as an IBM RS/6000? Do you believe Red Hat Linux 7.2 is over twice as advanced as the (not yet released) Debian Linux 3.0? Does NFSv4 go twice as fast as NFSv2?
For that matter, which is better, a 6-cylinder gasoline engine or a 4-cylinder diesel engine? (Oh, don't talk about that silly "horsepower" number, it's obviously number of cylinders that counts.) Do you believe a 15-inch CRT is bigger than a 14-inch LCD? Which has better acceleration, an 800-cc touring bike or a 600-cc racing bike? Which Ethernet card is faster, a 3Com 905C or a Realtek 8139? How about PC266 DDR-SDRAM versus PC600 RDRAM?
Careful there - the XP is known to have issues with SMP. You might dismiss it as "AMD wants me to pay more for a chip that says MP on it" but running a dual-XP system is rolling the dice, same as overclocking. (And yes, there are people outside AMD who concur.) You might get a stable system, or you might not. I wouldn't chance it - next new machine it will be with MP chips (well, I don't upgrade often, maybe it will be Hammer chips).
OK then, whine at the computer stores. You said it yourself - AMD is not trying to tell you it's a 2000 MHz chip. They are trying to tell you it runs at least as fast as a 2000 MHz chip from another vendor.
Assume for a moment that you have no way to measure the actual GHz of a processor. Why would you care about the GHz number anyway? It's just a number. Do you have any idea how many factors go into the speed of a system besides the clock rate of the CPU pipeline? If you see a bunch of CPUs on a shelf, labeled "1400", "1500", "1900" - why does it matter if those are GHz or some other rating system determined by the manufacturer?
While you're at it, why don't you whine about Intel selling chips clocked at 600 MHz but "forgetting" to tell you that the on-chip L2 cache only runs at 300 MHz? Isn't that equally deceptive? Or, from another viewpoint, equally irrelevent?
Come on, the PIII serial number panic was largely FUD. Workstations have had software-accessible serial numbers on their motherboards for ages. Run 'uname -m' on an IBM RS/6000 - there's the CPU serial number. Even for CPUs that don't have IDs, most high-class machines come with built-in Ethernet, so you can treat the PROM's MAC address as a serial number for the motherboard.
What were your objections to the PIII serial number, again? Did you listen to the trade rag "journalists" who said your web browser would use it as a unique ID to track your movements across the web? Why, pray tell, couldn't your web browser just use your Ethernet address for this purpose? Or, failing that - what about your hard disk serial number? (You do have a hard disk, right? If so, it has a 32-bit serial number.)
You are ignoring the fact that many CPU-intensive programs are optimised separately for Athlon vs P4. Vendors often use MMX, SSE, SSE2, and 3DNow! instructions to speed up critical algorithms. The P4 doesn't support 3DNow! and the Athlon doesn't support SSE2.
(OT: Even when a CPU does support a specific extension package, it may or may not provide a benefit. You'll see this if you dig into the internals of the Linux software RAID code, specifically RAID5. A RAID5 array stores not only your disk data but also one copy of "parity" information, which must be tediously calculated for all blocks of all disk writes. Ingo Molnar wrote several RAID 5 parity implementations for MMX etc, and at boot time, the code takes a couple seconds to automatically benchmark which is the fastest for the current CPU. It turns out that (if I remember correctly) the 3DNow! version isn't used on the K6-2 since, oddly enough, the code written for non-MMX Pentium is faster. The 3DNow! code is used on the Athlon, though.)
Hash: SHA1
One point: usually when you buy these expensive items, there are independent ways used to verify your identity. For buying cars and real estate (at least in Kansas), you have to have the title notarized, which of course implies that the notary, who is licensed by the state, is supposed to check your ID.
This sort of thing doesn't really scale to e-commerce easily. On the Internet, it is much more difficult to verify someone's identity than it is in the Real World. Thus, digital signatures are trying to solve a much harder problem, in the common case, than ink signatures are. Unfortunately the hard problems don't go away by throwing technology and GUI interfaces at them. A command-line switch for "trust this signature even though we have no way of knowing if the owner is who he says he is" is just as bad as a GUI check-box saying the same thing.
One might say that certificate authorities and KDCs are the digital equivalent of a notary public. The web of trust is the digital equivalent of a bank asking you for ID when you open an account, and keeping your signature on file for later comparison.
Nonsense - most of these features can only be implemented if there is a trusted third party, aka certificate authority (CA). How is this different from a notary public? In the Real World you can get every single signature notarized, providing the same non-repudiation, date stamping, and so forth. People don't usually do this because it represents a lot of time and money.
And then there's the issue of whether you trust the notary, or the CA. The notary is licensed by the State, the CA isn't really licensed by anyone but gets credibility from the number of people who recognise it (rather like the value of paper currency). In both cases, how do you know for sure that it can be trusted? You don't, you can only assume.
As I've said, if you want the real benefits of PKI and digital signatures, you either need an extensive web of trust (hard to achieve) or a trusted third party (CA). This isn't something you can just hand-wave away with better interfaces. I really don't see how the ease-of-use problem can be solved. It's easy to get people to use SSL with https: web sites. It's hard to ensure that their e-commerce transactions are actually secure against MITM attacks and various sorts of spoofing. Without identity verification (in both directions (sure, the web site has a CA-issued certificate, but do you?), the great benefits of PKI and digital signatures are largely a myth.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8o0tbXk7sIRPQRh0RAuBYAJ9DVmv2jxgv2jC6EeihX
B/PfLLMNGphv+UzaKcUZmaE=
=8uVU
-----END PGP SIGNATURE-----
Hash: SHA1
If anyone tried to verify that last message, slashcode seems to uppercase all the HTML tags, so you have to convert them back to lowercase (and remove the <BR>s from the metadata). Oh well.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oyohXk7sIRPQRh0RAgcXAKDdKgOARqKYF67IhA42W
jRRCrWVGqeOQx7j0jJntb1U=
=aLHt
-----END PGP SIGNATURE-----
Hash: SHA1
Some of the same ciphers and some of the same technologies. Notable differences:
- key exchange: in PGP you exchange keys out-of-band,
usually by means of a keyserver, or mundane means such as
having your public key on a web page or Slashdot user
profile. With SSL you use a Diffie-Hellman exchange,
in-band (i.e. you negotiate a temporary pair of keys for
each transaction).
- identity verification: in PGP it is the web of trust,
tied to the public keys themselves. You sign people's keys
which you have personally verified as genuine, and they in
turn sign other keys, until there is an entire network of
"trust relationships". With SSL each party can be certified
by a Certificate Authority, which is a similar process
except that the web of trust only goes one level deep:
everyone implicitly trusts the CA. This is much more like
the Kerberos model. Also, CAs cost money so individuals
don't usually use them. Thus, in most SSL transactions, the
web surfer can verify the web site, but not vice versa.
Also, the CA model relies on a separate certificate which is
not part of the key used for actual data transfer,
but is passed as in-band data.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oyStXk7sIRPQRh0RAj7xAJ9mjZCbQmFz+aj5PWY1Z
v2d4FQ9bqUhJRXFCcR8NbNA=
=8qbj
-----END PGP SIGNATURE-----
Hash: SHA1
There is - it's called a keyserver, and there are lots of them (which synchronise their keys periodically). You can upload your key to one, and set your software to automatically download a key when needed (to verify a signature).
The keyserver itself it not secure - the security lies in a so-called "web of trust". In essence, you can sign someone else's key once you have verified its veracity by face-to-face meeting or phone call (assuming you trust your ability to recognise his/her voice on the phone). If enough people sign each other's keys, you can trace a path of key signatures (no pun intended) from you to an arbitrary key you downloaded, and you know there is some assurance that the key is genuine. Of course, this relies on everyone in the chain being very careful only to sign keys they know for sure they can trust. (That is not something you can build into a software product - you can only document how the process works, and the user has to take responsibility to get it right.)
The advantage of the web of trust is that it is free and decentralised. The alternative is to use certificate authorities (CAs) who are centralised and well-known. This is how SSL web sites usually work. The process is similar, except that the web is very shallow in that everybody implicitly trusts those few CAs. And CAs generally don't sign your keys for free - it's a service they sell. As such, it is quite practical for e-commerce, but in my opinion not at all practical for individuals.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oyFcXk7sIRPQRh0RAmvRAJkBb304Qw9HbF/obB+ny
lZI4CNAroR8RxG3ZmGkFf30=
=32AC
-----END PGP SIGNATURE-----
Hash: SHA1
I don't mean to sound elitist (ok, maybe I do) but....
The problem is that PKI is not easy. Key exchange is relatively easy, sure - just have the application upload and download from a keyserver. But what about key signing, and the web of trust? How do you make that part easy? To maintain security, users must understand exactly how the process works. Signing a key is a multi-step process and each step must be done with regard to absolute security. I can't imagine how you could wrap the web of trust into a slick GUI without completely negating the point.
And what about key revocation? Do you really think that when an office worker moves from one department to another, and gets a new computer, that he will think to copy his private key to a floppy and delete it from his original computer? Or, failing that, will he issue a revocation certificate when he realises that someone else now has access to the private key? For that matter, will he encrypt the private key so that he has to type a passphrase every time he accesses it?
These are not things you can easily abstract away. The user must understand the whole process, or he will never get it right. In turn, not getting it right would dilute the web of trust. And remember, the users we're talking about are the same ones who fail to understand why you don't just launch untrusted applications out of your e-mail, and why your password really needs to be at least five characters long. Does anyone think the average corporate user will have any grasp at all on how and why to use PKI in the way it was designed (i.e. securely)?
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oxyBXk7sIRPQRh0RAm/RAKC1wm0wzc/WH+vyRrC5d
WjQJECmQ2hIL5axm0jo0lOU=
=CuR1
-----END PGP SIGNATURE-----
What OS doesn't support the Palm Pilot? If you have a serial cradle, I think you can run palm-sync utilities on just about any OS - well, any OS that supports serial port hardware, which is pretty much any OS. If you have a USB cradle, you're probably stuck with Linux or some species of Windows.
As an American I would have to agree, though I probably would have spelled it "Bryan". Comparing Enya to Celine is really off-the-wall. I don't understand what anyone thinks they have in common. (Not that I'm a big Enya fan, I prefer her sister Maíre Brennan.)
Are you kidding? Linux has way more fanboys per user capita than Windows. They just don't all work for one company.
There could be a lot of reasons. (I am not intimately familiar with the Wine project, so this is largely speculation.) One popular theory is that Wine is spread too thin. Its original target was 16-bit Windows. After Win95 came out, they started working on the Win32 API as well. When NT became popular with NT 3.51, there were two variants on the Win32 API, both of which were worked on. This situation has only gotten worse, as Wine attempts to be able to account for the quirks in all the various Win32 releases (you can select at runtime which flavor of Windows you want to "be"), which is a lot. Point being, the target is not stationary. The Wine developers did not want to concentrate on getting just Windows 95 right while ignoring other Win32 variants - if they had done that, they may well have painted themselves into a corner and made it nearly impossible to move on to the WinNT line when the time came. The two architectures are quite different and have some very different requirements. (Note that not even Microsoft has attempted to support both lines in one OS release - no version of NT runs every Win95 app.)
Add to that the complexity of the Win32 API. Not only do you have several variations on it, but it's a really complex API to begin with. In Unix, you sometimes have system calls that take three or four parameters, one of which is a structure pointer. In Win32, it is not uncommon for a call to take eight parameters, six of which are structure pointers. I'm not a Windows developer, but from people who have really studied it ... well, I've heard it called functional, but never elegant.
Then there are the design decisions. Wine runs as a regular user-space process under the X Window System. Thus they are having to map the fairly low-level Win32 API onto a higher-level X11 API. Efficiently, mind. One implementation decision was to build an entire debugger (I think it is a sort of Win16/Win32/Wine-aware variant of gdb) which is an application unto itself. I imagine the debugger paid for itself in development time, but still. Another decision was to offer two separate window management cases - you can either use your native X11 window manager to manage Wine windows, or you can use a built-in Wine window manager. Which they had to write - yet another application unto itself.
Which brings us to the "paradigm emulations", shall we say. Back to window management - it works quite differently in X11 and in Windows (in X, the window manager handles your window decorations like borders - in Windows, the application does.) The threading model in Win32 is completely different from, and much more complex than, the one in POSIX. It has to be emulated on a much higher level than just translating one function name to another. (I think they ended up rolling their own threads library based on the Linux clone() primitive.) Process creation - also completely different, a spawn model and a fork model. The Windows IPC mechanisms and memory architecture - same story. (Note: architectures, plural. This gets back to the Win9x vs WinNT thing - in Win9x the virtual memory system is much simpler and stupider than in NT/Unix, and some applications rely on this fact, so that has to be emulated as well.) And speaking of IPC, in Windows this largely revolves around an object model, COM/DCOM, which has no real analog in Unix (no, CORBA doesn't count, it's not a standard feature), so the whole OLE/COM/DCOM architecture had to be built up from scratch.
It all comes down to - they're not just implementing an API, they're implementing an OS. Multiple semi-compatible OSes, actually. I can only be surprised that they've done as well as they have.
Oh yeah, I forgot. The above isn't quite right: too many hyphens, too grammatically correct. JonKatz seems to prefer spaces in this post-liberal-arts-education world. So please s/-//g.
What I think Slashdot needs is a pre- writer. JonKatz can write about post-this or post-that, and someone else could post [no pun intended] equivalent drivel about living in a pre-something world. Just think of the paradigm shifts we haven't gone through yet...