Re: Backdoor?
On Dec 13, 2007 7:35 AM, Robert J. Hansen <[EMAIL PROTECTED]> wrote: > The source code is out there. Inspect it yourself. Make your own > decisions and compile your own binary if you're concerned. Also make sure your compiler is open source as well. Inspect the code for that, too. And you have to translate that into machine language by hand, just to be safe! -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Decrypt problem with large file
On Dec 5, 2007 1:06 PM, Robert J. Hansen <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > a simpler, much faster, solution is to just use truecrypt > > and then encrypt the keyfile with gnupg > > Unless you have done performance metrics with 1TB datasets, I seriously > doubt the accuracy of this statement. Backing up 1TB is definitely a > torture test; small effects can grow to dominate. It is very possible We actually tired TrueCrypt first, but the problem wasn't performance. We actually didn't get that far. The issue we had was getting the automatic mounting of the removable HDDs to work well. Disks would either not auto-mount at all, or would be assigned the wrong mount point. This was before TrueCrypt 4 came out, so maybe those issues have been fixed. What we have is wokring okay for us, so we havne't gone back. Actually the biggest performance issue with 1 TB backup sets isn't the large files, it's backup of millions of small files. The volumes with little files take up 80% of the backup run time, versus the other 600 GB of Exchange and databse data that takes just a few hours. We think this is an NTFS problem, but it seems that most Linux filesystems have similar issues. We'll have to give ResierFS a shot next time we migrate our file server data. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Decrypt problem with large file
On Nov 26, 2007 3:58 AM, Thomas Pries <[EMAIL PROTECTED]> wrote: > I realized, that I have lost my data :-(. Our solution for backup encyption has been to use 7zip, since it encrypts faster and supports segmentation, per-file checksuimming, and other useful backup-oriented features. What our scripts do is: 1) generate a random hex symmetric key in memory 2) pipe that imput to GnuPG to encrypt that key (as ascii) into a small key file on our destination disk disk. 3) Use 7-zip with 2 GB file splits and the random symmtric key to compress and encrypt the backup files in .7z format from the source to the destination disk. We use the lowest (fastest) compression settings, and the 2 GB file splits because reading and writing to 4+ GB files is slow on NTFS and most other UNIX-type file systems. This is why VMware et. all use 2 GB file splits by defuault. 4) Pad most of the remaining disk space with PAR2 files, for extra protection against bad disk blocks. We use a very large block size for par2 - something like 128 Mb, IIRC. We do over 1 TB of backups per night to removable HDDs with this setup, and have never had a restore fail. We'eve never even had to use the par2 files in a real-world restore, but we do test "bad media" scenarios with them by deleting one of the 7z split files and using par2 to recreate it. Backups aren't worth much unless you test restore them to be sure that they will work. We test all of ours weekly. As a side note, we looked into using the new encryption options in the new version of Symantec NetBackup, but we don't have budget for that upgrade just yet. It would be nice to have it all in one step (even though NetBackup is closed souce, so trusting the vendor is an obvious issue). -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: WinXP problem with large files was: Re: Decrypt problem with large file
> Snoken wrote: > > is the old problem with files greater than 4 GB solved? How large > > files can gpg handle on WindowsXP? On other systems? My recollection is that the file size issue was fixed years ago, as it was a limitation in the MinGW layer or something that was remedied. I never followed up much, though, becuase GnuPG's encryption was very slow compared with alternatives (7-zip). When I used GnuPG, encryption was CPU-bound, even with compression turned off. When I use 7-zip, encryption of our 500 GB backup files is disk-bound. I also recall that Werner stated the AES code in GnuPG wouldn't be optimized for a number of reasons, becasue of security (timing attacks), and also a desire to keep GnuPG architecture-agnostinc. The faster AES code used by 7-zip pretty much assumes a 32-bit x86 processor is the target. It's C, not assembler, but the data alignment in 7-zip's code is very architecture specific. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: New OpenPGP standard published
On Nov 2, 2007 10:52 AM, David Shaw <[EMAIL PROTECTED]> wrote: > The new OpenPGP standard has been published. It was assigned RFC > number 4880 (someone at the IETF has a sense of humor): Is there an FAQ or other document which highlights only the changes and improvements since 2440? The output of "diff rfc2440.txt rfc4880.txt" didn't help me, and such a document isn't prominent on the OpenPGP WG pages. Thanks, -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP messages getting flagged as spam
You advocate a (x) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.) ( ) Spammers can easily use it to harvest email addresses (x) Mailing lists and other legitimate email uses would be affected ( ) No one will be able to find the guy or collect the money (x) It is defenseless against brute force attacks (x) It will stop spam for two weeks and then we'll be stuck with it (x) Users of email will not put up with it (x) Microsoft will not put up with it ( ) The police will not put up with it (x) Requires too much cooperation from spammers (x) Requires immediate total cooperation from everybody at once ( ) Many email users cannot afford to lose business or alienate potential employers ( ) Spammers don't care about invalid addresses in their lists (x) Anyone could anonymously destroy anyone else's career or business Specifically, your plan fails to account for ( ) Laws expressly prohibiting it (x) Lack of centrally controlling authority for email ( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses (x) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP (x) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes (x) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam (x) Joe jobs and/or identity theft ( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Extreme stupidity on the part of people who do business with Microsoft ( ) Extreme stupidity on the part of people who do business with Yahoo (x) Dishonesty on the part of spammers themselves (x) Bandwidth costs that are unaffected by client filtering (x) Outlook and the following philosophical objections may also apply: (x) Ideas similar to yours are easy to come up with, yet none have ever been shown practical ( ) Any scheme based on opt-out is unacceptable ( ) SMTP headers should not be the subject of legislation ( ) Blacklists suck (x) Whitelists suck ( ) We should be able to talk about Viagra without being censored ( ) Countermeasures should not involve wire fraud or credit card fraud ( ) Countermeasures should not involve sabotage of public networks (x) Countermeasures must work if phased in gradually (x) Sending email should be free ( ) Why should we have to trust you and your servers? ( ) Incompatiblity with open source or open source licenses ( ) Feel-good measures do nothing to solve the problem ( ) Temporary/one-time email addresses are cumbersome ( ) I don't want the government reading my email ( ) Killing them that way is not slow and painful enough Furthermore, this is what I think about you: (x) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid jerk for suggesting it. ( ) Nice try, assh0le! I'm going to find out where you live and burn your house down! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: professionalism, was Re: PGP messages getting flagged as spam
On 10/18/07, Robert J. Hansen <[EMAIL PROTECTED]> wrote: > With proprietary software, you're mostly stuck relying on your vendor > for information. Compare "Microsoft says that IIS will scale up to our > server load with our current server configuration" to "the Apache > Foundation isn't making any promises, but I've had Apache running for > the last month on a test server and it's performing flawlessly." > > The first statement's source is Microsoft. Their method is presumably > their own internal testing. Why wouldn't you set up a test lab with the Microsoft products as well? They offer zero-cost trial and developer editions of their products for that express purpose. You should never rely on the word of a vendor if there is an alternative. You can always find proprietary vendors that will give you a trial of some sort. At my company, we've had months-long trial installations of $1M+ vertical market software packages before signing any agreement to purchase. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP messages getting flagged as spam
On 10/15/07, gabriel rosenkoetter <[EMAIL PROTECTED]> wrote: > It's up o the site administrator to make use of SA rules that aren't > braindamaged. It's hardly the fault of the authors of SA if some > site decides to add 2.5 points to every message with a MIME > attachment, though you can, perhaps, see how that might be a naive > approach that works pretty well most of the time. Another problem: automatically adding negative score to PGP data would make that an attractive tactic for spammers. If such a rule were popular in SpamAssasin, you'd see a lot of base64 encoded HTML spam with "fake" PGP headers, I imagine. The real solution would be for SpamAssasin to check that the PGP messages are well-formed, and verify signatures on any PGP message before altering its score. A tad CPU intensive, I think, and it poses a host of key management and trust management issues if the SpamAssasin systems serves many users (which most do). -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA or DSA? That's the question
On 9/6/07, Oskar L. <[EMAIL PROTECTED]> wrote: > One thing I forgot to mention in that discussion, is that since DSA is the > default, there are probably many more DSA keys in use currently than RSA > keys. (If anyone has any statistics that would be interesting to see.) > Therefore, if a government were to invest serious time and effort in > breaking public key crypto, they would probably attack DSA, not RSA, in > order to get the most for their money. I'm not saying either one is weak > and could not stand such an attack, but if there's less pressure on RSA, > then I would consider that to be a benefit. I disagree. DSA is more popular - perhaps - for the narrow use case of OpenPGP keys. But RSA is the *far* more popular public-key algorithm, used in everything from SSL/TLS to secure military communications devices. A general technique which allows RSA to be broken is far more valuable than a general break in DSA or ElGamal. If you were a government spending money to crack crypto, wouldn't you like to be able to impersonate and read the traffic from every "secure" website on the planet? Oh, and read the mail of foreign militaries and diplomats as a bonus? Or would you want to read Werner Koch's mail and that of a few other crypto enthusiasts? Despite its standardization and patent-free nature, DSA isn't really that popular in my experience. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA 4096 ridiculous? (was RSA 1024 ridiculous)
On 6/19/07, Henry Hertz Hobbit <[EMAIL PROTECTED]> wrote: > than it took me to tar it. It also takes me much less time to > encrypt the tarred file than it takes to do the final bzip2 of the > encrypted file. Huh? Why would you try to use bzip2 AFTER encrypting? Strongly-encrypted data is not compressible. And GnuPG uses gzip compression by default *before* encryption anyway. I suppose you could be using bzip to compress an ascii-armored GnuPG output, but that is pretty silly (just use binary output from GnuPG instead). -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure text editor?
On 5/17/07, Alessandro Vesely <[EMAIL PROTECTED]> wrote: > Not quite. That may happen as an undocumented side effect on some > (or all) OS versions, and is not what the function is meant to do. > The function keeps the page in memory. The OS is still free to back > it up whenever it thinks it is convenient to do so. The documentation clearly states: "These pages are guaranteed not to be written to the pagefile while they are locked." Assuming the documentation is accurate, VirtualLock() should be safe for security applications. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Printing Keys and using OCR.
On 5/17/07, Andrew Berg <[EMAIL PROTECTED]> wrote: > Aren't optical discs supposed to last for many decades if stored > properly and almost never used? > Theory and practice are often far apart. The price of CD media has dropped so low that quality is often an issue. CDfreaks has many articles about this topic. Also, who is to say that a CD or DVD drive will even be available decades from now to read the discs? Could you read 8" floppy media on any equipment you have or can buy today? Could you find a paper tape machine to read data archived in the 1950s? Anything but printed characters on paper will likely require some form of archive maintenance over a decade timeframe. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Printing Keys and using OCR.
On 5/16/07, Peter Todd <[EMAIL PROTECTED]> wrote: > Then only that > passphrase needs to be securely stored and the secret key can be stored > with standard backup procedures. I believe the originally posted question centered around long-term key storage, for which magnetic and optical media are inadequate. Popular media would require continual maintenance, such as burning to new discs every 5-10 years, or upgrading the tape format to LTO-1600 in 2013. Whether or not the private key is protected by a strong pass phrase doesn't really matter; how to store and recover a key from paper is the challenge. This discussion does raise in my mind another issue: if you're worried about being able to read CD/DVD or other media at some distant point in the future, shouldn't you also archive the GnuPG source code so you can compile a version for some future architecture for which there may be no OpenPGP software? We know ASCII, HTML, and PDF will last forever, but OpenPGP is probably not guaranteed immortality by its popularity. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Printing Keys and using OCR.
On 5/15/07, Casey Jones <[EMAIL PROTECTED]> wrote: > There appears to be an open source project going for PDF417 > http://en.wikipedia.org/wiki/PDF417 We've used PDF417 for conference attendee badges in the past. They work well, and there seems to be quite a bit of hardware and software out there to support them. However, using *any* secondary encoding technique mroe complex than base64 is going to make recovery of the key that much more difficult down the road. Have you ever tried to recover a 15 year old file from floppy or tape? Just figuring out what the file format *is* can be a challenge. I would suggest using plain old base64 ASCII and a large version of a font like OCR-A or OCR-B. You can include par2 information, also base64 encoded, but finding software to use that data for recovery may be difficult many years in the future. Simply printing multiple copies of the page for OCR and diffing for errors would probably be easier. Finally, consider the paper and ink/toner you use... some cheaper paper is very acid, and some toner flakes over time. Regards, -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure text editor?
On 5/15/07, Alessandro Vesely <[EMAIL PROTECTED]> wrote: > Virtual memory is a feature that an OS can expose to apps. Memory mapped > files are an example. On Linux there are both shm and mmap. Traditional > SysV stuff may better suit inter-process sharing, while more recent APIs > emphasize multi-threading within the same process. On Windows there is > just one way to share memory. Memory locking must be understood in that > context. It is meant for synchronization purposes, not for security. LocalLock() and GlobalLock() do indeed seem to be for synchronization, but VirtualLock() seems a different beast entirely. It seems its purpose is for performance and/.or security. But again, I have little experience in this area, and I am just regurgitating what I read on MSDN. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure text editor?
On 5/14/07, Peter S. May <[EMAIL PROTECTED]> wrote: > (Developers familiar with swap-locked memory: I'd appreciate at least a > short explanation of how it works to someone who understands ISO C but > not necessarily OS-specific APIs. Can stack memory be locked, or only > heap memory? Would there be any way to load a whole, full-featured text > editor, such as the 1.8MiB vim on my machine, entirely into locked RAM > without screwing something up?) I'm certainly no expert, but I can offer a link, as I was just looking into this myself. Locking seems to be page-based on Windows NT systems, so I think it is only heap memory that can be locked. There is also the complication of the nonpaged pool in Windows having a smallish fixed size (a restriction mitigated by newer versions of Windows I believe). See http://msdn2.microsoft.com/en-us/library/aa366895.aspx -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure text editor?
On 5/14/07, Zach Himsel <[EMAIL PROTECTED]> wrote: > On 5/14/07, Peter S. May <[EMAIL PROTECTED]> wrote: > > On Linux, swap space is its own partition > I just realized something. You have the option to NOT use swap > space in Linux. Does this mean that there is no memory written > to disk? If so, then it might be plausible to either have a > dedicated machine with no swapfile for the encryption or > temporarily turn off swap for the encryption/decryption process > and then re-enable it after. The same option exists in all versions of Windows NT, but you have to change the system options to run with no pagefile and then reboot. We run most of our development virtual machines this way, to decrease the size of the virtual disk files. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure text editor?
On 5/11/07, Joseph Oreste Bruni <[EMAIL PROTECTED]> wrote: > It is a requirement that the files themselves be encrypted > individually or would it suffice to use an encrypted file system? It seems you really want/need a *full-disk* encryption solution, so that any temporary files and system pagefiles are also encrypted. We use the commercial PGP solution for that, but there are other options for Windows. The solutions are very OS-specific, though; on Linux there are quite a few free choices of varying complexity and quality. Truecrypt is somewhat cross-platform, and makes good encrypted file containers, but it won't encrypt the pagefile, or your system's security databases/password files (Linux or Windows). -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
On 4/18/07, Anders Breindahl <[EMAIL PROTECTED]> wrote: > > However, I assume you know what you talk about, when you say that we > aren't likely to factor 256-bit-numbers ever. So please restate that -- > even in the face of quantum computers -- we won't ever factor 256 bit > numbers. > > By the way, I realize that this is a more general question of gnupg's > life expectancy in a quantum computer world. But it's interesting to get > answered. Robert was referring to a 256-bit key space, which refers to symmetric encryption, such as AES, Factoring, on the other hand, applies only to public-key RSA encryption. There "bits" mean something totally different; a bit of RSA key length is "worth less" than a bit of symmetric key length. Numbers have already been factored in the ~600 bit range, so at least 1024 bits are recommended for RSA, and 2048 bits is a good idea. The "keyspace" size of RSA is roughly equivalent to the O(exp(64/9b)^(1/3)(log b)^(2/3)) that you quote; That is the number of operations that must be performed to break the algorithm by brute force. For strong symmetric algorithms,like AES or Twofish, the number of operations required is simply two to the power of the number of bits in the key, Note that breaking Diffie-Hellman and other discrete logarithm based algorithms is thought to be nearly equivalent to factoring, but has not been proven to be so. I suggest you borrow a copy of Bruce Schneier's _Applied Cryptography_; it is a very good primer. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Quantum computing
On 4/18/07, Ryan Malayter <[EMAIL PROTECTED]> wrote: > Factoring, on the other hand, applies only to public-key RSA > encryption. There "bits" mean something totally different; a bit of > RSA key length is "worth less" than a bit of symmetric key length. > Numbers have already been factored in the ~600 bit range, so at least > 1024 bits are recommended for RSA, and 2048 bits is a good idea. This page represents a reasonable snapshot of the state of the art in factoring: http://www.rsa.com/rsalabs/node.asp?id=2093 One must assume that a governmental entity like China's Ministry of State Security can factor significantly larger numbers than the 640 bit factorization done by academic researchers. Which is why you often see recommendations for 1500+ bit RSA keys. -- Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Summary: Windows GUI recommendation for USB disk
On 11/2/06, Henry Hertz Hobbit <[EMAIL PROTECTED]> wrote: 7-zip, like most zip programs encryption doesn't even come close to the level of protection that you are getting with GnuPG. Even if you are using the lowest level cipher GnuPG provides, it is a quantum leap over the zip programs enciphering. Quoting from the man page for zip (roughly comparable to 7-zip and probably uses the exact same code for enciphering): (And where security is truly important, use strong encryption such as Pretty Good Privacy instead of the relatively weak encryption provided by standard zipfile utilities.) When encrypting to a *.7z file, 7-zip uses AES-256 in CBC mode, with a passphrase-to-key function based on SHA-256. This is actually stronger than most cipher preferences on OpenPGP keys. It is not the same as the weak "winZip"-derived encryption. Of course, these files can only be read by 7-zip, but it is free and open source. (It also compresses a lot better than standard ZIP's DEFLATE algoritm, if more slowly). -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgdisk campaign
On 10/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: but they can get TrueCrypt for free now, There are two major reasons we're using the commercial PGPdisk here instead of TrueCrypt. 1) Manageability - PGPdisk offers centralized deployment, policy management, key escrow, etc. 2) TrueCrypt's inability to encrypt the boot disk on any platform. The first is a failing that many open source software have; management is usually accomplished through scripting. That adds lots of flexibility, but makes the product far less attractive to IT departments that just want to make it work quickly. The second is more of an architecture problem with TrueCrypt. PGPdisk and other whole-disk encryption products do some very low-level, OS-dependent stuff, like loading from the boot sector and then handing off to an OS-specific device driver. These are the sorts of things that are difficult to accomplish without heavy involvement from the OS vendor. This is also why a "GPGdisk" is probably unworkable. GnuPG is designed and strives for platform independence, and thinks like disk drivers are inherently platform specific. I would think that improving TrueCrypt, perhaps stealing the OpenPGP smart card support from GnuPG, is the "best bet" for full-featured, open-source whole-disk encryption program. Finally, let's not forget the 800-pound gorilla: Microsoft already has per-file encryption (with decent key management in the OS), and has added whole disk encryption to Vista. If those solutions work well enough, practical Windows users will not see the benefits of an open source disk encryption solution outweighing the complexity of their use. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RFCs, standards, pink bunnies and flower patterns
On 10/17/06, Mica Mijatovic <[EMAIL PROTECTED]> wrote: ... There is no any whimsicality in it (the previous message and wider) and the answers/observations are given quite sternly and with a quite fine necessary precision. ... It's like reading Ulysses, but as a day in the life of Richard Stallman rather than Leopold Bloom. Featuring, of course, just marginally more frequent punctuation, sentence structure, and coherent thought. At this point, I am inclined to say: UNCLE! -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG and PGP Compatibility
On 10/17/06, Conan Purves <[EMAIL PROTECTED]> wrote: Theoretically speaking, what is the difference between PGP and GPG? Is it just a different management tool handling the same encryption algorithm or is there some further translation between the two? Why does my Enigmail menu on Thunderbird say OpenPGP, but it is using the GnuGPG engine? GnuPG, as well as recent versions of the commercial PGP-branded products from PGP Corporation, implement the OpenPGP standard. They are in almost all cases able to read each other's data, and decrypt-verify that data. We use both implementations at my company. I have tested sending signed and encrypted email from a PGP desktop user to a GPG4Win user, and vice-versa, and was able to verify at least plain-text messages, as well as .sigs on attachments. One small difficulty arises in that GnuPG tends to use.gpg as its main file extension for encrypted files, whereas PGP Corp.'s products use .pgp. But that can be overcome with configuration settings, either in one of the programs, or by telling Windows what programs to associate with which file extensions. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RFCs, standards, pink bunnies and flower patterns was -- Re: GPG Outlook Plug-In and Signatures
On 10/17/06, Nicholas Cole <[EMAIL PROTECTED]> wrote: --- Ryan Malayter <[EMAIL PROTECTED]> wrote: > Again I must state that one has little to do with > the other. MHTML's > MIME format may not play nice with PGP/MIME's > encapsultation format, > but it didn't *have* to be that way. S/MIME, for > example, seems to > make provisions for playing nicely with other MIME > structures such as > MHTML, as well as arbitrary attachments. What is it about the PGP/MIME spec that makes it not play nicely with HTML email? Or vice versa? I'm not sure, but it seems no MUA or plug-in I have tried handles it correctly. I've always assumed that lack of HTML support said more about the crypto crowd's preference for text email than some technical problem, but perhaps I was wrong... This very well may be the case; it could just be an implementation issue. PGP/MIME seems to be based on RFC1847, which states: ...The first body part may contain any valid MIME content type, labeled accordingly... So, it would seem the "first body part" could be of type multipart/alternative (HTML). But I am unsure; as multipart/alternative is needed in the message header of an HTML email. RFC 1847 requires "multipart/signed" or "multipart/encrytped" in the message header. I think that may be what causes the troubles. Whatever the case, I always seem to have issues with attachments and HTML messages using PGP, but not with S/MIME. Although that may be a result of the limited selection of MUAs and software I use at my company. (Thuderbird, Outlook+GPGOL and Outlook plus the commercial PGP Desktop v9). -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RFCs, standards, pink bunnies and flower patterns was -- Re: GPG Outlook Plug-In and Signatures
On 10/16/06, Mica Mijatovic <[EMAIL PROTECTED]> wrote: RFCs are not any "standards" nor they are by (their own) definition supposed to be. They are just collection of less or more recommended routines, and often also nothing but the lists of (most usual/mass) _habits_. Many RFCs *are* standards. Those that are not are identified as "informational". Even the IETF thinks so, identifying them as the basis for "the Internet Standards Process". See: http://www.ietf.org/IETF-Standards-Process.html The only reason you can read this message is because RFC 2822 is universally recognized as the *standard* protocol for email. In order to define a _real_ standards, quite another criterions are needed, created after essential _sense_ of a given act/procedure. In this sense HTML definitely does not satisfy elementary needs to be included in a crypto scheme (due to the very HTML's technical characteristics). This statement makes no sense to me. Surely you are not suggesting that HTML is incompatible with cryptography? That's like saying apples are incompatible with cooking. Not only is it untrue, but you're not even really comparing similar entities. Of course that it doesn't mean that HTML should be banished completely from the 'lectronic mail world, but it has its essential limitations as for the cryptographic routines. Again I must state that one has little to do with the other. MHTML's MIME format may not play nice with PGP/MIME's encapsultation format, but it didn't *have* to be that way. S/MIME, for example, seems to make provisions for playing nicely with other MIME structures such as MHTML, as well as arbitrary attachments. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Outlook Plug-In and Signatures
On 10/14/06, Werner Koch <[EMAIL PROTECTED]> wrote: Anyway, HTML mails are evil. But unfortunately they're here to stay. RFC 2557 is now listed as "standards track". I used to rail against HTML mail myself, but all my reasoning was soundly rebuffed by the CEO, CFO, my Mom, my sister, and really just about everybody else. They want their "pretty fonts and pictures" in their email. Security, legibility, and compatibility be damned. Now, well, I gave up fighting that battle. I still write mostly plain-text email, but reply in HTML when sent it. But even I originate an HTML email or two when a bulleted list or table is needed. It can add value to the content of a message when used judiciously. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG Outlook Plug-In and Signatures
HTML + OpenPGP = FAIL. In English: HTML screws up OpenPGP. You don't want it. There are other reasons why you don't want HTML anyway but I won't go into them here. Actually, when I sign an HTML email with GPGOL, and send it to my Gmail account, I seem to get this on the receiving end: 1) A plain text version of the message, signed in-line. 2) An attachment of .HTML type, which contains the original unaltered HTML message. 3) A second attachment, which is seems to be an ASCII detached signature of the first attached HTML file. Does any other OpenPGP client handle this "attachment" result? Or do you need to save the attachments and manually verify the detached signature? GPGOL itself doesn't seem to read this "exploded" format, even though it creates it. GPGOL only verifies the plain text version. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: DSA2
On 9/24/06, Qed <[EMAIL PROTECTED]> wrote: I haven't seen much traffic on ietf-openpg mailing list about this issue, maybe the last message about ECC was in 2001. ECC is not a priority task for RCF2440, do you think this statement is more acceptable? As far as I know, Certicom and others control many patents related to ECC in the USA, Canada, and several other jurisdictions. Which is probably why there is no effort to add these to an "open standard" such as PGP that might then be patent-encumbered. The OpenSSL project recetly added ECC to its portfolio of algorithms, though, so someone must have done the investigatory work to determine that the OpenSSL implementation was not patented. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Automated processes
On 4/7/06, John M Church <[EMAIL PROTECTED]> wrote: > Qed/Ryan et al, > Do either of you guys do automated decryption? This doesn't seem to be > addressed in the FAQ - just automated signing. I'm open to suggestions. I do use GnuPG for automated decryption for one batch process. To do so, I use a low-value, single-purpose key that has *no pass phrase* and very strict permissions on the secring.gpg file. This file is then placed in a folder that is encrypted at the file system level (using Windows EFS). I think this is about as secure as you can make automatic decryption without trusted hardware being involved. An attacker with the ability to run code using the same account as my script would be able to read the secret key from the encrypted file system. Using the --passphrase-fd option would offer roughly the same security - that is, permissions on the script file would be your only protection, just as the permissions on secring.gpg are my only real protection. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ElGamal: key length vs performance
On 4/2/06, Qed <[EMAIL PROTECTED]> wrote: > Different implementations => different speeds. > You cannot rely on a particular piece software to infer general > performance figures for crypto algos. This is very true. In my tests, for example, AES implementation in GnuPG runs far slower than the implementation used in TrueCrypt, 7zip or a number of other x86-specific programs. I mentioned this speed difference to Werner a while back, and he explained GnuPG has to work on many platforms, so using code optimized for x86 - even if it is C-code optimized for x86 - isn't going to happen. Which makes sense. The easiest way to test is to simply encrypt the same file several times using different --cipher-algo parameters on the command line. My tests on Pentium 4s showed CAST5 to be the fastest algorithm in GnuPG on that platform, but your own hardware is different, you should run your own tests. See this discussion at: http://lists.gnupg.org/pipermail/gnupg-users/2005-August/026315.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Network Neutrality
On 3/22/06, Eric <[EMAIL PROTECTED]> wrote: > there are two ways "around" this, that I can think of, both > of which suck for Cox: > > 1. Content-based whitelisting, meaning you can't make any kind of > connection in or out unless Cox can identify the type of traffic by its > content. > ... > 2. A man in the middle attack, meaning Cox decides to break the > encryption, which is a mostly straightforward process in this case. This > creates several interesting problems. > I think you're ignoring the fact that Cox can throttle your connection simply based on analysis of traffic volumes. They don't have to do any crypto at all, or inspect any packets deeply. Throttling rules would be set up that say "hey, here's one client getting data at high speed from a bunch of other folks simultaneously, and sending data quickly upstream to a bunch of people at the same time." Such a rule would be fairly straightforward to implement by tracking a few simple counters per client. I imagine Packeteer and the other traffic-shaping vendors already have something along those lines available. Such traffic-pattern throttling wouldn't step on VPN or SSL connections, as they're typically from a single host to single host. Basically, BitTorrent has a very unique traffic pattern that makes the encryption at best a temporary roadblock to traffic shapers. The vast majority of BT traffic is from copyright violators, so it's not like the imapcted users will complain about the throttling in any official capacity. As for the impact on "legitimate" BT traffic like Linux distros... well, I'm sure Cox doesn't care one bit. It's not like the Ubuntu project is going to sue Cox over BT traffic shaping. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using other compression algos with GnuPG
On 1/21/06, Johan Wevers <[EMAIL PROTECTED]> wrote: > If speed isn't an issue, why would anyone prefer rar over bzip2? Bzip2 > compresses much better than rar anyway, although it's slow. Bzip2 does not compress better than RAR or LZMA, at least with my test corpus. See http://www.malayter.com/compressiontest.html 7-zip (using LZMA) produced the smalles files in this test, followed by RAR. bzip produced files 30% larger than 7-zip. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using other compression algos with GnuPG
On 1/20/06, David Shaw <[EMAIL PROTECTED]> wrote: > It's always possible for someone to add a nonstandard algorithm, but > if you really want a particular algorithm, it's healthier to get the > OpenPGP working group to add it officially. The RAR compression algorithm proprietary and closed source, so it is not likely to make it into any standards. RARlabs has refused for years to allow anyone else to make RAR encoders (although they exist in violation of the RARlabs license). See http://en.wikipedia.org/wiki/RAR A much better choice would be the LZMA algorithm from 7zip, which is open-source and unpatented. It compresses with similar efficiency and speed to RAR. In any case, though, such slow-but-compact algorithms are really only useful for archival purposes. While I have used PGP for some archiving, this is not the most common usage of PGP, and probably not an OpenPGP design goal. There are much faster file encryption tools than PGP out there. We actually use 7zip to compress and encrypt backups for offsite storage, as its AES implementation is so much more efficient than GnuPG's. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Create key's over 4096 bit ????
On 12/24/05, Ivan Boldyrev <[EMAIL PROTECTED]> wrote: > sqrt(2^1024)=2^512 The factoring algorithm with the best running time is still the GNFS. See http://tinyurl.com/dlyl5 GNFS has a running time of: O(e^((64/9*log(n))^1/3 * (log(log(n)))^2/3) When you subsitute 2^(keylength) for n in that equation, I get the following table for RSA key strengths and the comparable symmetric key length: RSA Key Bits Operations Symmetric equivalent 192 1.92821E+12 40 256 1.11356E+14 46 384 8.09434E+16 56 512 1.75249E+19 63 640 1.78448E+21 70 768 1.0746E+23 76 1024 1.31176E+26 86 1536 1.30666E+31 103 2048 1.52656E+35 116 2560 4.71401E+38 128 3072 5.77594E+41 138 4096 1.28186E+47 156 13568 1.28393E+77 256 -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: USB tokens instead of smartcards
On 11/9/05, Philipp Kern <[EMAIL PROTECTED]> wrote: > Yeah, I got that fact. So to clarify: A USB token with a supported > smartcard in it. I don't know if they are supported by GnuPG, but we have several of the Aladdin eToken devices bundled by PGP Corp. with PGP Desktop v9. They work fairly well with that commercial PGP implementation. http://www.aladdin.com/etoken/pro/usb.asp -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ECC
On 11/4/05, Jean-David Beyer <[EMAIL PROTECTED]> wrote: > I guess it depends on how your paranoia works, and about whom you choose to > be paranoid. Does the NSA recommend ECC for government use so that another > government agency (e.g., the NSA) can read, if necessary or desired by the > parties that control that government agency? If so, I would assume they know > how to crack ECC. In that case I would not want to use ECC. > > Or do they know how to crack everything else and have not yet cracked ECC? > In that case, I would want to use ECC. > > Paranoia is a wonderful thing, but it can trap you in dilemmas like this. > I don't like being a wet blanket, but as Bruce Schneier likes to point out, a smart attacker (the NSA certainly qualifies) will not expend resources trying to crack your crypto at all. No matter what crypto you use, so long as the crypto is reasonably strong and not trivial to break. There are far weaker points in the system (specifically: pass-phrases, endpoint hardware, operating systems, client applications, and your personal resistance to torture or other forms of coercion). We all love crypto here, and it is fun to compare algorithms and protocols and what-not. Dream up attack scenarios. And crytpo does indeed make us safer from a lot of attacks, such as those where adversaries only have the means to intercept or forge communications. As such, crypto is a good countermeasure against the average Joe bad-guy out there on the Internet. But to think that this algorithm vs. that algorithm is going to stop a very smart or well-funded attacker is folly. The crypto isn't the weak point in the system. Which is why the uproar over vulnerabilities in SHA-1 are (currently) silly, as far as I'm concerned. Yes, we should think about replacing SHA-1 fairly soon. But no need to panic jsut yet. It's still far easier to compromise a electronic system using other nefarious means. Doing 2^63 hash operations to find collisions isn't a cost-effective attack, even for the NSA. Unless the end result is extraordinarily valuable (like, say, being able to forge orders to another nation's military assets.) If you're *really* paranoid, you should think about ways to not have enemies like the NSA at all. Or at the very least, find the best ways to fly beneath their radar completely. The same goes for just about any other government entity in any nation. Because crypto won't protect you from the NSA, the DGSE, or even a reasonably sized organized crime syndicate. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Disk Partition
On Fri, 2005-10-07 at 10:07 +0800, nidhog wrote: >Do you guys have any suggestion as to how to go about encrypting a >partition that can be available both to linux and win32? Why not use a hardware solution, so it sits underneath the OS entirely? Seagate makes a new laptop drive that has built-in encryption functionality. A number of vendors make hardware encryption interfaces that work a the IDE or USB level (the USB devices are usually external enclosures). Regards, -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trouble decrypting AES256 symmetric encrypted file
On 9/19/05, Alphax <[EMAIL PROTECTED]> wrote: > I have a feeling Windows has problems with files this large, esp. on NTFS. This is surpisingly *not* a Windows issue. We have 200+ GB database files on many of our database servers. All using NTFS. I think the issue is that GnuPG is using a 32-bit DWORD file pointer and the older file functions. Werner mentioned using GetFIleSize, but the platform SDK indicates that you need to use GetFileSizeEx to enable files greater than 2^32 bytes: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/getfilesize.asp Werner, do you use GetFileSize or GetFileSizeEx? There are also WriteFileEx and any number of other -Ex file-related functions to handle files larger than 4 GB. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: trouble decrypting AES256 symmetric encrypted file
On 9/20/05, Werner Koch <[EMAIL PROTECTED]> wrote: > I have to commit that I did not try larger files on Windows for years > (lack of disk space) so here might indeed be a problem with that. A > quick check however shows that GetFileSize is used correctly. Werner, I can confirm that large file (> 4GB) support does not work on Win32 without using file redirection, at least in version 1.4.1. Did you make a change to enable 64-bit file sizes in a later version? I would love to help fix this issue, but as I have not worked with C much since 1996, I can probably really only contribute lots of testing. Are there debug builds of GPG for win32 that might be useful in this regard? Or will using "-vv" give the kind of information necessary? Thank you for any help/ideas, -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Forgot the key passowrd
On 8/10/05, Alphax <[EMAIL PROTECTED]> wrote: > How long will 8 characters (standard unix password length) take to break > at present? Using the supplied figure of 200 keys per second, and using only the 95 "printable" ASCII characters: (95^8)/200 seconds. Or about 1.1 million years! Obviously, if you know something about the structure of the password (inlcudes words, is mostly lower case, etc.), you can trim that way down. But 200 trials per second just isn't going to be verry effective for a brute force attack. -- RPM ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On 8/4/05, Werner Koch <[EMAIL PROTECTED]> wrote: > So roughly libgcrypt gets 55% of the performance of OpenSSL with AES > and 61% for 3DES. This all with a higher level interface, a non ia32 > optimized AES. I am pretty sure we can improve here but it will > require to duplicate code for the modes (CBS,CFB) into the actual > cipher implementation. My test show 7-zip yields ~228 Mbps on a 2.4 GHz P4. The only cipher available with this program is AES256 in (I believe) ECB mode. I presume this performance is the result of the efficient Gladman code and a P4-specific compiler optimizations used when building 7-zip. Still, it seems a bit odd that this program generates AES-256 throughput 2.78 times faster than the AES-256 implementation in GnuPG/libgcrypt on the same machine. I suppose those large lookup tables in the Gladman code really speed things up. (I would not think the extra XOR operation used in GnuPG's CFB implementation would account for so large a difference). Gladman's very fast GPL-compatible code (as used in 7-zip) is available at http://fp.gladman.plus.com/cryptography_technology/index.htm. He has C, C++, and x86 assembly implementations. You might want to take a look. Gladman's code uses large tables, which presumably makes it vulnerable to the recently publicized timing attacks. That should not be an issue for GnuPG, but might be for other programs that use libgcrypt. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On 8/3/05, Henry Hertz Hobbit <[EMAIL PROTECTED]> wrote: > Given the size of the files that you are encrypting, I would strongly > advise going with the Eden chip rather than a software based solution... I actually found an open-source tool, 7-zip, that includes AES-256 encryption functionality. For whatever reason, it runs several times faster than GnuPG in software. Fast enough, in fact, that the removable hard disk devices have become the limiting factor in the system (the 7-zip process only uses 70% CPU on a 2.4 GHz P4). The code is open-source, and it uses a salted + iterated SHA256 hash to produce the AES key from a pass phrase. The AES implementation is Gladman's well-known and fast C++ code. Looking at the source, I haven't figured out whether it uses ECB or CFB mode yet; the 7-zip code is rather light on comments. I am assuming ECB, which should be fine for my application. See http://www.7-zip.org for more details. Thanks for all the help. -- Ryan = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Protecting signing key
On 8/2/05, Johan Wevers <[EMAIL PROTECTED]> wrote: > As long as you're not as stupid to use the built-in functions. I've > heard stories that the FBI was very happy when they confiscated a > laptop from alledged Al Quaida members protected only by that - didn't > seem difficult to crack for them. And why use weak protection as you > can get good protection too? > Windows doesn't have whole-disk encryption yet, only per-file and per-folder encryption. That said, everything I've read indicates that the encrypting file system (EFS) in Windows 2000+ is reasonably well implemented. However, the user's password is still the weak link, as it is used to protect the private key that EFS needs for decryption. Because you can get the hash of this password from the disk in some way (you always have to be able to, otherwise you could not authenticate), the password is the weak link. Unless the password was very long and full of entropy, brute forcing it from the NTLMv2 hash would be easy for a government organization. And if the Al-Queda dude neglected to turn off the generation of the weak LANMAN hash, it would be even easier. (LANMAN hash generation is off by default in newer versions of Windows). Microsoft is putting whole-disk encryption into Windows Vista including card/token and RSA secureID support. Similar (hopefully better?) functionality is already available for 2000/XP/2003 from a host of vendors, including PGP Corp & PC Guardian. -- Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
throughput of GnuPG symmetric ciphers
I'm reposting this because it never appeared on the list for some reason, even after 12 hours. I was going to use GnuPG for encrypting some very large backup files on disk (~200 GB). However, the symmetric ciphers in GnuPG seem to be fairly slow. Using the Windows build of 1.4.2, I only modest throughputs piping GPG output from a fast 7200 RPM disk to >NUL (the Windows equivalent of /dev/nul). (See table at end of email). The process is not disk bound, since it uses 100% CPU and the different algorithms take different times. Compression was turned off. I have seen references on the net to fast software implementations of AES that are an order of magnitude faster than GnuPG on a P4 (~1.5 Gbps). See http://www.via.com.tw/en/resources/pressroom/2003_archive/pr031014edenn.jsp. Has anyone made a GnuPG patch that includes faster implementations of the core symmetric algorithms? What other tools are people using for encrypting backups in datacenter operations (as GnuPG seems to be too slow for this task)? Thanks for any help, Ryan Tests encrypting a 1 GB file on a 2.4 GHz Pentium 4. Cipher Algorithm Speed (Mbps) --- CAST5 153.39 BLOWFISH 59.24 AES102.26 3DES 64.59 AES-25681.81 TWOFISH124.49 -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
throughput of GnuPG symmetric ciphers
I was going to use GnuPG for encrypting some very large backup files on disk (~200 GB). However, the symmetric ciphers in GnuPG seem to be fairly slow. Using the Windows build of 1.4.2, I only modest throughputs piping GPG output from a fast 7200 RPM disk to >NUL (the Windows equivalent of /dev/nul). (See table at end of email). The process is not disk bound, since it uses 100% CPU and the different algorithms take different times. Compression was turned off. I have seen references on the net to fast software implementations of AES that are an order of magnitude faster than GnuPG on a P4 (~1.5 Gbps). See http://www.via.com.tw/en/resources/pressroom/2003_archive/pr031014edenn.jsp. Has anyone made a GnuPG patch that includes faster implementations of the core symmetric algorithms? What other tools are people using for encrypting backups in datacenter operations (as GnuPG seems to be too slow for this task)? Thanks for any help, Ryan Tests encrypting a 1 GB file on a 2.4 GHz Pentium 4. Cipher Algorithm Speed (Mbps) --- CAST5 153.39 BLOWFISH 59.24 AES102.26 3DES 64.59 AES-25681.81 TWOFISH124.49 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Passphrase Encoding and Entropy
[Oskar L.] > Thanks for your anwser, but I'm afraid you mostly told me > what I already know. What I don't understand is how this > relates to breaking passphrases. > For example, say I use the passphrase foobar. It has 6 > characters, each represented by 8 bits, so it will be > represented by 46 bits. These 46 bits are then the key used > to symmetrically encrypt/decrypt my secret key, right? > (Another question; is salt added to it, and/or is it hashed?) There are a number of options in OpenPGP for converting a pass phrase to a symmetric encryption key. They are called "String-to-Key (S2K) Specifiers" and are listed in RFC-2440. Some are salted, others unstalted, and some use more than one iteration of the hash function. Many different hash functions are supported, although MD5 and SHA-1 are the most commonly used. I believe the GnuPG default settings work like this: the passphrase is stored as unicode (UTF-8 encoding maybe?) in memory, the random 64-bit salt is read from the password file and tacked on to the begginnging of your passphrase. The entire salt + passphrase string is hashed with SHA-1. That generates the encryption key used to encrypt the private key or file with 3DES. > Now if the attacker knows that I have only used the 23 > characters a-z in the passphrase, then she/he can represent > all of them using 5 bits. But I don't understand how this > helps the attacker, since foobar represented this way would > obviously produce a completely different key (of only 30 bits). It helps the attacker because the attacker only needs to try 26^6 combinations instead of 95^6 combinations. That is a big difference. The all-lower case password would require ~2^27 guesses on average to crack. The one using six of the full 95 characters on a U.S. key would require about 2^38 guesses. That makes it ~2000 times harder to crack (but still very weak considering all the multi-core multi-GHz computers cheaply available out there). The fact that the attacker must take the time to make the SHA-1 hash of each guess doesn't really figure into the discussion, since making that hash takes the same amount of time for every guess - it is a "constant time" factor that drops out when comparing the relative strength of one passphrase vs. another. > I thought that all this was about time and the amount of data > you have to deal with. That, for example, when someone is > brute forcing a passphrase it would be 25% faster if all the > characters used were represented with only 6 bits instead of > 8. I understand why this would be faster, but not who it > could possibly work. It works because the attacker just has to make their password-guessing program smart enough to skip the unused characters. They start with "a","b"... then to "aa","ab","ac" and finally all the way up to "zy","zz". If they had to cycle through all the combinations of all the characters on the keyboard, instead of just lower case, there would be 2000 times as many steps in this process. They wold have to go through combinations like "4Av%#." Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: passphrase or random characters the safest
Just to inject some practicality into the discussion, a pass phrase with more than 64 bits of entropy is probably safe from all non-governmental attackers. After all, it took distributed.net five years to crack 64-bit RC5 using tens of thousands of machines. Beyond 64 bits, attacks against the endpoint computers (keyboard sniffers, etc.) and the key holder's body will be far more cost-effective and attractive. The pass phrase would certainly not be the weakest link in the security chain. Using a 2311000-word Oxford English Dictionary (the latest count I found on their web site), that's CEILING(64/log2(231100)) = 4 randomly selected English words. Much easier to remember, and those four words would actually provide 71+ bits of entropy. As 9/11 taught us, it's pointless to build ever-stronger defenses against attacks we already know how to defeat. Our bomb-sniffing and X-ray machines failed us when faced with a few fanatics carrying box-cutters. It is the *new* avenues of attack that we must think about and guard against. A 256-bit-strong OpenPGP pass phrase is pointless when used on a machine compromised by a keyboard sniffer, or when used to hide secrets from an attacker that is willing to torture the key owner. I recommend Bruce Schneier's latest books, _Secrets and Lies_ and _Beyond Fear_, which have great discussions of *practical* security. -Ryan- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Filesystem Encrytion with GnuPG ?!
=k3Rn= wrote: > Is it possible to specify a min password length (maybe > entropie) from that on the password can be considered 'safe' against > bruteforcing? The password length has little to do with the amount of entropy it contains. See this old thread: http://lists.gnupg.org/pipermail/gnupg-users/2004-October/023554.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: IBM to Provide Security w/o Sacrificing Privacy Using Hash Functions
[Alex L. Mauer] > Can you expand on this? > > How could the Name/address/ssn be retrieved from a hash of the same? > The data can be recovered from the hash because search space is small. Say you are looking for the SSN of a John Smith. Every large DB is bound to have someone named John Smith. If you have access to the hash DB, all you need to do is calculate the hash of "John/Smith/000-00-", "John/Smith/000-00-0001", etc. until you find a matching hash. Iterating through all the SSN possibility, that's only a 30-bit search space, and can probably be handled by a modern CPU in a few minutes. Once you find a match, you know James's SSN. Things get much easier if you know a particular person is in the DB, or know more about them to remove certain variables that might be in the hash. Even adding the home address to the hash isn't useful, because there are 400 MB files that contain every street address in the US available on the market. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Timing attack against AES
[Jean-David Beyer] > Aside from the necessity to compromise the machine running > gpg to get the > timing data for this attack, > just how much data can a timing attack retrieve from a > multiprogramming > system, such as UNIX, Linux, etc., anyway, since all the > other processes > running at the same time, which could include web servers, > file servers, > database servers, name servers, mail servers, etc., would > really add a lot > of noise to the data obtained? In the attack, signal-processing techniques were used to remove or smooth the noise in the timing data. In fact, the demonstration server he "attacked" was running OpenSSH on Linux, meaning it was servicing hardware interrupts and the like, adding at least some noise to the data collected. I presume that more noise in the system means more data collection is needed to find "accurate" timings and therefore extract the key, but I know just a tiny bit about signal processing from one college class, so I am no authority on the matter. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Timing attack against AES
[Per Tunedal Casual] > 2) Are any other ciphers safer to this kind of attack? What about the > ciphers in OpenPGP applications? Other AES candidates? >From my reading of it, it looks like any cipher with data-dependent S-boxes would seem to be susceptible to this class of attack. I think that would include 3DES, Twofish, etc. from what I know of their design. > 3) Would it be easier to write a fast implementation of some > other cipher > that is immune to this kind of timing attacks? Not for me ;-). > 4) What are the plans for GnuPG? I do not think this timing attack is a serious issue for GnuPG, since it does not work as an encrypting server that encrypts and transmits packets in real time. Obtaining timing data would require a compromise of the local machine. If an attacker can do that, why wouldn't the attacker just snag the pass phrase from the keyboard, or the plaintext? There may be some implications for GPG systems which automatically receive-encrypt-forward, such as GPGrelay. However, since a different block cipher key is used with each run in OpenPGP, obtaining enough accurate timing data might be impossible. In the attack, the same key is used to encrypt different plaintext repeatedly. I think the real implications of this attack are for VPNs or other "encrypting oracle" network services. But most site-to-site VPN devices use hardware ASICs these days, which would probably mean a constant-time implementation of AES and 3DES at least. Attacking software-based VPN clients may be a possibility, but again a local compromise of the machine is probably an easier attack to mount - even if it is running a hardened FreeBSD or something similar. Regards, Ryan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Encrypting for a user who has a IDEA public key
From: [EMAIL PROTECTED] > Is this expected behaviour of > GnuPG? I thought GnuPG does not support the IDEA algorithm in any > form. Could someone please shed some light on this? The default fallback algorithm is 3DES... All OpenPGP-compliant programs must support it. If GnuPG can't find a matching cipher in its prefs list, it falls back to using 3DES. -ryan- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
