Re: did you really expunge that key?
[EMAIL PROTECTED] (Peter Gutmann) writes: Which operating systems leak memory between processes in this way? Win32 via ReadProcessMemory. The documentation for the function says it will check read access permissions. Isn't this permission check done properly? I.e., disallow memory reads across processes owned by different users. If so, this should be reported and fixed. The remaining situation seems to be if ReadProcessMemory() on the running process leak data initialized by dead processed owned by other users, any pointers to information on this case would be appreciated. Most Linux systems which set up the user as root when they install the OS. The combined total would be what, 97%? 98%? 99%? of the market? If you can run a program as root, aren't there easier way to discover passwords than allocating memory initialized by other processes? E.g., attaching a debugger to /bin/login. Which operating systems write core dumps that can be read by non-privileged users? Watson under Win32, any Unix system with poor file permissions (which means a great many of them). Again, that's most of the market. This *is* a serious issue, which is why any security software worth its salt takes care to zeroise memory after use. My point is that the software in general cannot solve this without help from the operating system. In particular, software cannot protect itself from operating systems bugs that reveal secret data handled by the software. If you run security software on a insecure host, you won't achieve security no matter how good the security software is. A pair of functions secure_memory_allocate() and secure_memory_zeroize() that handle volatile char* data, together with a compiler that respects the volatile property, seems like a useful interface. No doubt, this already exists. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: did you really expunge that key?
John S. Denker [EMAIL PROTECTED] writes: 1) This topic must be taken seriously. A standard technique for attacking a system is to request a bunch of memory or disk space, leave it uninitialized, and see what you've got. I find that this thread doesn't discuss the threat model behind expunging keys, and this statement finally triggered my question. On which systems is all this really an issue, and when? Which operating systems leak memory between processes in this way? Which operating systems swap out processes to disk that can be read by non-privileged users? Which operating systems write core dumps that can be read by non-privileged users? My gut feeling tells me that if you can allocate memory on a system, there are easier way to attack it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
Steven M. Bellovin [EMAIL PROTECTED] writes: While I generally am on board with this, I can see a situation where the encryption overhead [and complexity] may be excessive [underpowered mail servers administered by beginners] compared to the gains. The primary use of STARTLS for SMTP is for mail *submission*, not relaying. While it may was designed for submission, STARTTLS use in relaying probably transports more mail -- looking at the past month, of the 82000 mail I received close to 11000 was delivered in encrypted streams. 7% is quite nice... I wonder how that compares with the use of OpenPGP or S/MIME in mail. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP GPG compatibility
[EMAIL PROTECTED] writes: Things would get much better if a PGP 2 version with support for CAST5 would get more into use. [ etc. ] On Sat, 9 Feb 2002, Russell Nelson wrote: I know that you're working hard, Werner, but I believe that the recent few years have destroyed the PGP brandname. I think the only worthwhile way forward is to create a cryptographic email standard de novo, which is free of export, trademark, and patent problems. On 9 Feb 2002, at 22:36, Lucky Green wrote: I believe such a standard already exists. It is called S/MIME. Best of all, this email encryption standard is supported out-of-the-box by the overwhelming majority of deployed MUA's in the world. However, to make it work, everyone needs to get officially blessed keys, and manage those keys. I believe it would be fruitful to separate the secure email message formats (S/MIME vs PGP/MIME, or perhaps CMS vs OpenPGP) from the key trust mechanism (PKI CA vs PGP web of trust). In theory I cannot see why one decision need to affect the other, they could be orthogonal issues. Perhaps by reading the relevant standards creatively, a mailer sending S/MIME messages but uses a OpenPGP implementation locally is already possible. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
