Slashdot Mirror

There is some uncertainty as to the future of PGP. Network Associates (pgp.com) appears to be trying to bale out of encryption, post 9/11... thus GnuPG is the way to go.

Incidentally, I use GPG to store a growing list of passwords. It is very useful to maintain a central list, for when I forget my passwords. However, this is not the way for large organisations to go (read: kludgey).

RFC2440, which defines the OpenPGP standard, already reserves 3 AES keys sizes (128, 192, 256-bit).

Gnupg already supports AES in all 3 block sizes and so does 'official' PGP v7.0x.

PGP since v7.x hasn't been open source, so you won't find any details at www.pgpi.org. The best way to add AES support to previous 'open source' versions is to use the CKT builds by Imad. These are still based upon the v6.58 code base but contains dozens of fixes and improvements.

Your trust model idea sounds a lot like PGP... And it works just fine, IMO (I use it on a regular basis for professional contacts); so this should work as well. Of course, you'd still need some central database, where everyone would start from...

Well, I'd hardly think that 250 people would represent those who work to actually MAKE the products. Plus, the PGP "Business Unit" of PGP made way more than a single encryption product, some of which did not have "PGP" in the name. Regardless, as with a company of its size, many of those people are also going to be "infrastructure" ... HR people, office staff, management, etc. Sure, you can move the programmers to another part of the company (as they plan to do with the ones for the remaining products in this case). But when you eliminate the company altogether, that doesn't leave any place to put the rest of the people that run it's day-to-day operations. But 250-300 working on the product hands-on? The actual number of "little minions" working on the stuff is probably quite a bit smaller.

Some other comments from what I've read here...

From actually READING the announcement http://www.pgp.com/other/jump/customer-faq.asp, and listening to the NAI Earnings Conference Call from the same day (thanks Yahoo!), "NAI PGP" isn't being totally scrapped! They've just decided not to keep PGP as a separate business entity, as they see doing so as hindering their potential growth as a company. In doing so, they've evaluated their product lines and have decided to stick with what they think they can SELL, for example, their E-Business Server product. They spell out in their announcement what they feel they need to do to meet that goal. Some products are to be sold off (if possible), some moved, and some having parts extracted, possibly being merged into other similar products they already have in the other BUs. Once that's all done... of course they won't need ALL of their current PGP staff. And well, sounds like 250 is their estimate of what the surplus.

It's nice to be ulturistic and think "wouldn't it be nice if they just did it for the 'good of all' and gave the products away for free?" But well, that's not what software companies do. They exist to SELL the software they make. They need to make money to survive, as does any corporation, and that's about the only bottom line that their shareholders will care about.

I've read a lot of posts from a lot of people wanting a nice free version that they can use freely cuz "well, you could easily just write it yourself... why pay for it"? Well, I don't see anyone volunteering their time and efforts to obtain the PGP SDK and grace us all with their programming prowess and their 'for the good of all humanity' ideals. If anyone does... I have my own 'wish list' of features I wouldn't mind being added to PGPmail and PGPdisk. I can pass them along if you wish. Anything to help. :-)

But, unfortunately for us end-users... NAI seems to think (as indicated by the products that will remain, albeit moved to other business units) that $$$ for their PGP survival is going to come more from big business... not from us. I guess that judging from many of the comments here, they seem to be right, at least on the last bit: "not from us".

I have two holes to punch into Acer's new notebook:

(1) Their illustration of a Pentium III-M processor is good for a laugh. Check out the lower-right corner of the second page of the brochure, and tell me that isn't an FCPGA Coppermine Pentium III sitting on top of a circuit board.

(2) More than likely, they've implemented the hard drive protection using an IBM Travelstar hard drive, which has a password-protection option (although this is very rarely used in the real world). Why am I poopooing this? Keep reading.

Section 11.8 of the Travelstar 48GH Specifications (page 87, PDF page 101) details IBM's security system. I would imagine this can be circumvented in one of two ways, the first being in the hard drive itself and the second being part of the notebook's security implementation.

First, there's a Master Password in addition to the normal User Password. If you don't know what the Master Password is, and don't know that only you know both passwords, anyone with access to the Master Password (quite likely any high-level Acer technician) can send a Device Unlock command to the drive along with the Master Password and voilà, the oyster opens to reveal the pearls inside. (No, you can't read the passwords out of the drive's EEPROM; it's stored in a non-externally-addressable area of the disk. Even if you know and control both passwords, though, I'd imagine there are undocumented commands to reset the password or unlock the drive regardless of the password. If you're thinking that IBM would need to be able to unlock drives to refurbish/repair them, they wouldn't, because there's a command which will write zeroes to every externally-addressable sector on the drive then unlock the drive and erase the password. No hard drive maker that I know of guarantees the integrity of the data on any hard drive that's sent to them.)

Second, I'd be very surprised if they had gone any further than storing the Travelstar's access password in CMOS or an EEPROM part, and sending it to the drive if the fingerprint matches what's stored there as well. (They couldn't store a one-way hash of the drive password, because any obfuscation would have to be reversable to be able to feed the password to the drive.) Therefore, anyone with an SMD rework station and an EEPROM reader could probably extract the password from the CMOS/EEPROM.

In summary, I wouldn't trust state secrets to this. I would recommend PGP Corporate Desktop instead as the closest thing a mortal can get to decent data security. (An interesting aside: You know how the government erases drives holding classified information before they're resold? They don't. The drives are physically destroyed. For good reason.)

"Michael L. Love says the "open-signing" form of encryption that's available with encryption programs such as PGP and GnuPG would keep would-be terrorists from hijacking other people's email to send their messages. Under open signing, the text of the email is open for all to read, but the identify of the sender is authenticated."

There is also some discussion of .NET, and Love says that PGP keyservers could provide an authentication infrastructure to compete with Microsoft in the net services arena. Be sure to see the related Slashdot thread about Microsoft's new authentication proposals.

And this will be safe!!

Why?

You've probably heard about PGP(pretty good privacy) and what the basics are: public and private key system....

so everyone will get one pair of those...

This will make it easier to pay on the internet and to make sure you are who who you tell you are ("everyone will get/be a personal number")..

And a multi-to-one card...: why should it be difficult to make that...??? Proton chips can store a lot.... and like we have frequency bands, we can have datasections for every bank/institution....

**fatnotic**

That was Phil Zimmermann, author of PGP, who quit working for Network Associates.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

There are (at least) three extremely good packages available for performing seamless, convenient, on-the-fly encryption of your hard drives. I can't believe they are stupid enough to not only neglect to use one, but also to propose an unreliable physical 'bomb' to destroy the drive! C'mon!

Scramdisk, E4M, and PGPDisk all create 'virtual' mounted disks on your system, which act just as any normal disk. When you boot up, you run the software, 'mount' the virtual disk (it's a large file on your hard drive), and voila. You have a fully high-strength encrypted volume to use just like you would any other disk. Very, very easy. You can even install your apps there if you want.

The data itself is encrypted on the fly, and stored on fully encrypted form on the disk. Therefore, if the volume was unmounted (say, by rebooting), the data is totally unaccessible. If you just rely on your computer to kick into password-protected 'sleep' mode, or use a password-protected screen saver, you're pretty well covered - the only way you can really get by these things is by rebooting - which unmounts the encrypted disk. Abracadabra.

Everyone in business who travels with a laptop should be using software like this. Scramdisk is, in fact, free (Win98/ME, $20 for NT/2k), and open source! I believe E4M is free, as well (not sure about the source).

Take a look:

Scramdisk
E4M
PGP

Why this stuff isn't more universally used by laptop-travelers, especially government-secret or business-secret toters, is absolutely baffling. Hell, it's even easier to use than public-key encryption.

HebGb

...just like that other relic from the 1980's, Ronald Reagan. I suppose we should be grateful: it was the threat of the V-chip that brought the Cypherpunks into existance and was indirectly responsible for the creation of PGP and the EFF. A little dose of fascism can do wonders for freedom.

Unless I'm sending something absolutely unimportant, like "meet me at the movies at 8", I almost always use encryption when talking about anything personal, like "meet me in front of the bank at 8 with car running". It's not really that I worry about people intercepting the message while being routed across the net, since I'm not exactly a criminal and anyone who knows me is not smart enough to intercept my email, but I fear that someone will gain access to the recipient's mailbox (boss monitoring email, friend is over playing around on computer..) and reads a message I would rather they not see.

A problem with relying on encryption of email solving this problem is that most mail clients will allow you to save the message in a decrypted form for filing once it has been received and decrypted. It would be much more secure if mail clients didn't allow you to save a message in decrypted form, and required you to identify yourself to the decrypter every time you wanted to go back and read an email.

The biggest problem with email encryption is that so few people have keys. I have tried to encourage friends and family members to use encryption by helping them create PGP/GnuPG keys and encrypting everything I send them. Sometimes they encrypt when they send back. Encryption of email might be more common if all the major mail clients shipped with encryption software bundled and installed/setup keys with the default installation.
More people would probably use encryption if they were aware they can do it, had access to the software to do it, and had it setup/knew how to use it.

My first job out of graduate school was at Trusted Information Systems (now swallowed by Network Associates) on the NSA-funded Trusted Mach project.

The idea was that you would run different OS sessions, each of which would provide a POSIX, or OS/2 (guess that dates the project), or whatever, "personality", at different sensitivity levels on top of the Mach microkernel. Data could be copied between sessions subject to security contraints. It was targeted (though never evaluated) to hit the B3 TCSEC critera. Interesting stuff, but it never really went anywhere.

This sounds very similar.

Tom Swiss | the infamous tms | http://www.infamous.net/

The BIND 4 hole(s) is/are going to be a BITCH to exploit, certainly not impossible; but hard enough that it won't be suprising if such never sees wide distribution. Quoth the original advisory:

"In order to trigger this overflow, an attacker needs to get BIND to cache an NS record with a very large length. Furthermore, the attacker needs to cache a record for the resolution of the NS record that contains one of the problem conditions for the logging. This is achievable by sending a query to a recursive name server, asking it to resolve a large name that is under the authority of a malicious name server. The malicious name server then needs to refer the request to another name server also with a large name, and provide an additional record giving an invalid address for that name server.

The limitations placed upon the character set allowed in domain names makes the construction of a viable return address difficult. However, there is a potential for an attacker to make the name server return into memory that the attacker has forced the name server to allocate. In this case, vulnerability is contingent upon the location of the heap and the amount of memory available, as well as whether or not the operating system has a policy of lazy swap page allocation as opposed to an eager reservation policy. COVERT has verified that it is possible to exploit named running under Linux by growing the heap to sizes that far exceed that amount of memory and swap available. This was performed by utilizing specific patterns of memory allocation that maximize untouched memory."

It's been said before, but:

Vote Libertarian.

Support the EFF.

Support the ACLU.

Use encryption (someone post me a Linux link).

Call your representative.

Don't just sit there, do something. Put the right people in power and this crap will get fixed.

DNSSEC and IPv6 are independant but complementary. DNSSEC allows the authentication of DNS data. IPv6 uses composite addreses (A6 records) thus it is imporant to be able to authenticate all the A6 records used to compose the 128 bit address.
A good short introduction to DNSSEC,it is little bit out off date as the DNSSEC standards have changed.

I'm gonna hold my nose and pull the lever for Bush, he represents the least totalitarian idealogy. Maybe we can explain the web to him.

You're forgetting one, and amazingly it's the one that's the *LEAST* totalitarian of the bunch: Harry Browne.

You probably don't know about him, because the press doesn't cover him. Curiously, they cover Nader, who's behind Browne in the polls, and who is also on the ballot in fewer states than Browne.

And if you want to explain something to the Libertarian party, you can use their PGP key.

Try that with the Republicrats or the Democretins.

-

I'm not certain, but I think the full ($$$) version of PGP do per-file/per-folder encryption. If you're doing aerospace work you should be able to fork out the pocket change for the software. =)

PGP Product Info

-Josh

So, I should think about the fact that I'm upholding fair use with the DeCSS-based program I'm writing. Or is the "social consequence" that the MPAA can't force me to use a $30 piece of software and get royalties for it?

How about Phil Zimmerman knowing that human rights organizations use PGP to thwart oppressive governments? Or is the "social consequence" that Louis Freeh has a harder time listening on your communications?

Freenet is going to be a censor-resistant network that will allow people to speak freely and anonymously-- giving people who may never have had a voice before the chance to make themselves heard. But, according to some, the "social consequence" is the availability of badly-encoded .mp3 files.

Any program worth writing has social consequences, dammit! Whether it's a hex editor that can be used for looking at core dumps or FooCat BarCode for reading in ISBNs, good programs have good and bad consequences. Within the bounds of legality (which are currently being tested), the ethical decisions of programmers should NOT be questioned by the government!

It seems all the these certifications refer to the design of the system, and don't address implementation aspects.

IIRC, you don't have to deliver the source to the evaluators, but you have to at least have someone in-house designated to do reviews. Somewhere in the huge pile of documents has to be plan for ensuring that implementation meets design - as well as plans for testing and configuration management.

The only two operating system/hardware combos I've ever seen with an A1 rating under this [yes, A1 is both hardware and software security] are Trusted Xenix [where did this one go?]

"...throw your message through a compression algorithm, like zip or gzip then hit it with PGP."

Read the PGP source code. Compression-before-encryption is already in place, standard. Unless things have changed, the InfoZIP (a la PhilKatzZIP) method is still used, just as it was in the early versions of PGP. (I haven't actually tracked PGP source changes since I started tracking GnuPG source, preferring a free(-as-in-freedom) alternative to the .COMmercial code.)

IIRC, somewhere in the docs I believe you will find an explanation as to why compression-before-encryption is utilized / good practice. You DID read the docs before using any crypto software, right? (cf. {insert link here about why RTFM is even more important with crypto than with other software} This link is left as an exercise for "Reply" karma-gleaning, heh.)

Since it's in the docs, not just the source, I'm surprised you don't know this. LOL.

(I'm not surprised others don't read crypto source before trusting it, but I *am* surprised if they don't at least RTFM. Would they also run untrusted binaries they receive via attachments to unsolicited email?)

The newly released PGP 7.0 (pgp.com) includes an ICQ plugin that does realtime encryption of all ICQ messages.

On top of that, it includes PGPnet, a VPN client that can encrypt all communications between two clients.

Don't reinvent the wheel.

What makes Carnivore different is:

• It's the US Government - There is an inherent distrust when it comes to privacy matters

• It's close sourced - We are even more afraid of what we don't understand.

Email has always been insecure. If you're really concerned about the mail that leaves your workstation, learn to use PGP, and get all your friends to use PGP. Suddenly, you won't care nearly as much about who's reading your email because it's all encrypted.

Zimmerman states that fixes to PGP 6.5.x will be available today, and that keyservers have been/are being modified to filter bogus ADK packets from public keys.

HTH,

fRoGG

It shouldn't, at all.

GPG is based on the OpenPGP standard ( RFC 2440 ) which doesn't, AFAIK, include "Key Escrow" or "ADK". PGP seemes to have "added" this feature, perhaps this is what the mean by "multiple recipents" in the E-business product.

Of course I could be wrong, but that's the way it looks to me :)

It shouldn't, at all.

GPG is based on the OpenPGP standard ( RFC 2440 ) which doesn't, AFAIK, include "Key Escrow" or "ADK". PGP seemes to have "added" this feature, perhaps this is what the mean by "multiple recipents" in the E-business product.

Of course I could be wrong, but that's the way it looks to me :)

then use a good level of encryption. i don't think any company is exercising due dilligance if they aren't encrypting their email.

use gpg or pgp. use mailers like pine, mutt or eudora that support them.

then they should use encryption. use gpg or pgp. use mailers like pine, mutt or eudora that support them.

use gpg or pgp. use mailers like pine, mutt or eudora that support them.

Most encryption software is still too hard to use. This plays into the hands of those who would spy on us because they don't even have to try hard.

PGP is more approachable now on Windows than it was back in the command-line-only days, but it is also a huge program.

What we need is for everyone to be using encryption all the time. Encryption should just be the standard, not the exception.

My client asked me to email her my source code, and I made her download PGP and send me a public key. It took some persuading to get her to do it. But I don't have the sense that she's going to be continuing to use it, I think that she only did it to humor me.

I encrypt every thing of value on my laptop with PGPDisk under windows and the Linux encrypting kernel under Linux - so if my laptop gets stolen the theives get nothing of value to them and my client's trade secrets are not revealed.

A friend's office was once broken into and all of his computers were stolen. They got all of his source code, his customer sales database, and all of his sales and support correspondence.

Are you protected against such an event?

Am I in The United States of America? The same country that passed the Bill of Rights? I forget because the so called "Drug War" mask makes me think that I am living in Communist China sometimes. This whole "Drug War" sure does allow the government to bend the rules alot in their favor, even when drugs aren't the reason people are being arrested. Made up monologue below...

GOVT: "Lets get everybody all pissed off about drugs so we can crap on the Bill of Rights, violate illegal search and seizure laws, restrict freedom of speech, restrict freedom of the press, seize "drug" property without due process (and spend the money like common theives regardless of guilt or innocence), lie under oath (I know officers who routinely do this in College Station, Texas! YES I'm calling you out ya perjurors! Bryan cops are better.), illegally monitor e-mail via carnivore, obtain wiretaps for the hell of it, etc..."

The best part of this whole thing is how the sneaky bastard that authored the bill snuck this in as a rider to the "Bankruptcy Reform Act of 2000". If you are my Senator or Representative you can bet your a$$ I'm not voting for you in the next election. I respect no representative that votes away the rights given to us by our forefathers. I would rather vote for Mickey Mouse, Homer Simpson, my dead dog Elmer (God bless that crazy dog), or even... dare I say it? Hillary Clinton.. aghhh!

Back to the serious side. I'm not a paranoid psychotic or anything, but it sure is quite clear to me that the "Drug War" is a very convenient tool for getting more illegal power for the government at the expense of what the UNITED STATES OF AMERICA was founded on! At least there are checks... I'm rootin' for the Supreme Court! But in the meantime I'm writing my both of my Representatives and my Senator!

JOhn
P.S. Bitch slap big brother and get PGP! -- http://www.pgp.com

Even the govt. can't crack PGP mail on a realtime basis. Encrypted email provides for secure communications. The only surprising thing is that people continue to send unencrypted emails. It's unfathomable why businesses don't use encrypted email exclusively. http://www.pgp.com/

Please read my page Why You Should Use Encryption.

If you get your mail from and put web pages on a hosting service, then at a minimum you should use one that provides secure shell (ssh) and secure copy (scp) access. One such hosting service that does is Seagull Networks. Does anyone know any others?

When you retrieve your email via POP or load a web page via FTP your password is being transmitted in the clear. You have no control over which routers and cables it passes through in the process, so you have no way of knowing if someone's running a sniffer on a compromised host. Usually you have no knowledge even of the route, unless you go to the trouble to run traceroute regularly.

You can download your email via an encrypted channel with ssh port forwarding if your mail host provides ssh. The instructions given are oriented to the BeOS but apply in general to any OS for which an SSH client exists.

If you run a website that uses passwords please consider allowing the users to enter their passwords via SSL (https).

If you use websites that require passwords, please use a different password for each site. At the very least, use a unique password for your important sites, like your email, web pages and financial sites. If you keep the passwords in a file (which you may have to do because there are so many sites that take passwords), encrypt the file.

Be aware that most sites that have passwords do not encrypt them, otherwise they wouldn't be able to send you your password reminder in clear text. I've even used sites that mailed out password reminders in the clear every couple months just to prompt me to use the service. Note that anyone at the site who has root access, anyone who compromises the site or anyone running a sniffer on or near the site will be able to catch your passwords.

Also I think it is very likely that many websites are provided for no other purpose than to collect passwords for later use by crackers - beware of that free trial and use a unique password if you must accept the offer!

Use the anonymizer or, if you have Windows 95 or 98, Freedom to protect your privacy while you web surf.

Finally, do you use a laptop computer? Do you have files on it that you don't wish to share with the random stranger who might steal it someday? How about your competitors? A thief won't likely be in the direct employ of your competitors but they may recognize the value of the information and sell it to them, or even post it on the net for fun.

And remember in this information age the information on our computers is more valuable than the hardware itself, and unlike car stereos can continue providing value to a thief because, once it is fenced, it is still available to be fenced again.

Depending on your OS, you should use PGPDisk or the Linux encrypting kernel on your laptop.

Consider encrypting important information on your desktop too. A friend of mine who is a software developer lost every machine in his company in a robbery - source code, strategic plans, and the customer database.

I know of two cases where laptops were stolen from intelligence agents, once during the Gulf war, and once from an MI5 agent while he'd set it between his legs at a train station. Good thing they used encryption!

Finally, read the Forum on Risks to the Public in Computers and Related Systems available on the Usenet News as comp.risks and on the web at http://catless.ncl.ac.uk/Risks

Tilting at Windmills for a Better Tomorrow

Also read my note Secure Email Download with SSH on the Be Tip Server. While the tip is BeOS specific, the basic ideas work fine on other operating systems.

Of course, to download your mail via SSH, you'll need a hosting service that provides it at their end, which is why I recommend Seagull Networks. Note that if you upload content to your website with FTP, you're exposing your password to network sniffers. Seagull Networks allows you to use secure copy (scp) for this so your password remains secure.

Finally, I use the Linux Encrypting Kernel under Linux and PGPDisk under Windows to keep important personal info like my Quicken checkbook, and confidential business information like the source code I'm writing for my clients encrypted on my laptop so the theives won't have them if my computer is stolen.

With either one you can create a big file that when mounted with a passphrase is accessible like any ordinary filesystem. I have even found that I can run MPEG movies off a PGPDisks with no loss in playback quality on my laptop which has a 450 MHz Pentium III.

Finally read the Forum on Risks to the Public in Computers and Related Systems for significant discussions on privacy issues. It is available as comp.risks on the Usenet News and on the web at http://catless.ncl.ac.uk/Risks/.

Do you think Microsoft takes care to protect your privacy when designing its products? Guess again.

The scary MSWord residue feature

I recently received a legal document as part of a personal negotiation that I am doing. The document was e-mailed to me in MSWord format. As I was showing it to my lawyer (who happens to be my wife), we decided to put our thoughts inline using the track changes feature of word. After selecting Tools, and Track Changes, we clicked on "Highlight changes in document" and voila, suddenly a whole bunch of red appeared on the screen. We looked at it closely and realized that everything in red represented changes in the document that my counterpart's lawyer had written. We got a good look at the previous version of the contract, as well as a bunch of comments and justifications that the lawyer wrote to his client. It was an eye opening experience.

It appears that instead of selecting "Accept all changes" before sending it to me, the other party to the contract simply turned off the highlighting to the track changes feature.

This is obviously a case of an unsophisticated person misusing a feature. However, it is very dangerous. Lawyers send word documents around all the time, and many of them do not really understand all the features that they use, nor should they have to. I imagine that I was not the first person to see some behind the scenes conversation in an important word document, that I was never intended to see.

I'd like to see Slashdot, for example, have the option of being served up on 128-bit SSL. I mean all the pages on the site. It would probably be best for the slashdot folks if this were done with hardware encryption support.

For one thing, encrypting all one's casual traffic helps to provide cover for people who really do have something to hide.

I recommend using a web hosting service which provides secure shell login access. One such web hosting service is Seagull Networks. Here is how I retrieve my POP mail through SSH port forwarding. The tip entry gives BeOS specific instructions but the basic idea should work on any platform for which SSH is available.

And yes I know my email is sent to seagull in the clear, but what this does is generate encrypted traffic (generally a good thing) and also prevents my ISP from snooping on me unless they hack into my hosting service.

If you work in a company and are concerned that your employer may be snooping on your personal email (you're not mailing out your resume are you? Know how an ethernet sniffer works?) then you should definitely use SSH for your mail.

Also on my laptop I use PGPDisk to encrypt my Quicken Checkbook and source code on NT, and the Linux Encrypting Kernel to encrypt source code on Linux. If someone steals my laptop, my clients won't have all their trade secrets stolen too.

Mike

99.9% of the people who consider putting honeypots on their networks should instead spend that time securing their vunlerable networks, checking for and applying the latest patches, and reading up on security trends and issues.

that said, honeypots are a really cool concept, nevertheless. but a network or security admin needs to focus on more fundamental security issues though. those NT network admins, for instance, should be deploying a second, or third, or fourth firewall on BSDi or Linux, instead of wasting time and compromising their security with a misconfigured NT honeypot. honeypots are best left for IT security research environments, or for people who have too much time to waste.

a notable exception is NAI's Cybercop Sting. Sting emulates Cisco IOS 11.2, Solaris 2.6, and WinNT 4, running common services. with Sting, you can pipe all of your legitimate traffic thrugh Sting, and utilize the excellent logging capabilities of Sting for an added layer of security. additionally, Sting can be, should be, and often is utilized to monitor employees (i.e. internal hacking/cracking attempts). since most of the security incidents will be from internal sources, honeypots are an excellent way to monitor for suspicious LAN activity.

there was an excellent discussion recently of the honeypot concept, with a wide range of opinions and views from all sectors of the Net population, on the Security Focus Incidents mailing list. the thread was entitled "Cracked; rootkit - entrapment question?", and was back in late February and early March.

for those who have more interest in honeypots, check out the following:

To Build a Honeypot - article by Lanace Spitzner

CyberCop Sting - product by NAI

dtk - Fred Cohen's Deception Toolkit

NFR's BackOffice Friendly - product by Marcus Ranum and L0pht

and finally, a cool new product that i saw at RSA2000
ManTrap - product by Recourse Technologies that is based on Solaris 7

I wasn't going to post this when I saw exactly how many other useful references you've already been given, but then I remembered how useful it was to me to get an understanding of the background, I thought I would anyway.

Phil Zimmermann is the bloke who wrote PGP way way back. The preface to the book "PGP Source Code and Internals" is well worth a read. It gives his background and the curious circumstances surrounding the development of PGP.

While there's not enough to base a whole project on by any stretch of the imagination, it will give some useful background and insights from somebody who is (IMHO) very clearly anti-governmental control.

Nick.

Probably not supposed to be a comprehensive list of topics there, but just in case... a brief history of PGP/PGPi would demonstrate almost all the issues you seem to intend to cover

========

I agree entirely. Indeed, look at PGP and what happened to it. The original PGP 5.0 if I remember correctly, while it was commercial, supported lower key sizes than the free version (key sizes of 50 were common).

Yet many people continue to use 2.6 internally. Why? Originally because it was better. And while the commercial version of PGP went forward, 2.6 has continued to remain behind on many servers, available for download. I think its to do with the open nature of the code, the ability to make changes if they are needed. People are naturally suspicious of binary distributions, which commercial programs must usually of necessity be. Better Open Source and a sureity that the software contains no backdoors than commercial with a truckload of holes in it. This is the moral Windows has taught us, if anything. The license protects the end user, and with good reason. Why pay for software which was originally free when the commercial version has less capability for upgrade and bug fixes than the free version?

How about using PGP to further encrypt files? Remember that for the US government, the "most powerful encryption software" only goes up to 128-bit RSA Lab closed-source technology. PGP, on the other hand, is astronomically much more powerful. I bet it would be quite frustrating for the FBI's $15 M cluster to be stumped by a file encrypted with a 4096-bit key made with PGPFreeware. You can get your copy at http://www.pgp.com/

Public keys are distributed to encrypt messages. The Distributer of the public key has a private key which is the only key which can decrypt a message.

The system: Public key can encrypt but not decrypt
Private key can decrypt and is not distributed.

Have a look at PGP. (or GPG:)

J:)

This particular site is just using common or garden analogue scanners. American/Canadian mobiles are still analogue (can you imagine that! No international roaming, loads of static- it must be like still living in the 80's).

If US/CA citizens are stupid enough to broadcast their private conversations on an open channel, that's their look out. They can have all the laws they like but it doesn't change the fact that analogue transmissions are no more private than standing on top of a hill and shouting (and what kind of idiot would draft a law that makes it illegal to own a pair of ears?).

I too live near Cheltenham and I take your point about GCHQ. However if GCHQ have a need to listen in to anything, no matter how it is transmitted or encrypted, they will. GSM or GPO, PCN or PGP it makes no difference. The most obvious way of doing this is by being present at the time of encryption or decryption, or by stealing the key physically, NOT by doing the maths. That's why we still pay our spies- to break in to places, plant bugs, and steal things.

The question is... do they WANT to be listening in to your or my lives? The answer I'm afraid is that they have loads more important things to do.

I know enough people there to know that, on the whole, they're an okay bunch of people. Sure there must be more than a few maneovolent bad apples but on the whole, they're good guys.

If you are going to worry about people hacking GSM or PCN then you are going to go very, very mad.

--