Re: copy protection
At 01:23 AM 12/25/2000 +0100, [EMAIL PROTECTED] wrote: Don't tell me I can't find a crypto-free mass storage vendor. I expect the approach will make the software refuse to install on noncompliant disks. They already have extensive equipment requirements, adding compliant disks to the list (especially when virtually all machines are shipping with them) is trivial. The only protection from this is user revolt. Hopefully it will occur. jay
Re: Good crypto products?
If you are running W95/98, try Scramdisk. It creates a virtual drive in a fully encrypted (your choice of algorithm) binary file (which can be stego'd if desired). Files are opened and saved to this disk, Explorer, recycle, etc. works like any regular disk drive. http://www.scramdisk.clara.net/intro.html jay At 12:41 PM 9/20/1999 -0700, Rob Lemos wrote: Can anyone recommend a good product for encrypting information on the fly, meaning encrypt the file when you close it and decrypt it when you open it. It would also be nice if it would ask you whether you wanted the file you are just closing to be encrypted. That is, it builds a list as you use your computer, rather than requiring the user to be explicit up front. PGP requires too many steps to be truly useful here. Any suggestions? -R
RE: more re Encryption Technology Limits Eased
At 10:26 PM 9/17/1999 +0100, Antonomasia wrote: From: Lucky Green [EMAIL PROTECTED] after he began talking about some very curious, very complex, very undocumented instruction he discovered in late-model CPU's. Instructions that will put the processor into a mode that makes OS protections irrelevant. This is scary. It could be time to hoard antique computers. I would like to see some discussion of what are the actual possible CPU subversions. All the obvious subversions would seem to require a cooperating OS. In many ways, CPUs seem to be limited as targets since they see only opcodes and databytes, it certainly would not 'know' it was working on cyphertext any more than it would know know it was recalcing a spreadsheet or calculating a pixel. A compromised OS could, of course, be saving keystrokes to a file, or sending them out in packets. But the CPU does not see files or packets or keystrokes, only individual opcodes. The only obvious effective subversions I can think of off hand are: RNG (can be potentially countered by replacing with trusted software) Radiation of signal for TEMPEST. (Since the CPU cannot determine what it is actually doing, it would have to radiate its entire operation stream...hundreds of millions of ops per second, mostly doing background stuff. Without a cooperating compromised OS, it would be up to the attacker to sort out the meaningfull from the noise...not an easy task...especially if there are 2 or more units located in close proximity). With all the techies on this list, I would like to hear other types of CPU attacks discussed wo we can anticipate problems. What would these 'specialized' opcodes look like? jay
Re: NSA key in MSFT Crypto API
Some quotes from: http://www.wired.com/news/news/technology/story/21589.html "Windows is compromised!! Microsoft is in bed with the Federal Government," wrote one poster to a mailing list addressing privacy and crypto issues. Not attributed, but that sounds like cypherpunk WG III. Unfortunately also these quotes from Russ Cooper, moderator of the NTBugtraq Windows security resource: He said the lion's share of individuals overreacting to the claims are freedom fighters and privacy advocates. "Unfortunately they have a loud voice," he said. "I don't think they are representative of the average person, the real people that populate the Net," he said. "We give away all kinds of things, every day, that sacrifice our privacy. These privacy advocates, I'd put them in the category of the Michigan Militia, the Ruby Ridge folks." Apparently, according to Cooper, privacy folks are not like "real people". His comment not only dismissese the seriousness of the immediate issue (which may or may not prove to be valid ultimately) but he seems to consider those who raise such questions government intrusion as some form of crackpot not to be taken seriously (real people shouldn't mind privacy intrusion). jay
Re: Eason/Kawaguchi stego
--
From: David Honig [EMAIL PROTECTED]
To: Jay Holovacs [EMAIL PROTECTED]; Russell Nelson [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: Eason/Kawaguchi stego
\begin{nuance}
Except that encrypted LSBs will be perfectly uniformly distributed
and normal noise won't. Its possible to reversibly sculpt crypto
data to have a less conspicuous spectrum.
\end{nuance}
Good stego can choose LSBs from pseudo randomly bit locations. LSBs from
these locations should be indistinguishable from random if appropriate
images are used.
jay
Re: Eason/Kawaguchi stego
-- From: Russell Nelson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Eason/Kawaguchi stego Date: Tuesday, June 29, 1999 9:27 AM . Also, only a few parameters are needed to retrieve the information, so anybody with the appropriate detector and a few guesses can find the information. Yes, that's right, it's only hidden from view, not from even the least determined observer. But if data is properly encrypted first, noise extracted from any picture should be virtually indistinguishable from encrypted data. Stego is really just obscurity with plausible deniability, it should never be used without encryption. jay
