Cryptography-Digest Digest #461, Volume #10 Thu, 28 Oct 99 22:13:07 EDT
Contents:
Re: RC 4: security & law (Paul Koning)
Re: VXD Memory Allocator for Win9x (Tom St Denis)
Re: Weakness in the Rijndael key schedule? (Tim Tyler)
Re: VXD Memory Allocator for Win9x (Paul Koning)
Disk wiping code or utility (Clinton Begin)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Re: VXD Memory Allocator for Win9x ("Rick Braddam")
Re: VXD Memory Allocator for Win9x ("Rick Braddam")
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: digest/hash problem (Boris Kazak)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (d g)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: RC 4: security & law
Date: Thu, 28 Oct 1999 10:30:36 -0400
fungus wrote:
>
> Paul Koning wrote:
> >
> > FWIW, that ("delay... for years") doesn't match my experience.
> > 2-3 months is more typical.
> >
>
> Have you actually done this? Can you tell us what actually happens
> during the review process?
Yes, I have -- from the periphery, anyway. Much of the work
was done by (a) the prouduct mgr, (b) an export consultant.
I submitted a technical description (a couple of pages, much
of it of the form "it does standard IPSEC, see RFC mumble).
Then I answered a few random questions that came back over
the next few weeks (like "explain a bit more why you can't
configure this box to run the data through the cipher twice").
About 2 months later we had the approval in hand.
paul
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 17:57:54 GMT
In article <7v92lj$64e$[EMAIL PROTECTED]>,
"Rick Braddam" <[EMAIL PROTECTED]> wrote:
> I've started working on a VxD for ?secure? memory allocation on
Win95/98 (again). I would appreciate any advice, criticism,
> etc. to help with the implementation.
>
If the info is available on the computer at any time in unencrypted
form, no ammount of 'security' will protect you from remote trojans.
Your pursuit is moot. The best advice is to avoid getting trojans :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Weakness in the Rijndael key schedule?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 28 Oct 1999 18:49:37 GMT
solidash <[EMAIL PROTECTED]> wrote:
: So I guess your gospel is that" All Block Ciphers have backdoors if they
: are used in CBC , CFB or ECB mode cause that weekens the cipher?"...is that
: right...[?]
I don't think he thinks they have "backdoors"... Just that the
specifications are needlessly underspecified, and will almost inevitably
be broken by some security agency or another.
: P.S.....has anyone cryptoanalysed your Cipher?
I have no idea - but there is a cash prize if you can break it:
http://members.aol.com/jpeschel/contests.htm
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Hackers have kernel knowledge.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 15:22:28 -0400
Rick Braddam wrote:
>
> I've started working on a VxD for ?secure? memory allocation on Win95/98
>(again). I would appreciate any advice, criticism,
> etc. to help with the implementation.
> ...
> Which brings me to the first major problem, Allocation Strategy. A poor choice
>here can ruin the whole show.
That's for sure!
Check this out:
http://www.dent.med.uni-muenchen.de/~wmglo/malloc-slides.html
paul
------------------------------
From: Clinton Begin <[EMAIL PROTECTED]>
Subject: Disk wiping code or utility
Date: Thu, 28 Oct 1999 22:07:23 GMT
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.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 28 Oct 1999 22:10:37 GMT
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> (...)
>>It appears to me to be extremely difficult to define "intelligible
>>plaintext".
An update on how to send "intelligible plaintext" while using two
ciphers in random sequence:
Take two ciphers that work with 128 bit blocks; Twofish and Rijndael
are free and are good choices. Now implement the following protocol
that works on blocks of 120 bits of plaintext. For each block compute a
hash digest of 8 bits and concatenate it to the plaintext block;
randomly choose one of the two ciphers, encrypt the block and send the
ciphertext. Also, decrypt this ciphertext with the other cipher,
compute the hash of the 120 first bits of the result and compare it
with the original hash. If they are equal then add 1 to the plaintext
and repeat the whole process.
To decrypt try both ciphers and check the hash. If one hash is correct
and the other is not then use the plaintext that produced the correct
hash. If both hashes are correct then we have a collision. Read the
next ciphertext block and check the hashes again. If they are equal
(double collision with probability 2^(- 16)) then compare the 120 bit
plaintext block created now with the previous 120 bit block; if the
current block equals the previous block plus one, then you have
identified the correct cipher. There is a extremely low probability (2^
(-136)) of a triple collision in which both plaintexts come out
alright. If you worry about such low probabilities, implement a
protocol that loops around until the 8 bit hash doesn't collide.
This protocol is slow: to encrypt one block it uses a little over one
encryption and one decryption plus the time necessary to produce one
random bit; to decrypt it uses a little over two decryptions. Taking
into account the very high speeds achieved by modern ciphers, almost
all applications could live with this. The ciphertext stream is about
7% larger.
Why use this protocol instead of cascading two ciphers (with roughly
the same cost in speed)? I think the difference is this: By cascading
two ciphers you greatly increase the cost of most known attacks but
there is a chance that in the future a new attack will work even
against the cascade. Using two ciphers in random sequence wipes out
whole classes of attacks. Any attack against a cipher that requires a
lot of previous knowledge (more than about 30 plaintexts) will not work.
Some observations:
1. The 8 bit hash need not be "cryptographically secure". In this
context any fast hash function works fine. Probably even a simple xor
of all bytes would be sufficient.
2. The random number generator must be unpredictable. For high volume
work you will need a hardware based RNG (how fast is the new Pentium
chip in this?). For lower speeds (certainly for Internet client
requirements) you can use the PC itself as an entropy generator. I
think that Yarrow does something like this. I've written code myself
that collects entropy in the background using exact timing information
for mouse and keyboard events, hard disc access, etc; you can add a
hash of the state of the stack, and so on. (I like to call this an
"Almost Random Number Generator" or ARNG.)
3. Other variations. Instead of randomizing the cipher, we can design
similar protocols that randomize the encryption direction or randomize
the key. Examples: Use one cipher in a random sequence of encryptions
or decryptions. Use two ciphers each one with its particular key. Use
two ciphers and two keys for a protocol that is 4 times slower.
4. The following variant is more efficient (you pay 1% in speed and 1%
in space), but may be less secure: Use blocks of 127 bits of plaintext
to which you add 1 random bit. This random bit defines which cipher
will encrypt the next block. I believe that this protocol is not as
secure as the previous ones, because the information about which cipher
will be used is explicit.
Conclusion:
Normally, the attacker is supposed to know everything except the secret
key. In addition to this, the proposed protocol denies the attacker
knowledge about which cipher has been used for each block. Anything
that denies the attacker knowledge is a valid defense. I think that
this protocol makes it almost impossible to apply conventional
cryptanalytic attacks at a modest cost in speed and space.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 15:22:25 -0500
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:7va2r1$6k6$[EMAIL PROTECTED]...
> In article <7v92lj$64e$[EMAIL PROTECTED]>,
> "Rick Braddam" <[EMAIL PROTECTED]> wrote:
> > I've started working on a VxD for ?secure? memory allocation on
> Win95/98 (again). I would appreciate any advice, criticism,
> > etc. to help with the implementation.
> >
>
> If the info is available on the computer at any time in unencrypted
> form, no ammount of 'security' will protect you from remote trojans.
As long as trojans stay remote I'll not worry about them. I have a program which runs
continously and protects me from most attacks
(not absolutely all), which will prevent most of them from becoming local trojans.
> Your pursuit is moot. The best advice is to avoid getting trojans :)
What brand would you suggest? Sheik? I don't use them anyway.
> Tom
Do you have any advice, criticism, or comments that pertain to implementing
non-swappable or locked memory, or access control to
memory?
Rick
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: VXD Memory Allocator for Win9x
Date: Thu, 28 Oct 1999 13:26:52 -0500
Excellent beginning! Thank you. My comments or questions are inline.
Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brief comments
>
> 1. For memory allocation strategy I recommend a buddy system. The Fibonacci buddy
>system is more complex than the binary buddy
system,
> so I recommend the latter. Using a buddy system also allows you to maintain
>multiple free lists such that neither allocation nor
> deallocation requires tree/list traversal. Big performance win, some space lost.
Can you give me a reference for the binary buddy system? I'd planned on using the
B-Tree because it is the fastest *I* know about
for searching.
> 2. You need to insure that a program can safely reach your VxD and authenticate it.
>It would not be hard to provide a trojan
"secure
> heap VxD" that carefully copied each page of data to a log file before deallocation.
> So, how can you prevent an attacker from
> masquerading as you? This is hard
It would be *very* hard for me alone, but I'm sure that with help from you and others
we can come up with a good method of doing it.
Note: before anyone asks why they should help me develop a product let me state that I
will post the source either to this newsgroup
or to a web page where it can be downloaded. It will be free for any use.
> 3. You also have to authenticate the API that you use. Otherwise a layer beneath
>your VxD may leak. This is very hard.
Unfortunately, as far as I know so far, it will be necessary to use the Windows
standard interface for communicating with devices to
access the functions in the VxD. The VxD is opened like a device. The DeviceIOCtrl()
function is used to access functions within the
VxD. Such as:
hCVxD = CreateFile("\\\\.\\CrPP.VXD", 0,0,0,
CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE, 0);
if ( DeviceIoControl(hCVxD, CrPP_APIFUNC_1,
(LPVOID)NULL, 0,
(LPVOID)RetInfo, sizeof(RetInfo),
&cbBytesReturned, NULL) )
This is only used to allocate and free memory, access to the allocated memory is by
standard pointer usage. That's why I'm going to
investigate possible use of hooking the page fault handler, so I can check the process
ID of who is trying to access the data with
the one stored in the control structure and return NULL if they don't match (actually,
FFFE0000, an invalid address).
Rick
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Thu, 28 Oct 1999 23:46:50 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Rebus777)
wrote:
>David, I have DL your compression programs from your web
>page and have tried them on several text files. They do not
>seem to add any header info as you state, but they do seem
>to leave a lot of redundant strings in the files, especially if you
>are compressing redundant data.
>
>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. :)
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
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: digest/hash problem
Date: Thu, 28 Oct 1999 15:56:49 -0700
Boy wrote:
>
> Hi Folks!
>
> A problem regarding digest (or hash function):
>
> given:
> a byte stream D[0:n]
> 2 indexes x,y 0 < x < y < n
> digest( byte tream ) - a digest algorithm
>
> what 'digest' algorithm as defined above can give the following:
>
> digest( D[0:n] ) == digest( D[0:x] D[y:n] ) (digest of all D
> but the segment from 'x' to 'y')
>
> when:
> D[x+1] = START_SYMBOL
> D[y-sz] = STOP_SYMBOL
>
> (the above symbols can be anything you like. 'sz' is the size of
> STOP_SYMBOL)
==========================
I cannot see any problem, it seems to be a routine operation.
1.Start copying your file D into a temporary file D' until you
encounter START_SYMBOL.
2. Keep reading file D, but do not write into file D' until you
encounter STOP_SIGNAL.
3. Finish copying the rest of file D into D'.
4. Hash file D'.
If this is not what you mean, then I am at a loss.
Best wishes BNK
===============================
>
> What I need is an idea for an algorithm. It can be a modification of
> an existing one. It is important that it will be efficient.
>
> Lots of thanks in advance.
> Boy.
------------------------------
From: d g <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 28 Oct 1999 16:17:51 -0700
[EMAIL PROTECTED] (Vernon Schryver) writes:
> I think SSL assumes that it has TCP/IP underneath, which is less than what
> any cipher negotiating protoocol will assume for transport. What do you
> think?
TLS (the standardized version of SSL, rfc2246) assumes a reliable
connection oriented data stream. You can run it over, say, a
connection-oriented wireless data protocol that does not have the same
retransmission characteristics as TCP.
Cheers,
==
Dipankar
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 00:49:22 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>David Scott has proposed a property that it is desirable for compression
>programs intended to be used in conjunctioon with cryptography to have.
>
>This is that the compressor is "one-on-one" or that its action may be
>represented as a bijection between two sets of all possible texts.
>
>However one problem with actually /employing/ the scheme is the apparent
>paucity of non-trivial compressors currently available.
>
>Using a compression program less-than ideally suited for the target data
>raises security problems of its own.
>
>I've written a monograph detailing one approach to building such
>compressors in an attempt to help rectify this situation.
>
>The document describes a technique for building bijective compressors
>that target data types with a number of known properties. The example
>used discusses the compression of English text, an application for which
>the approach appears suitable.
>
>The approach is a simple one - but it is my hope others may benefit
>by having the technique clearly articulated.
>
>To quote the guts of the idea from the document:
>
>`` 6. Build your own one-on-one compressor
>
> The technique described here works by extracting any frequent,
> long sub-strings and swapping them with infrequent short ones -
> in a manner that is guaranteed to be completely reversible.
>
> The dictionary used in this operation is compiled in advance and
> may be optimised - by hand if necessary - in order to produce the
> best-possible characteristics for the target files.
>
> Files are parsed from top to bottom. The compressor systematically
> searching for any and all words which match those in the
> dictionary, and replacing them with their matching partners. After
> a replacement has been made, the file continues to be scanned from
> the first character after the last one that has just been replaced.
>
> In order to produce a compressor, two tables of words are
> required. Each table contains an equal number of strings, so that
> a bijection between them is possible. Together, the words in the
> two tables comprise a single dictionary.
>
> One table contains high-frequency long sub-strings from the text.
> The other contains low frequency short symbols (including
> sub-strings with a frequency of zero).
>
> The entirety of both tables in the dictionary is then "cleaned"
> according to the following two conditions:
>
> * No string in the tables should contain another such string as
> a substring;
>
> * No leading symbols in any string should exactly match the
> trailing symbols in a different string.
>
> Between them these conditions are both necessary and sufficient
> for lossless, "one-on-one" compression to occur.
>
> Explanations of these conditions follow [...] ''
>
>The document is located at http://www.alife.co.uk/securecompress/
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
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
