Cryptography-Digest Digest #462, Volume #10 Fri, 29 Oct 99 07:13:07 EDT
Contents:
Re: VXD Memory Allocator for Win9x ("Eric W Braeden")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: VXD Memory Allocator for Win9x ("Rick Braddam")
Re: VXD Memory Allocator for Win9x (Tom St Denis)
Re: Disk wiping code or utility (Tom St Denis)
Re: Compression: A ? for David Scott (Rebus777)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: the ACM full of Dolts? (David Wagner)
Re: Disk wiping code or utility (Fiji)
Re: Disk wiping code or utility (Clinton Begin)
Re: Unbiased One to One Compression ("Xav2")
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Symetric cipher (Emmanuel Drouet)
----------------------------------------------------------------------------
From: "Eric W Braeden" <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 21:20:19 -0400
You sure you want to write a VxD? Win95/98 will be
around for quite a while yet, but WDM is the wave of
the future. It will work on all future WinXX OSes.
Eric
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 29 Oct 1999 02:45:13 GMT
On 26 Oct 1999 11:39:30 -0700, in
<7v4sh2$ps2$[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (David Wagner) wrote:
>In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>> I see no reason why the negotiation protocol must be "cryptographic,"
>> other than in the sense that it will handle cryptographic objects
>> (ciphers). [...] The
>> negotiation protocol can afford to have some weaknesses.
>
>If you have a non-cryptographic negotiation protocol, you might end
>up with the weakest of the ciphers supported by both ends, rather than
>the strongest of them.
Fine. And if you don't change your cipher you might *also* end up
using the weakest of the ciphers *AND* never changing it.
Basically you continue to berate the idea of changing ciphers
apparently because that does not produce provable security.
But you conveniently overlook that the conventional alternative *also*
does not produce provable security *and* is willing to rely on the
same potentially faulty cipher for years on end.
>[...]
>This illustrates the risk of cipher negotation: you might end up with
>the _weakest_ of the available ciphers, and thus you'd better be very
>sure that every cipher you support is strong enough for all purposes.
Nobody can follow your advice. Nobody knows how strong their cipher
is. Neither do you, so it is strange advice.
It is also sloppy, since it is unnecessary that *every* cipher be of
some minimum strength. Indeed, it is only necessary that *one* such
cipher exist in a field of two, to beat the alternative of using one
cipher, if that happens to be the wrong one! And we cannot know if
that is the case or not.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 21:27:49 -0500
Thanks, Paul, I'm on my way.
Rick
Paul Koning <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>
> Check this out:
> http://www.dent.med.uni-muenchen.de/~wmglo/malloc-slides.html
>
> paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Fri, 29 Oct 1999 02:54:10 GMT
Basically anything you can suggest I can undo by saying
'Get user to run program X'. Security = Void.
Obviously this is also true for any other cryptoprogram, however the
need to secure local memory is so moot. A message in transit for
example cannot be attacked by a trojan if a end-to-end scheme (pgp or
peekboo) is used.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Disk wiping code or utility
Date: Fri, 29 Oct 1999 02:57:35 GMT
In article <7vaheo$i1n$[EMAIL PROTECTED]>,
Clinton Begin <[EMAIL PROTECTED]> wrote:
>
>
> I know you folks aren't here to solve programming problems, but at
least
> this will give you something to talk about other than compression. ;-
)
>
> Are there any generous developers out there who have code that they
are
> willing to share that will securely wipe the free space on a disk?
This
> code must be compatible with Windows 9x+ and Windows NT4+.
>
> Otherwise, does anyone know of a good standalone utility that is good
> for doing this and is compatible with the above mentioned platforms?
>
> Thanks much,
>
> Clinton.
What is the big deal with securing local information? For the most
part any security you try to provide locally is moot. Clearing
stack/swap space is a prime candidate. Since I could more easily [good
grammar?] remotely install a trojan and hitch you keys out of ram, then
sort thru a multi-meg swap file for a key in binary form ...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: Re: Compression: A ? for David Scott
Date: 29 Oct 1999 03:19:18 GMT
Rebus777 Wrote:
>>Since the object of this compression is to aid security in encryption,
>>would it not be a plus to add a simple random stream xor to hide
>>these patterns? This might allow you to improve the compression
>>algo, since any crc info would be disguised. :)
>
David Scott replied:
> Look it is not for every thing. But it does work where one could have
>used adaptive huffman compression and it does not add info. In a few
>months I will have others (I hope). But if your data such that it has
>lots of reapation after the compression pass than when you reverse
>the file and give it a second pass it should get smaller. The second
>pass makes it harder to break where one tries to exaimne a few blocks
>it forces the attacker to at least do one full decompression pass before
>any partial data becomes visable.
>David A. Scott
>
Wouldn't it be much simpler and more efficient to just us a very good
compression without headers and simply hide it's output with a random xor or
chaining as (Tom, [EMAIL PROTECTED])
suggests?
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 29 Oct 1999 03:21:24 GMT
On Mon, 25 Oct 1999 00:14:16 -0600, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>
>> Cipher negotiation can be far cleaner -- provided a single selection
>> mechanism is standardized. If not, then we may see the same sort of
>> ad hoc stuff we saw with modems.
>...
>>
>> Because the need is to change ciphers frequently, the desired
>> negotiation process is not one-time at the start, but rather, a
>> frequent or continuous process in different messages or sessions.
>>
>....
>>
>> There is no other possibility, unless you wish to depend upon the
>> strength of a cipher which explicitly HAS *no* known or guaranteed
>> strength. Not having strength is not a trivial detail, this is the
>> essence of the reason for using a cipher.
>>
>> The ability to change ciphers offers each of us the power to choose
>> what cipher we want to use. This means no government organization is
>> edicting our use, or forcing it through market pressure. We get to
>> choose what to use, and what not to use, and to change our minds on a
>> daily basis. That is not a trivial advantage.
>>
>Well, how clean can it be: Figure that you have a list of ciphers which
>you will accept. It is up to the sender to speak in one or them, at
>least.
Either end could and should have their own list. Either end could
propose a cipher from that list, or send the whole list. When the
other end accepts, or sends back a cipher name that can be accepted,
the cipher changes.
If agreement never occurs, the user should be notified, but from the
point of view of the cipher change state system, the next change
simply has not yet occurred.
Also I would support a different cipher in each direction, thus
simplifying the negotiation process.
>Figure that you develop a means of generating a key for any of them, but
>from something which may be acceptable in form to anyone of them, text of
>some sufficient length.
I would require each cipher to have some sort of hash which takes a
sequence of bytes to the internal keying value for that particular
cipher. The sequence of bytes could be a textual keyphrase of almost
arbitrary length, or just a random binary. In this way, we can use
the same key with any cipher we pick, and do not have to pick keys of
a particular form for each particular cipher.
>The recepient generates all the keys as needed, tries one at a time with
>an appropriate algorithm on the ciphertext. The system should lock to the
>one with the most appropriate recovered plaintext, likely only one that
>makes sense.
I would require the cipher system to include a hash of the message
with each message. This is not only to aid dynamically changing the
cipher, but also because using the wrong key is, in my experience, the
major sort of error which users encounter (assuming a stable
implementation). It is important to detect common user errors.
So, when the cipher changes, the cipher is *either* the last cipher
used, being used again, or the new cipher, just proposed. We try the
old one, then the new one. If the new one is OK, we accept it. If
neither, the next time we get a message we try both again.
>To change cryptosystems, just do it; at the other end, detection falls out
>of lock as the current system fails to recover reasonable output, and go
>back to checking the various algorithms, getting the new system, locking
>until unlocked.
>
>Sounds simple enough to me, but who am I to judge?
We can improve the efficiency quite a bit, but that is the general
idea. Maybe "negotiation" is the wrong word for many people:
Actually, it's a normal sort of handshake that we complete simply by
using the new cipher.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: the ACM full of Dolts?
Date: 28 Oct 1999 21:09:56 -0700
In article <7v6ubj$jj2$[EMAIL PROTECTED]>,
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
> The first cut of ACM paper in htm at my
> webpage. for there Crossroads online magazine.
>
> http://members.xoom.com/ecil/dspaper.htm
I think there might be a terminology problem here.
You say you want
[...] a mapping from one form to another in such a way that any thing in
one set maps uniquely to another item in the other set. Also every item
in that second set maps back to every item in the first set.
This is known, not as a one-to-one function, but as a bijective function.
A function f is one-to-one (or injective) if x!=y implies f(x)!=f(y).
In other words, this is your first criterion.
A function f is onto (or surjective) if every element in the range set has
an inverse. This is your second criterion.
A function that is both one-to-one and onto (i.e., both injective and
surjective) is called bijective. This is the notion you want.
Finally, I should mention that it seems what we'd _really_ like from a
compression function f is that its output should be (approximately) uniformly
distributed when its input is generated according to the distribution we
expect our plaintext to have.
In other words, view the original message M as a random variable.
(It might have the distribution you'd expect for English sentences, or
whatever you like.) We may also view the compressed text T = f(M) as a
random variable in the obvious fashion. Then, it'd be nice if T was
roughly uniformly distributed [*]. If we could say that T was roughly
uniformly distributed, then it'd mean that ciphertext-only attacks on
the encryption algorithm are essentially impossible (just by Shannon's
information theory, since we can hope there won't be enough redundancy
in T, the input to the cipher, to even approach the unicity distance).
In practice it seems extremely difficult to get very close to the
uniform distribution for T. However, _heuristically speaking_, we can
expect that the closer T is to uniform, the harder it will be to mount
ciphertext-only attacks.
Footnote [*]:
Actually, it was an over-simplification to suggest that T be uniformly
distributed, not least because T has unbounded length. Moreover, when
we encrypt T, typically the ciphertext will trivially reveal the length
of T to the adversary (but, we hope, nothing else). Thus, it seems more
appropriate to ensist that the distribution of T, conditioned on the
bitlength of T, should be approximately uniform. In other words, the
requirement is that Pr[T=t | T is b bits long] ~= 1/2^b for all b>0 and
all strings t of length b.
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Subject: Re: Disk wiping code or utility
Date: Fri, 29 Oct 1999 00:16:51 -0400
> In article <7vaheo$i1n$[EMAIL PROTECTED]>,
> Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> >
> > I know you folks aren't here to solve programming problems, but at
> least
> > this will give you something to talk about other than compression. ;-
> )
> >
> > Are there any generous developers out there who have code that they
> are
> > willing to share that will securely wipe the free space on a disk?
> This
> > code must be compatible with Windows 9x+ and Windows NT4+.
> >
> > Otherwise, does anyone know of a good standalone utility that is good
> > for doing this and is compatible with the above mentioned platforms?
> >
> > Thanks much,
> >
> > Clinton.
>
> What is the big deal with securing local information? For the most
> part any security you try to provide locally is moot. Clearing
> stack/swap space is a prime candidate. Since I could more easily [good
> grammar?] remotely install a trojan and hitch you keys out of ram, then
> sort thru a multi-meg swap file for a key in binary form ...
>
> Tom
Think of a CEO visting a country...say France. The CEO leaves his laptop
in his hotel room. This is/when the information could be taken from his
machine. Attack attacks while the machine is connected to a network should
be taken care of in a different manner. Some people have legitimate
reasons for securly wiping the visidual data left in unattached inodes
while their machine is not ont the network.
Personally on Wintel I use PGPDisk. It seems to work rather well with the
option of how many passes one would like to use (1-32 I believe).
-Fiji
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
>
------------------------------
From: Clinton Begin <[EMAIL PROTECTED]>
Subject: Re: Disk wiping code or utility
Date: Fri, 29 Oct 1999 04:35:25 GMT
For the most part, I agree with you.
However, the reason I need this tool, is to support those people who
don't.
Cheers,
Clinton
In article <7vb2eu$tpl$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7vaheo$i1n$[EMAIL PROTECTED]>,
> Clinton Begin <[EMAIL PROTECTED]> wrote:
> >
> >
> > I know you folks aren't here to solve programming problems, but at
> least
> > this will give you something to talk about other than
compression. ;-
> )
> >
> > Are there any generous developers out there who have code that they
> are
> > willing to share that will securely wipe the free space on a disk?
> This
> > code must be compatible with Windows 9x+ and Windows NT4+.
> >
> > Otherwise, does anyone know of a good standalone utility that is
good
> > for doing this and is compatible with the above mentioned platforms?
> >
> > Thanks much,
> >
> > Clinton.
>
> What is the big deal with securing local information? For the most
> part any security you try to provide locally is moot. Clearing
> stack/swap space is a prime candidate. Since I could more easily
[good
> grammar?] remotely install a trojan and hitch you keys out of ram,
then
> sort thru a multi-meg swap file for a key in binary form ...
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Unbiased One to One Compression
From: "Xav2" <[EMAIL PROTECTED]>
Date: 29 Oct 1999 07:26:29 GMT
"SCOTT19U.ZIP_GUY" writes:
> In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]>
>wrote:
> >There is no file ending problem any more than there is a file sector padding
> > problem. Simply
> >pad the byte with random bits.If you are truly concerned use a communication
> > mechanism that
> >tracks bits instead of bytes.
>
> I am perffectly happy with files that are made up of 8 bit bytes. However
> there is an ending problem in Normal Huffman coding. Since one would
> not know if the random fill bits added are random padding or the next token.
I'd guess one will just have to reserve a spot in the huffman tree as an
EOF then.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 10:32:31 +0200
SCOTT19U.ZIP_GUY wrote:
>
> TIm I did a quick look at it and yes I feel it would work. I have been
> thinking of a more complicated version but yours is more straight forward.
> I hope to is clear to users that as you search the long strings are
> replaced by the short one and that if a short string is found it is replaced
> by the long one.
>
> The weird way I was thinking of doing it was things like "th" replace with
> "q" if "th" not followed by "u" this way since q is usually followed by u
> then it would not be replaced and since th seldom has a u after it it would
> generally be replaced by a q
> So you can see mine would be messier.
>
> An alternate approoach is to allow for more than 256 symbols. You can expand
> from 8 bits to 9 bits with leading bit a zero for common stuff that way
> ( note the 9 bit or even 16 bit is a temporary file to allow for more than
> 256 leaves at start mabye only 267 leaves in huffman tree)
> "th" could be replaced by a new symbol when at the compression stage since I
> can easily allow 512 symbols with a slight mod to the current compressor. Know
> on decompression if a "th" not there as a special symbol. It would be count as
> a repeat of "th" where combinations of "th" and specail new symbol would
> represent the repeat count. This is what I am playing with lately.
>
> Keep up the good work
If I understand correctly, you are now on compression not operating
on groups of 8 bits but on group of bytes. That certainly removes
the remaining bits problem at the last byte of file on decompression
of an arbitrary file which is a factor giving rise to the original
one-to-one problem. However: (1) the frequency counts of such group
of bytes takes much larger work and the Huffman tree is much much
larger, (2) due to the larger granularity the compression ratio is
likely to be poor, I believe.
M. K. Shen
------------------------------
From: Emmanuel Drouet <[EMAIL PROTECTED]>
Subject: Symetric cipher
Date: Fri, 29 Oct 1999 11:26:36 +0100
Hello !
Please, could you give me informations about several cryptosystems :
Blowfish, CAST5 and SAFER
(what is their level security, which is the fastest, are they sensible
to specific attaks...)
- to resume, what are their caracteristics...
- what do you think about them,
- should I use CAST5/SAFER or CAST256/SAFER+ which are more recent ?
Thanks, manu :o)
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
