Windows 2000 Save plaintext passwords and encryption keys to disk facility
Windows 2000 includes a very dangerous feature as part of its power management interface which saves the current system state to disk before putting the system into hibernate mode. Unlike the (already considerable) problems with a swapfile, which creates the risk that encryption keys, passwords, and other sensitive data will be written to disk, the hibernate feature *guarantees* that this data will be written to disk since the entire RAM contents are written to the hibernat.sys file before the machine switches to low-power mode. Exact details on this are very sketchy (http://www.microsoft.com/hwdev/onnow/), but it appears that this is a fixed file like a swapfile. Result: Anything which can read this file (insert any one of dozens of "... remote users can read files on the machine" security holes here) can grab your passwords, PGP keys, and anything else which is sitting there in plain view. Although this feature has been present on various laptops for awhile (eg Thinkpads, Toshiba's), the fact that it's now built into the OS (firmware- based hibernation which saves to files doesn't work with NTFS or HPFS partitions) and that your keys get saved as a standard file (as opposed to being squirrelled away on some hidden partition or whatever) makes it somewhat more serious. The only real fix for this would be to encrypt the data as it's being saved. Peter.
[RRE]I-Gear list cracked; privacy violations and error rate
From: Phil Agre [EMAIL PROTECTED] [See also http://www.peacefire.org/censorware/X-Stop/xsdecode/. Reformatted to 70 columns.] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). You are welcome to send the message along to others but please do not use the "redirect" option. For information about RRE, including instructions for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 1 Mar 2000 15:05:04 -0600 From: [EMAIL PROTECTED] Subject: I-Gear list cracked; privacy violations and error rate One week after our report on the decryption of X-Stop's blocked site list, Peacefire has released a program that can decrypt the list of 437,000 sites blocked by I-Gear, another "censorware" program now owned by Symantec. The codebreaker program can be downloaded from: http://peacefire.org/censorware/I-Gear/igdecode/ (This page also has instructions on how to obtain I-Gear's encrypted list without having to download and install I-Gear.) We performed an experiment similar to our X-Stop test: we extracted student pages in the ".edu" domain that were blocked in the "Sex/Acts" category, looked at the first 50 URL's that were still working, and found that 76% of the blocked pages were obviously errors! This sounds ridiculously high, but I saw the blocked pages myself, otherwise I wouldn't believe it. The list of 50 examined sites is at: http://peacefire.org/censorware/I-Gear/igear-blocked-edu.html We also discovered that when you install I-Gear, it scans in your real name and company name from your computer and uploads this information to Symantec. Not the "real name" that you give the program during the registration process -- your actual real name that you used to register your copy of Windows. (This is the name that shows up on the "General" tab of the System applet in Control Panel.) Symantec's privacy policy, on the other hand, states: http://www.symantec.com/legal/privacy.html "The choice of how much personally identifiable information you disclose to Symantec is completely at your discretion." Again, we believe these discoveries will bear on the ongoing debate over the Digital Millennium Copyright Act, UCITA (the law strengthening the force of draconian "license agreements" that prohibit users from examining products by reverse engineering) and the DVD codebreaking court cases. Reverse engineering I-Gear and decrypting the list was the *only* way to obtain a reliable figure for the error rate of their product, rather than just coming up with a list of blocked sites. Even the discovery that I-Gear retrieves and uploads your real name to the manufacturer, was discovered through reverse engineering. If such reverse engineering becomes illegal, it will become very difficult for third parties to criticize software in general, other than the user interface and other aspects that are visible without "looking under the hood". -Bennett [EMAIL PROTECTED] http://www.peacefire.org (425) 649 9024
zarro boogs (was Re: NTK now, 2000-03-03)
At 8:01 PM + on 3/3/00, Danny O'Brien wrote: HARD NEWS zarro boogs On Monday, the REGULATION OF INVESTIGATORY POWERS BILL will get its second reading in the Commons. Then it goes to committee, then it becomes law, and then you'll never hear from it again, because talking about most of its powers will get you five years in prison. So, when the police ask your ISP to put a tap on your mail, you won't hear about it. When your local trades and standards officer decides to take a look at your browser log for the last month, you won't hear about it. And when they come and get your private encryption key so that can read your friend's mails, you won't be able to tell your friend - or us - that it happened. Hell, you won't even be able to change your key if that might give us a clue. Given that it's all going to get so quiet so soon, STAND thought it might be an idea to let our MPs know that we're still here. So, with mild and belated fanfare, please welcome - STAND's Open Web to MP fax gateway. Peruse the bloody-long-but-not-as-long-as-the-bill STAND Guide to RIP, then send your comments on the Bill direct to your constituency MP's office with just a few clicks. But please be quick - MPs have only ten days from Monday to propose their amendments. At the very least, we should get an anti-spam statute out of it. http://www.stand.org.uk/ - may be a few bugs. but, hey, there's bugs everywhere these days http://www.stand.org.uk/ripnotes/ - liberty requires eternal vigilance (and magnifying glass) -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
No Subject
Hi... I need help. I am a student studying crypto protocols (newbies). I have a problem pertaining group signatures, which has many use in electronic commerce too. My problem ~~~ Actually, right now, I want to create a group signature, which upon group signature verification by the group manager, the 'private signing key' of the signer will remain hidden. Of course, the group manager will still know who sign the signature by recovering proofs/traces of signer's public 'key' or public 'identity' in the signature. If this can be accomplished, it means that the signer can use the same 'private signing key' for an unlimited number of times, even if his identity is revealed upon signature opening by the group manager (but only his public 'identity' / 'key'). Related paper: ~~~ I've studied a paper titled "Efficient Group Signature Scheme for Large Group" (Crypto 97) by Jan L. Camenisch and Markus Stadler. Their solution is nice and really efficient. However, I think, in the paper, the group manager can impersonate the member, after the group manager opens a group signature. The reason is because the signer's 'private signing key is compromised' by the group manager. Is this true? I do not want this property. If anyone can give me some directions what should I have to do (to let the group manager know only the public 'identity' of the signer upon signature opening), I really appreciate it. Or, if somebody you know has already published the solution to this problem (at least as efficient as your basic group signature protocol), please let me know. Thank you very much. Sincerely -mukti
How to avoid those pesky crypto security measures
An except from Microsoft Knowledge Base Article Q228786: -- Snip -- Sometimes it is convenient to export/import plain text session keys. However, the Microsoft Cryptographic Providers (Base and Enhanced) do not support this feature, for which both CryptExportKey() and CryptImportKey()require a valid key handle to encrypt and decrypt the session key, respectively. But, by using an "exponent-of-one" private key the same effect can be achieved to "encrypt" and "decrypt" the session key. Since the exponent of the key is one, both the encryption and decryption do nothing to the plain text, and thus essentially leave the session key unencrypted. Sample code below illustrates how to implement this feature: -- Snip -- I don't know what's more scary, the fact that their CSP will accept an obviously invalid RSA key, or that they have an article telling you how to bypass the CSP's (ahem) "security". I love the creative way that "gaping security hole" has been redefined as "feature" too :-). Peter.
Re: hiding plaintext
Bill Stewart writes: At 02:54 PM 03/01/2000 -0500, Russell Nelson wrote: The essence of the above algorithm (let's call it BP1, for Buried Plaintext 1) is to force the decryption trial to be iterated until the buried plaintext is found. It means that the decryption engine needs to have the full crypttext available to it. If you can decrypt a message in N steps, then using BP1 with half random data forces you to do N*2 steps, where the steps themselves are more complicated. The storage requirements are higher, as are the data transfer pathways. I'm not convinced that this is a big win compared to CBC with a random IV, which also forces the cracker to crank the crypto step an extra time. For many popular crypto algorithms, such as N-DES, Blowfish, even RC4, the key scheduling takes more time than cranking the algorithm (though there are ways to avoid that with 1-DES), and you know that once you find a SOT, that's the starting point, though if you've got the wrong key, 1/256 bytes will be SOT. Yes, but you're tying up a decryptor for that much more time. Cryptography is more about economics than anything else. You want to do things which cost the cryptanalyst more than they cost you, preferably as many multiples more as you can manage. But now I'm agreeing with you that there are probably other algorithms which are more profitable to you. That is, they have a higher multiplier -- for a given amount of effort spent, they generate more work for the cryptanalyst than anything else. And realistically, that translates into key length more than anything else. Perhaps HP1 is best used to pad messages while creating the least possible known plaintext. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | "Ask not what your country 521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | do for you..." -Perry M.
Re: please help FreeNet by becoming a node
In message [EMAIL PROTECTED], Steve Schear writes: At 09:56 AM 3/2/00 -0500, Steven M. Bellovin wrote: It is worth noting that some bans on running servers are based on technology , not the business model of the provider. In IP over cable systems, there is much less bandwidth available upstream than downstream, and it's much more expensive to add more upstream bandwidth than it is to add downstream bandwidth. If you run a server, you're chewing up a lot of capacity, and affecting your neighbors. But you're right, it's a real concern for users of Freenet (btw, isn't that a trademarked term?) -- I have the same problem as you do. Seems the firewall restriction is more of a concern. Anyone who cares about their PC's integrity and communication privacy should have a firewall for always-on connections. In the next year or so look for many/most cable modems and DSL boxes to provide a firewall function or have it as an option. There are a lot of responses to that; the real issue is who controls the security policy. --Steve Bellovin
