-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bits _never_ get written to the disk? Guaranteed never to use swap space?
The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is
not possible to make a Windows program insist on physical RAM the way a
program can in Open
Regarding Peter Guendl's discovery of DoS attacks against iWS 4.1:
1) Peter G. reports that disabling the cache with cache-init is not
an effective workaround for the FastTrack problem.
2) I wrote that iWS 4.1 has "at least one huge hole (remote code execution
via SSL/TLS implementation
Well, had you bothered to contact Netopia first, (what!, you didn't!
shame on you!), you would have found that the problem has been
resolved for some time now. The version of firmware against which
you are reporting this problem (4.6) is close to a year old. The
current version of firmware is
This entire thread and problem is basic computer crypto. If you want
something to be safe, you never store it plaintext, period. Granted, EFS
doesn't have loud red warnings if you encrypt a file that was previously
plaintext, but at the end of the day, this is not an EFS flaw---pure user
error.
From: Peter W [mailto:[EMAIL PROTECTED]]
Bits _never_ get written to the disk? Guaranteed never to use
swap space?
The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is
not possible to make a Windows program insist on physical RAM
the way a
program can in Open Systems.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-016-2 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 23, 2001
-
The URL given by Dan Kaminsky in a previous message for the Peter Gutmann
paper "Secure Deletion of Data from Magnetic and Solid-State Memory" seems
to be not working. A working URL is:
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
Ben Greenbaum
Director of Site Content
SecurityFocus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-
Debian Security Advisory DSA-016-3 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 24, 2001
-
I've got a couple of question on this issue..
The concern is that a temp file of the original plaintext may be left
around for an attack to "undelete". It's understandable why this might be
neccessary for a rollback in case of machine failure at just the wrong
time. (Though one could argue
Recommended EFS procedures call for the encryption of a direcory, not
file-by-file as the procedure indicated by Berglind suggests. If you copy
an
unencrypted file and paste it into an encrypted directory, the file and
the
temporary file are both encrypted.
This is actually covered in the
Quoting James Perry [EMAIL PROTECTED]:
As described on the MSDN site:
"The AllocateUserPhysicalPages function is used to allocate physical
memory. Memory allocated by this function must be physically present
in
the system. Once allocated, it is locked down and unavailable to the
rest
of
On Wed, 24 Jan 2001, John Wiltshire wrote:
Note that the PGP implementation uses a device driver (PGPmemlock.sys)
to lock pages into memory and prevent them from being swapped out. I am
unsure as to the motives of the GPG team if they have not implemented a
similar feature, but smells like
Addendum to my thoughts on the apparent EFS design flaw, which is actually
less significant than originally announced. Essentially, only files that
are converted FROM plaintext TO ciphertext are temped, meaning the bug only
affects files that were plaintext on the disk in the first place.
SP6 has been released by iPlanet.
http://www.iplanet.com/support/iws-alert/index.html
Karubin
-Original Message-
From: Peter W [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 5:35 AM
To: [EMAIL PROTECTED]
Subject: iPlanet FastTrack/Enterprise 4.1 DoS clarifications
14 matches
Mail list logo
