Slashdot Mirror

Thank heavens I'm not with Demon any longer!

No good comes from pandering to folks who can't cope with "defammatory postings" at all. You should be allowed to flame away to your heart's content, IMNSHO - if you don't like being flamed, don't go out of your way to deserve it!

While you're at it, pay a visit to Stand.org.uk, and if you're UK-based send your MP a fax (preferably GPG-signed, too).

How do we go about getting the government out of the 'Net once and for all? Anyone got a small island to spare?
~Tim
--
.|` Clouds cross the black moonlight,

I just got wind of this. It seems a web service for reading Usenet will be highlighting keywords within the articles displayed through their site with links to advertisers who have purchased that service. The press release from the service itself is here. It is high time to start digitally signing everything with either PGP or GPG and licensing it only for unaltered redistribution.

This comment is licensed under the OpenContent License (OPL) Version 1.0, July 14, 1998. The relevant paragraphs concerning modification are as follows:

2. You may modify your copy or copies of the OpenContent or any portion of it, thus forming works based on the Content, and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified content to carry prominent notices stating that you changed it, the exact nature and content of the changes, and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the OC or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License, unless otherwise permitted under applicable Fair Use law.

How about GNU Privacy Guard? It's only got 3DES, CAST5, Blowfish, Twofish, and (modular) IDEA for symmetric encryption, but how many do you need? And it does public key encryption, too, and it's PGP compatible.

Because RSA was patented, replacement algorithms were developed and used instead. GNU Privacy Guard as well as PGP 5.0 and later use Diffie-Hellman, DSA and/or ElGamal instead of RSA.

Besides, PGP doesn't use public-key encryption for the whole message. It uses RSA (or equivalent) only to encrypt a random "session key", which is then applied to the whole message using a symmetric cipher. PGP 2.x uses the IDEA cipher, which is also patented, and which is patented more widely than in just the USA.

Because of all the patent nonsense, I urge everyone who still uses PGP 2.x to upgrade to PGP 5.0 or higher, or to switch to GnuPG.

If you don't use any encryption tools yet, I recommend GnuPG.

Because RSA was patented, replacement algorithms were developed and used instead. GNU Privacy Guard as well as PGP 5.0 and later use Diffie-Hellman, DSA and/or ElGamal instead of RSA.

Besides, PGP doesn't use public-key encryption for the whole message. It uses RSA (or equivalent) only to encrypt a random "session key", which is then applied to the whole message using a symmetric cipher. PGP 2.x uses the IDEA cipher, which is also patented, and which is patented more widely than in just the USA.

Because of all the patent nonsense, I urge everyone who still uses PGP 2.x to upgrade to PGP 5.0 or higher, or to switch to GnuPG.

If you don't use any encryption tools yet, I recommend GnuPG.

First, Slashdotters should realize that key management is basically a harder, and more important, problem than the cryptography itself. More "secure systems" get broken because of bad key management than because the ciphers get cracked. A PKI module that can do good key management, and can get a decent user interface so that users don't screw it up, is worth more in the long term than access to the RSA algorithm.

That said, it sure sounds like this PKI is focussed on the nasty X.509 style PKI that's basically a support infrastructure for old style centralized security systems. Verisign, DoD, and so on. I'll be glad when PGP/GPG style web of trust gets direct support.

Second, there was some gnashing of teeth here that SSL won't be in Mozilla. Justly so. But hey, there's really no problem ... just don't confuse "SSL" with "RSA Encryption and Signatures". They really aren't the same ... even though with Verisign buying out Thawte (maybe), it looks like the main signer of non-RSA certs may have been co-opted. (Sigh; I really want freedom of choice for public key algorithms, particularly now that TWINKLE makes RSA look weaker and weaker.)

With the new US regulations, folk could incorporate a version of the OpenSSL toolkit, sans RSA support. (And at about 12:01am on September 20, check the RSA support into CVS.)

The patent-free flavors of SSL use algorithms much like those used by GPG. There is a public key signature algorithm (DSS/DSA), a key exchange algorithm (Diffie-Hellman), and various flavors of DES (and Triple-DES) for bulk data encryption. OpenSSL includes support for Blowfish (way faster) and other patent-free ciphers, as well as TLS (a somewhat more secure SSL that mandates patent-free encryption options; it's the IETF standard). There's a recent IETF draft showing how to incorporate OpenPGP keys and ciphers (such as CAST128) into TLS.

Third, please don't get hung up on RSA. Everyone's security will be better when there's a choice of public key algorithms for use in authentication and encryption. OpenPGP (such as GPG), SSL, and TLS can all be used just fine without anyone having to get a wedgie about RSA (or deal with their nasty lawyers -- give me a normal lawyer any day).

In short: there's a lot of good news here, and if you want it, this is sufficient to move a good SSL into Mozilla right away. Whatever you do, don't let the licensing agreements that Sun, Netscape, and so on have with RSA force you to hold off till you can use that particular public key algorithm.

It has long been recognized that a cryptographic system is only as good as the quality of the reviews and attacks it survives. Open source crypto, really open source, is an excellent next step. GPG, Gnu Privacy Guard is part of the equation, but its initial development all took place outside the US because of crypto export restrictions. It looks like the genie is truly out of the bottle. It isn't the governments of the world that I fear when I protect my data. It isn't worth much to them. This will help protect it from the people who want a piece of my bank account.

GnuPG is a good replacement for PGP, developed outside the US, and unencumbered by patents.

I nominated Sawmill, and then stopped to think a little longer and realized how much GnuPG has improved lately. Especially for those interested in using open-source cryptography that's easy to set up and use.

I haven't followed the development very closely, but I think it's tough for even the mildest crypto-geeks to avoid noticing how so many folks have given up their old PGP keys and switched to GPG in the last year. This is a Good Thing, in my opinion. PGP was confusing. There seemed to be several concurrent versions being released at the same time, and you couldn't use some of them if you were outside the USA, couldn't use some of them if you were inside the USA, and some of them just didn't work. Finally, GnuPG stepped forward and started clearing the path, and now I'm using Mailcrypt with VM again! GnuPG kicks some serious ass!

The same is true if some people send "terminologically-enhanced email" around in quantity; some analyst is reasonably likely to notice it, and find some way of filtering it to some degree.

What would be more likely to cause consternation would be to have larger quantities of encrypted traffic. If, for instance, CVS and FTP archives started using GPG to encrypt all file transfer information in transit, this would cause more traffic where it may make it hard to tell if it's suspicious or not.

The entertaining option would be to use something like unto stenography...

This would involve taking "raw" messages, compressing and encrypting them using something like Blowfish. And then transforming them into masses of "dangerous terminology," compressing and maybe again encrypting that, and then transmitting this.

Thus, if we start with message "M," we do: % cat M | gzip - | blowfish -e -k "tata, NSA" > N We now have a file, N, that's hopefully small, and reasonably encrypted.

Now, pass it through a transformation where we turn it into a sequence of "dangerous words." The simplest option looks like:

• ASCII 0 maps to "NSA"
• ASCII 1 maps to "President"
• ASCII 3 maps to "Ortega"
• ASCII 4 maps to "Semtex"
• and so forth...

The obvious answer here is to pick the 256 best "dangerous words;" having only 64 would amount to a perverse equivalent to Base64 encoding; having 4000 words makes life more entertaining.

Another alternative would be not to pick words, but rather to pick phrases in some manner from some controversial essays/books, so that we're not merely getting random words, but rather sets of words that go together to appear to be in a vaguely meaningful sequence. Information Retrieval: Algorithms and Data Structures might have something to offer here. The idea is to pick from the ways that words were phrased in some text, so that the results at least vaguely look like something one might write.

You'll then get the original 500 byte message to expand out to something like 50K of "steganography." Fortunately, that 50K will be highly compressible English text. (Unless, of course, you picked some subversive book written in Russian as the "steganographic dictionary," in which case it'll be 50K of highly compressible Russian text.)

Compress again, encrypt into submission, and send that CVS patch over to the GnuCash archives...

The post office analogy is not really very accurate when you really look closely at the problem. The program that dumps the headers out for you (an MTA: Mail Transfer Agent, such as sendmail) already accesses and parses the whole message... it HAS to. Said same program can pipe a copy of the headers to a file thereby keeping the "contaminated" part of the process (the one that reads your mail) in the program and the "prying eyes" part of the process (the postmaster trying to fix her network) seperate. (this of course assumes morals, competency and a whole bunch of other stuff.....)

A much better analogy is the telegram (don't laugh!) operated by the old school telegraph operators that could tap out a message without reading it... or better yet, an illeterate operator! If all you know how to do is transpose '---' to 'O' and vice-versa then it doesn't matter if I'm sending a love letter or a creditcard number.

The biggest refrain in this though is that if you want privacy you must encrypt . GnuPG or PGPi or if you must have someone to sue if it breaks... PGP.

You need to be made aware of it if someone is going to read your mail.

In the physical world, this is correct. The effort to prevent someone from doing something they can do must be expended because there is no other way.

On the net, this is not correct because there is another way. Simply make the undesired activity impossible.

How? GnuPG or PGP.

sklein

Currently, it seems that SSL and RSA are tied together--you can't talk SSL unless you talk RSA. I would take SSL, gut out the algorithms (gut out RSA, and see if the symmetric algorithm is copyrighted), and replace the algorithms.

You can get a pseudo-free implementation of SSL out of an Australian team (the RSA patent is void there). They are called SSLeay. If you can't find one, you can find the SSL spec and write to it.

Then, go to GnuPG, a GPL'd version of PGP that only uses Diffie-Hellman to avoid the RSA patent. Snag the crypto algorithms out of GnuPG, glue them into the SSL server/client, and you have your own free variant SSL. You won't be able to talk to regular SSL (expecting RSA), but you can make your own free standard.

Spooks, you're on your own, and people, though we didn't create a tapping standard, someone else will implement something, and you won't know about it, you're on your own as well.

Well, unless there is a -close- to 100% foolproof way of authenticating a digital signature, we're just going to run into the same old hastles we're having now, where signatures are forged or copied, or transactions deliberately tampered with or fabricated.

A GPG digital signature is currently nearly 100% authenticatable.

A digital signature used to sign a document is both specific to that document and specific to that sender. If it was sent by the wrong person, the signature will be invalid. If the data changes between the time of signing and the time of verifying, the signature becomes invalid.

Try playing with GPG [http://www.gnupg.org] for yourself. It's an extremely neat app.

• Previous message: [Livid-dev] css
• Next message: [Livid-dev] Howto CSS
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

• Previous message: [Livid-dev] css
• Next message: [Livid-dev] Howto CSS
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

These days, any form of activism involves events intended to disseminate your message to as broad a base of listeners as is possible. Whether we like it or not, this generally includes specifically-crafted "media events" targetted toward being picked up by mass-market information disseminators, such as the news media.

Like it or not, at this point in time, the general populus still is either unaware or unconcerned about the steady erosions of their online (and offline) privacies and the increasing trend of Orwellian monitoring of even the most simple interchanges by Three Letter Agencies and others.

A one-day action certainly isn't going to overwhelm the NSA's filesystems, and I am certain no one actually believes that it would. But it does have merit nonetheless. In a sense, it enables "the little guy" to feel a sense of empowerment by making an (admittedly token) gesture, somewhat akin to making obscene gestures at surreptitious surveillance cameras. Obviously this doesn't directly change the underlying problem, except in the small measure that the individual is that much more likely to take a slightly larger "rebellious" action the next time. Don't forget that so-called resistive actions are frequently the precursors to more active (and effective) attempts to effect change of the undesirable situation. (Think, "baby steps.")

More importantly, these events bring the subject to the forefront of conversation. How many water cooler conversations might happen in offices thoughout the land, somewhat like this, the day after a similar event gets national coverage on the ubiquitous evening news?

• "Hey, you're into computers; did you see that thing on the news last night about how we can prevent the government from spying on us by jamming their computers?"
• "Well, actually, it's more like this...."

This also provides the opportunity to educate those with recently-awakened awareness of the issues to the importance of routine use of strong cryptography, since it is one of the most effective means of ensuring privacy against such Orwellian systems. Providing a link to GNU Privacy Guard (or even its less-free predecessor you mentioned) as well as an offer of assistance in setting it up, or acting as a mentor, will go a long way toward acheiving the goal of widespread use of cryptography being the norm, rather than the exception.

Oddly enough, your post here on Slashdot is indication that the "Jam Echelon Day" event succeeded, at least from my perspective. The story is covered here, and will generate discussion, hence awareness of the underlying issues is being increased, with opportunity for followup discussion. Obviously, being picked up both other major information dissemination channels will increase the effectiveness.

Emacsen's Mx-spook and its ilk may not directly affect the NSA, but indirect effects via increased public awareness are likely. An idealist would say that Echelon can be ended through the process of representative government. A realist may doubt that, and feel Echelon can be ended only by making it no longer cost-effective, due to the routine use of strong cryptography. Either way, the first step is to bring the issue to the eyes of the populus, as often as possible.

Right, and that's what GPG does, at least for the PGP equivalence. The 1.0 version came out a month or so ago.

Unfortunately, such a program is indeed a "workalike", but it is not compatible with existing systems. SSL with RSA/RC4 and PGP with RSA/IDEA have large installed bases, and unencumbered software cannot be compatible (until all the patents expire).

-Doug

RSADSI is a big company who depends heavily on the RSA algorithm for their revenue. You can bet that they have scores of lawyers who will try to intimidate anyone who tries to use the RSA algorithm after expiry.

They would probably not win any case that made it to court, but that is enough to scare many smaller companies into purchasing a license. Most of the larger companies already have licenses.

PGP (2.x at least) still uses the IDEA algorithm which is patented by Ascom Systec of Switzerland, so it is not totally free.

GnuPG does not use any patented algorithms and is a much better product anyway. There also exist plug-in RSA implementations which allow it be backwards compatible with PGP 2.x.

``People from outside (of your organization) can get at your software,'' said Anne Gardner, general manager of desktop systems for IBM. ``People from the outside can't get to your hardware.''

So there will probably not be a software flash-upgrade for this chip or anything like that: after all, if it can be software-upgraded, it can be cracked: witness the recent virus (forget its name) that wiped your BIOS chip if you had a Flash-BIOS capable motherboard and chip. So the only way to upgrade this thing will be to replace the chip -- and it'll likely be soldered onto the motherboard.

``We want this to become an industry standard,'' IBM's Gardner said. ``We want this on as many desktops as possible.''

Which means that if they get there wish, people who build <buzzword>E-commerce</buzzword> sites will start to rely on their customers having PC's with the chip installed.

The features of the security chip include key encryption, which encodes text messages,

What key length? Is it upgradeable? Considering the "can't get at it with software" statement above, probably not. So either it will have export-grade encryption (weak and insufficient, as most /. readers well know) or the U.S. government will restrict its export from the U.S. Furthermore, what happens when 128-bit keys are no longer secure enough and you need to move to 256-bit keys? Whoops, sorry, can't just get a software upgrade, you need a new computer. More lock-the-consumer-into-the-upgrade-cycle stuff here, even if it's not intentional (and it very well may be intentional).

and ``digital signatures,'' which act as unique ``watermarks'' that identify the sender of the document.

So everything made on a computer can be traced to that computer. Just like typewriters in the olden days (I seem to recall a few detective stories based on that fact). Great -- could be useful in some circumstances; law enforcement would love that, for example. This is where the privacy issues (which I'm not discussing here) come in. BUT this just identifies machines and is useless for identifying people. It will almost certainly, however, be misused for identifying people by what computer they use. What happens when (not if) Joe L. User sits down at one of the public-access PCs at his local library to surf the web, sees a cool "web shopping" site and registers as a customer? Assuming the site uses the chip ID the way IBM seems to be suggesting here, it will send Joe's computer (which is actually the library's) a digital certificate for Joe to make it "easier" for him to shop there since next time he won't even have to log in. Joe likes this, of course: it makes things easier for him. So Joe orders a few things and leaves. (Log out? What's dead trees got to do with things, anyway?) Now Carl Cracker comes along, uses the same computer at the library, and checks the Netscape history to see what he can find. He finds Joe's recent visit to the <buzzword>E-commerce</buzzword> site, checks it out, and sure enough, Joe didn't log out. So he visits the site and their software thinks he's Joe. He orders a bunch of stuff and charges it all to Joe.

Plausible scenario? You bet. Could <buzzword>E-commerce</buzzword> site designers be so clueless as to use a mechanism designed for computeridentification to identify people? No doubt about it.

The real solution to the <buzzword>E-commerce</buzzword> security issue is software. Ubiquitous, open-source, peer-reviewed software. Like, say, PGP (International version), or GNU Privacy Guard, or SSLeay. The hard part is that "ubiquitous" bit. You want real security? Here's how: Convince your boss to go open-source on the security aspects of the company's new <buzzword>E-commerce</buzzword> site. Read the Linux Advocacy mini-HOWTO first, then point out the advantages of using PGP or GnuPG or SSLeay rather than a proprietary solution. It'll be a hard sell, but stick with it. If everyone works at this, we'll eventually achieve the "ubiquitous" part.

The solution is out there, folks. Let's go implement it.
-----
New E-mail address! If I'm in your address book, please update it.

I believe you're referring to GPG - Gnu Privacy Guard. Get it here.

Kythe
(Remove "x"'s from

The open-source encryption software mentioned last week is called GPG (GNU Privacy Guard), and can be obtained from http://www.gnupg.org/. It was developed entirely outside the US, and therefore will be free from any restrictions bills such as SAFE place on crypto software.

The GNU project releases the GNU Privacy Guard. It is freely available, and runs on multiple platforms:

HPUX v9.x and v10.x with HPPA CPU,
IRIX v6.3 with MIPS R10000 CPU,
OSF1 V4.0 with Alpha CPU,
OS/2 version 2.
SCO UnixWare/7.1.0.
SunOS, Solaris on Sparc and x86,
USL Unixware v1.1.2,
Windows 95 and WNT with x86 CPUs.
(quoted from the above link)

To me, this executive order looks like a chance to score some political points now that they can no longer count on keeping a legal easily available encryption product out of the rest of the world.

I may be missing something obvious here, but why for crying out loud can't people use PGP (or even the new GPG)? They are available free worldwide without any export restrictions (see PGPi.com and gnupg.org) and are many times stronger than standard 128-bit stuff. Yes, I know a commercial license is required for PGP, but the mere fact that there is no export hassle should make it a no-brainer.

So long as the FBI is not granted a magic key by either consensus among crypto companies or by government regulation, privacy over the internet can and will exist.

As much as the government wishes otherwise, the crypto code is out there. GnuPG is free software, good luck to any organization to eliminate it.

As far as public policy goes, the one point that has to be driven home is that data sitting on someone's hard drive isn't going to hurt anybody. Logically, there is no latitude for any regulation in this area.

Is the Open Source community strong enough yet to overturn a bad standard in such way?

Look on the GnuPG web page. There are links to a number of mail clients with some level of support.

Personally, I prefer mutt.

It can interoperate with PGP5/6 users as long as they use DH/DSS keys and the associated default symmetric encryption (3DES or CAST128?).

See the GNUPG Homepage for more info.

Nugget94M asks:

You! Reading this article! Do you use ssh and pgp?
No!

If not, why not?

Because ssh is non-free, and pgp is patent encumbered. Why use that when there are excellent Free alternatives, such as:
SSLrsh
SSL-MZtelnet
gpg
S/WAN

----

Even better still... why bother with PGP with all its commercial connotations and export problems, when you can do much the same things with GnuPG without export restriction (no IDEA or RSA)?

(It doesn't support all the key formats of PGP but things generated in GnuPG can be imported into PGP with no problem...)

Otherwise I agree entirely. Everyone should use ssh, gnupg/pgp-according-to-taste; I also like the idea further down this thread concerning double-encrypting things so you can say you've decrypted it and it is an encrypted file. The alternative is to get the government to back off the 1-level encrypted file as a valid format anyway...

~Tim, GnuPG and PGP keys on website :)

~Tim
--

GNU Privacy Guard is a Free alternative to PGP. Take a look at their web site for more information.

--

GNU Privacy Guard

Not that faked results aren't a headache for the seti people, but anything that might be good they'll check against the original data and if it's good enough, check it with the telescope again. As far as signatures, I'm just starting to learn about encryption, and have nothing good to say about it, except go here and here!

• www.counterpane.com , Bruce Schneier's company, which hosts a lot of info on e.g. blowfish and the newer twofish cipher. (Twofish is an AES candidate)
• NIST is working towards the Advanced Encryption Standard (AES), which is to take over DES' role as the US-government recommended shared key block cipher.
• www.gnupg.org , the GNU Privacy Guard, a free alternative to PGP. (Currently rapidly approaching version 1.0)
• Lsh ( http://www.lysator.liu.se/~nisse/lsh/.) is a GPL-ed implementation of the SSH2 protocols.

You can use PGP to verify that the file is valid (you'll have to download the linux-2.2.0.tar.gz.sign signature file).

The odd thing is that they used PGP/RSA to generate their key. Why not use GnuPG instead?