Re: Best Windows XP drive encryption program?
You are correct, I screwed up. They were both co-hosted at: http://www.scramdisk.clara.net/ The site was updated and is authorship is very clear. --- David Howe <[EMAIL PROTECTED]> wrote: > As an aside - Dave Barton? Shaun Hollingworth was the author > of SD as far as I know. I can't remember exactly, but seem to > recall Dave Barton did a delphi wrapper around some of the SD > function calls... = end eof . New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Re: European Data Retention and Encryption for Dummies
I strongly support your idea. Although it would even be more useful if you added: c) e-mail address user certs authenticated via confirmation message sent to the e-mail address being certified (as Lucky suggested) d) fully enable all certificates for all purposes, thereby allowing the certificate to sign code. I hope that you are able to implement this idea, as all efforts to increase the volume of encryption on the internet will ultimately increase privacy and show strong public support for cryptography in general. Curt --- Tom <[EMAIL PROTECTED]> wrote: > Hi everyone, I've been on this list before, but didn't have > time for it for a while. Now I'm back because I need some > input: ... > Setting up apache so that it does HTTPS instead of HTTP, and > all requests to HTTP pages are redirected to a page pointing > to the HTTPS equivalent and explaining why is trivial. > Getting the various MTAs to use SMTPS isn't too difficult, > either. > > The problem with both is the need of SSL certificates. So I > was thinking of setting up a "Joe Doe's CA". A simple webpage > where you can request a certificate. It would do two check: > > a) check if IP you are using is identical to the IP you are > requesting for, i.e. you'll have to ssh into your webserver > and use lynx from there. > > b) the certificate will be mailed to the admin-c of the > domain you requested it for (whois lookup). > > This is not 100% secure, but then again how much checking > does Verisign really do on certificates? I believe this > is "good enough" in that it establishes a reasonable safety > that you are talking to the right site, at least much better > than regular HTTP can offer. > > The purpose of this is to get as many sites to switch to > using HTTPS and SMTPS as possible. Therefore, the required > work must be kept minimal. Once considerable parts of the > internet traffic are encrypted, they can pass as many data > retention laws as they please. > > Any comments? What did I miss? Where does this idea come > apart? Does it make sense at all? > = end eof . Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: When encryption is also authentication...
I concur. The problem is that the most prevalent e-mail program (Outlook) requires no user intervention as a default when signing and/or encrypting a message with S/MIME. One can override the default to "High Security" (requiring password) only while the X.509 certificate is being installed. I also agree that alternative authorization mechanisms (or combination thereof) are entirely appropriate: smartcards, flashcards, biometric readers, magnetic strips, bar codes, etc. Different schemes will work provided the hardware is available and adequate authentication can be assured. Curt --- David Howe <[EMAIL PROTECTED]> wrote: > Partially agreed - a user doesn't have to know *how* it > works, but must have to take a positive step (eg, type in a > password, answer "yes" to a "are you really sure you want to > do this" message, that sort of thing) for it to be binding > under most e-sig legislation. However, the law of contract > assumes every dotted i and crossed t is read and fully > understood to the full measure of the law. Enough people get > caught out this way each year (they find the contract they > signed isn't what they negotiated but (eg) binds them to a > full term of service (say, two years) when they wanted a > three month trial... > There is a balance to be had here. it should be impossible > for a random user to walk up to their powered off pc, power > it on, then sign a document. It should be extremely difficult > for a random user to walk up to a pc that has been left > logged on (but which hasn't been used to sign documents for > five minutes or so) and sign a document; it should be easy > for the user to sign a large number of documents in rapid > succession, without having to type in a complex password > every single time. If this involves remembering the password > for a specified "idle" time, or using a smartcard to auth > (rather than a manual password or in addition) that the user > can remove when he takes a coffee break then fine - but > whatever you do must almost certainly use no other hardware > than is already fitted to the machine, so a usb dongle could > be ok for a home user but a credit-card style smartcard > almost certainly won't be (although if anyone knows a decent > floppy-adaptor for smartcards, I would love to know about it) = Curt end eof
Re: When encryption is also authentication...
I concur. The problem is that the most prevalent e-mail program (Outlook) requires no user intervention as a default when signing and/or encrypting a message with S/MIME. One can override the default to "High Security" (requiring password) only while the X.509 certificate is being installed. I also agree that alternative authorization mechanisms (or combination thereof) are entirely appropriate: smartcards, flashcards, biometric readers, magnetic strips, bar codes, etc. Different schemes will work provided the hardware is available and adequate authentication can be assured. Curt --- David Howe <[EMAIL PROTECTED]> wrote: > Partially agreed - a user doesn't have to know *how* it > works, but must have to take a positive step (eg, type in a > password, answer "yes" to a "are you really sure you want to > do this" message, that sort of thing) for it to be binding > under most e-sig legislation. However, the law of contract > assumes every dotted i and crossed t is read and fully > understood to the full measure of the law. Enough people get > caught out this way each year (they find the contract they > signed isn't what they negotiated but (eg) binds them to a > full term of service (say, two years) when they wanted a > three month trial... > There is a balance to be had here. it should be impossible > for a random user to walk up to their powered off pc, power > it on, then sign a document. It should be extremely difficult > for a random user to walk up to a pc that has been left > logged on (but which hasn't been used to sign documents for > five minutes or so) and sign a document; it should be easy > for the user to sign a large number of documents in rapid > succession, without having to type in a complex password > every single time. If this involves remembering the password > for a specified "idle" time, or using a smartcard to auth > (rather than a manual password or in addition) that the user > can remove when he takes a coffee break then fine - but > whatever you do must almost certainly use no other hardware > than is already fitted to the machine, so a usb dongle could > be ok for a home user but a credit-card style smartcard > almost certainly won't be (although if anyone knows a decent > floppy-adaptor for smartcards, I would love to know about it) = Curt end eof . Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: When encryption is also authentication...
I agree that the signer does not need to understand the mathematics or underlying technology for digital signatures to be viable. However, what good is an agreement when the parties do not know what the terms of the agreement are? A signature (digital or otherwise) generally indicates that the signer not only made an agreement, but also understood the agreement. A digital signatures must involve a conscious decision by the signer to keep their part of an agreement. I maintain that this requires user intervention to verify that the signer knew that they making an agreement - a "click of understanding" or pass phrase. Curt --- Mike Rosing <[EMAIL PROTECTED]> wrote: ... > Having it be "transparent" where the user doesn't need to know > anything about how it works does not have to destroy the > effectiveness of digital signatures or crypto. When people > sign a document they don't know all the ramifications because > few bother to read all of any document they sign - most of it > won't apply as long as you keep your part of the bargin, > so why bother? > > The same thing should be true of digital signatures. The > user shouldn't have to know a thing, other than they've made > a promise they better keep or all the bad clauses really do > apply, and the proof of their signature will come to haunt > them. The way the digital signature works does not > matter to them, and it shouldn't need to. > > If digital crypto, signatures or e-cash are going to get into > mass appeal, then their operations will be "magic" to the > majority. And it all has to work, to 1 part in 10^8th or > better, without user comprehension. > > It may well take "user intervention" to create a signature, > but they shouldn't have to know what they are doing. > > Patience, persistence, truth, > Dr. mike = end Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
When encryption is also authentication...
I agree that under-the-hood encryption is becoming more and more prevalent, and that it generally improves security. Also, the widespread use of encryption technology helps protect cryptorights in general as important to the public good. The fundamental problem with "under-the-hood" is that the user is not required to have any understanding of the process. Furthermore encryption technology is often also authentication technology. This includes transparently sending S/MIME documents (encrypted and/or signed) as a default without requiring additional user intervention. In many places this results in legally binding documents. Furthermore, anyone with access to a system can send legally binding e-mail documents on the user's behalf. Both legally-binding and authentication technology should not be completely transparent. Even "EULA's" require user-intervention. Digitally signed messages should require user-intervention. --- Lucky Green <[EMAIL PROTECTED]> wrote: ... > I indeed consider passive encryption methods alone to be > typically insufficient for some of my personal security needs > and am continuing to utilize encryption that requires me as > the user to make that trust decision. But that does not mean > that no security benefits are to be had from opportunistic > encryption of Internet traffic. ... > How does the increased use of strong crypto under-the-hood > help Cypherpunks? The answer reminds me of the response > another Cypherpunk gave to my posting statistics about the > nature of the USENET traffic seen by a major node. I > expressed surprise at these rather revealing statistics, > musing that there had to be a lesson to be learned from the > fact that the bulk of the data is generated in newsgroups > that one would not initially consider mainstream. His > response was illuminating: "Yes, the lesson is: just look at > all that cover traffic". > > --Lucky = end Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Key verification schemes...
(in response to a topic mentioned in various threads) I agree that neither CA-verification nor WoT-verification is as useful as Key Fingerprint-verification for secure communication between crypto-aware individuals. After all, CA's can be subverted and WoT is probably best used as a back-up option when direct key verification is not possible. Key Fingerprints can be verified in both PGP and S/MIME, but neither system enforces it. I would prefer for Key Fingerprint-verification to be more central to the system. --- [EMAIL PROTECTED] wrote: ... > The hierarchical verisign model is useful when one wishes to > verify that something comes from a famous and well known > name --that this software really is issued by Flash, that > this website really does belong to the Bank of America. In > this case, however, only famous and well known names need > their keys from verisign. No one else needs one. > > When one wishes to know one is really communicating with Bob, > it is best to use the same channels to verify this is Bob's > key, as one used to verify that Bob is the guy one wishes to > talk to. The web of trust, and Verisign, merely get in the > way. ... --- Eric Murray <[EMAIL PROTECTED]> wrote: ... > And to be honest, exactly zero of the PGP exchanges I have > had have actually used the web of trust to really verify a > PGP key. I've only done it in testing. In the real world, I > either verify out of band (i.e. over the phone) or don't > bother if the other party is too clueless to understand what > I want to do and getting them to do PGP at all has already > exausted my paticnce. ... = end Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Re: Joe Sixpack doesn't run Linux
The lack of e-mail detailing financial transactions is also the reason many businesses chose not to incur the overhead of secure communications. If there were servers on the internet which automatically displayed all plaintext e-mail messages which passed through them as webpages (for the bored, curious, and opportunistic), THEN everyone would see the value of encrypted e-mail. --- [EMAIL PROTECTED] wrote: > ... > The big lack of demand for encryption by Joe Sixpack is a > result of the lack of financial transactions using the > internet between Joe sixpack and Bob sixpack. > > --digsig > James A. Donald > = end LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
RE: NAI pulls out the DMCA stick
While we are on the subject of issuing your own X.509 certificates: 1. How do you create a X.509 signing hierarchy? 2. Can you add additional algorithms (ie. Twofish)? 3. Is a relavent developer reference is available for X.509? --- Peter Gutmann <[EMAIL PROTECTED]> wrote: > ... > So issue your own. Honestly, why would anyone want to *pay* > some random CA for this? > ... = end LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
RE: why OpenPGP is preferable to S/MIME
Self-signed and CA x.509 certificates cannot be used in Outlook even when they are added to the Trusted Root CA's. Apparently Outlook is able to distinguish between these and CA-issued x.509 certificates. --- "Trei, Peter" <[EMAIL PROTECTED]> wrote: > > I can't speak for mail-only clients, but it's easy (for > moderately > geekish or carefully instructed people) to add new trusted > roots to IE or Netscape. > > Peter Trei > = end LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: Joe Sixpack doesn't run Linux
This is a fairly accurate description of the situation, but neglects to emphasize that the reason [1-cypherpunk] bothers convincing [2-coerced associate] to use encrypted e-mail is because [1] understands its importance and is attempting to share/spread that understanding. Although [3-Joe Sixpack] may not understand or appreciate encryption, [3]'s support is helpful to protect [1]'s cryptography rights. Furthermore once [3] has crypto, [3] will resist attempts to take it away (along with his six pack, etc.). --- Meyer Wolfsheim <[EMAIL PROTECTED]> wrote: > ... > There are three main classes of mail encryption users: > > 1. The people who demand true security. > > These are the cypherpunks, the government agencies, the savvy > drug dealers, financial traders, etc. They won't trust S/MIME, > they won't trust EnvelopeMail, and they won't use Zixit. They > might use PGP, though if they have the resources they'll use > something developed securely in-house. This class is fairly > small. > > 2. The people coerced into using encryption by [1]. > > This is the government contractors, cypherpunks' relatives, > the drug couriers, and other business partners of the first > class. These people will use whatever standard is dictated by > the people with whom they must do business. This class is > also small, but makes up the majority of mail encryption > users today. > > 3. The people who might use it if it is easy. > > This is Joe Sixpack. This is who you are worrying about, > wanting S/MIME to deliver on its promises. This is Templeton > is worrying about, wanting opportunistic mail encryption. > > Public key crypto is a complicated, confusing concept. To > date, no one has even proposed a system that would be both > secure under a reasonable threat model for [1] and simple > enough to be groked by [3]. And guess what? [3] doesn't care. > [3] isn't asking for it. [3] might use it if it existed, but > you'd be lucky to be appreciated for your troubles. Most > likely, you're only in for a lot of criticism when your > solution doesn't measure up to [1]'s standards. > > If you want to be the guardian of Joe Sixpack, go right > ahead. Be warned that it is a thankless job. > > > -MW- = end LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
RE: NAI pulls out the DMCA stick
Although I also hope for widespread e-mail encryption, I feel that S/MIME introduces more problems than it resolves. Certificate Authorities issue certificates complete with CA imposed expiration dates and usage limitations. (I prefer independent systems with unrestricted certificates) Certificate Authorities match individuals to keys (Thanks, but no thanks) Certificate Authorities can revoke certificates at anytime (CA-driven DOS attack) These are in addition to compatibility and security issues. --- Lucky Green <[EMAIL PROTECTED]> wrote: >> Adam wrote: >> Which is too bad. If NAI-PGP went away completely, then >> compatability problems would be reduced. I also expect >> that the German goverment group currently funding GPG would >> be more willing to fund UI work for windows. > > Tell me about it. PGP, GPG, and all its variants need to die > before S/MIME will be able to break into the Open Source > community, thus removing the last, but persistent, block to > an instant increase in number of potential users of secure > email by several orders of magnitude. > > Here's to hoping, > --Lucky PS. "end" used to trunkate postings eliminating attached spam - does anyone know how to do this these days? end = end LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: NAI pulls out the DMCA stick
Disk encryption can always be augmented by physical security, however communication encryption is dependent on available encryption tools and legal rights. If quality tools are not available, then individuals and businesses will not use them. As long as communication encryption is not widespread, crypto rights will be vulnerable to attack as a special interest issue vs public safety. Of course privacy and other pillars of democracy seem to be special interest issues as well. --- [EMAIL PROTECTED] wrote: > -- > On 21 May 2002 at 15:03, Meyer Wolfsheim wrote: > NAI is now taking steps to remove the remaining copies of > PGP from the Internet, not long after announcing that the > company will not release its fully completed Mac OS X and > Windows XP versions? > > Not a problem -- we have too many communication encryption > programs already. Still a bit weak on disk encryption > programs, and of course, we have no transaction software. > > We may suspect that someone is leaning on the big boys not to > provide encryption to the masses, but if so, it is a bit > late. > > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > X6j99VDvTvGmFGh1D3CQg9dK9SHeYpD48/ZPZgHz > 4BH3f/B8/u/XrQuUz6UmSd7Vb0Xyl7FKwywwFfFdN = End. LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
RE: NAI pulls out the DMCA stick
Perhaps there is a conflict of interest issue as well? "NAI Labs is comprised of more than 100 dedicated scientific and academic professionals in four locations in the Unites States, and is entirely funded by government agencies such as: the Department of Defense's (DoD) Defense Advanced Research Projects Agency (DARPA), the National Security Agency (NSA), and the United States Army." >From http://www.nai.com/naicommon/aboutnai/aboutnai.asp --- Lucky Green <[EMAIL PROTECTED]> wrote: ... > LOL. Nothing new here. NAI has been dutifully sending > cease-and-desist letters to the well-known PGP mirror site > for years. The mirror sites just as dutifully have tossed > said notices into the trash can upon receipt. This has been > going on for over 5 years. > ... > --Lucky LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: on the state of PGP compatibility (2nd try)
Old software/source code should always be archived. I am also concerned when new versions of security or cryptography programs are introduced, especially if the source code is unavailable. This problem is very concerning when "subscription" and "live update" services attempt to force incremental patches and automatic upgrades on users. It is even conceivable for individual systems to be targeted with "special" patches. --- Morlock Elloi <[EMAIL PROTECTED]> wrote: > Getting caught in the upgrade scam is bad in itself. > > Doing this with crypto software is sin. > > There are no advances beyond 2.6.2 worth upgrading. > If you must, use 5.5.3i and enable only IDEA and > RSA/compatible. 2.6.2 runs on dos, integrates > with pegasus on windoze, runs on unix and macs. > > Also, always keep copies of "old" software. > You never know when a "feature" will be quietly > introduced or dropped from the new release. > (...) __ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/
Re: Babel (Re: on the state of PGP compatibility)
sMIME will always be hampered by Certificate Authority issues. PGP is large and complex. Version problems are bound to increase as some users will remain divided between PGPdesktop, PGPfreeware, and OpenPGP. Still others will want historic versions or ckt builds. Older versions are limited by key sizes and algorithm selections, while newer versions are prone to version problems. Simple 3rd Party options are important and must always be available.. I am developing a free program and simple specification - http://www.opencrypto.com - that integrates public key crypto into a basic SMTP program. I agree with Tim that it is perhaps best to settle on a single assymetric algorithm (RSA/DH/EC) and a single symmetric algorithm (3DES/AES/2FISH). Perhaps as every 2 to 5 years the algorithms could be replaced or key lengths increased (if necessary), without adding a extensive feature or significant complexity. And James, although the best standard may win, a lack of viable alternatives is unhealthy. --- [EMAIL PROTECTED] wrote: > On 31 Mar 2002 at 10:03, Tim May wrote: > > And so now PGP (or GPG) use is utterly balkanized, utterly > > useless. > > > > [...] > > > > Is there a solution? I would think that a "keep it simple, > > stupid" strategy is needed: Forget the hooks into popular > > mailers (Eudora, Outlook, Entourage), forget the "OS X > > versions of GPG," forget the Red Hat, Mandrake, SuSE, > > Windows XP, etc. versions. > > If PGP options have grown beyond human comprehension, perhaps > everyone could use my software, which is as simple as you can > get with a windows interface. > > http://www.echeque.com/Kong > > However, I predict that most people will wind up using > RFC2440 (OpenPGP) compliant code. > > An RFC and source code is far from "utter balkanization" and > utter uselessness. > > In due course, the best standard will win. > > --digsig > James A. Donald > 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG > uR++DP8NV5KuKFCaDraZEp6VTZQcmTqZI5aotgTD > 4KXzf6dt2b3+U2MX665Iy8h+EFpHj6Vw0HKjMhvoy > __ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/
