Cryptography-Digest Digest #523, Volume #9 Mon, 10 May 99 17:13:03 EDT
Contents:
Re: Scramdisk: Security flaw in VxD? (Andy Jeffries)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (Mok-Kong Shen)
Re: IP encryption: stream cipher or block cipher? (Jim Gillogly)
Re: True Randomness & The Law Of Large Numbers ("Tony T. Warnock")
Simpliest "Overkill" Crypt Algo beyond "One Time Pad"? (Jay)
Re: Scramdisk: Security flaw in VxD? ("JB")
Re: Snuffle -- Source Code -- Where Is It? (James Kirkpatrick)
Re: How was this key constructed? (Medical Electronics Lab)
Re: public/private key authentication? (Medical Electronics Lab)
Time stamping ("Jean Marc Dieu")
Time stamping (complete) ("Jean Marc Dieu")
Shamir factoring result (John Kasdan)
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: How was this key constructed? (John Savard)
Re: Scramdisk: Security flaw in VxD? (Shaun)
Re: Crypto export limits ruled unconstitutional (Mike McCarty)
Re: public/private key authentication? (John Savard)
Re: Simpliest "Overkill" Crypt Algo beyond "One Time Pad"? (John Savard)
Re: Factoring breakthrough? (Mike McCarty)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Andy Jeffries)
Crossposted-To: alt.security.pgp,comp.security.misc
Subject: Re: Scramdisk: Security flaw in VxD?
Date: Mon, 10 May 1999 12:47:59 +0100
On 9 May 1999 15:42:03 -0500, Aman. eloquently stated...
> >In particular; it is possible to write an application that can interrogate the
> >driver for the (plaintext!) passwords it has cached.
>
> However I do intend to try plug this one and very quickly...
Aman,
(Obviously) if you can let me know if I need to make any changes to the
Delphi component when you have plugged this leak.
--
Andy Jeffries
Kwik-Rite Development
--See http://www.kwikrite.clara.net/ for Kwik-Crypt BETA - Self-restoring
archive maker for Windows 95/98/NT using Blowfish (FREEWARE)
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 10 May 1999 16:43:34 +0200
SCOTT19U.ZIP_GUY wrote:
>
> > > It handles the case of 8 0's. The tree is such that there is
> > > never a symbol made up of all zeros less than eight.
> >
> > (I suppose you wanted to say 'never a symbol containing 8 or more
> > zeros as prefix.)
>
> No I meant table is such that will be always one token (symbol) that
> has eight of more zeros. But the table will never have a symbol with
> less than 8 zeros.
I compressed a file consisting of symbols of one kind (all a's) with
your program. I looked at the result and found that the a's are
almost all coded with 1. Could you check this?
> We seem to get to this point over and over and over. I don't
> think you know what I am driving at. You can use your EOF scheme
> if you want but I don't think it would be secure for 2 reasons.
> YOur compressed files we be longer ( write code and we can test this).
> Second it lacks the property that I keep trying to explain. You
> don't have to agree but I had at least hoped you would understand
> what I state but I think you still don't see it. So here it is
> again
>
> THE SENDER
> the user compress file A to get file B ( buy what ever compression
> method). The user then takes file B and encrypts it to file C using
> a secret key known only to him and the reciver.
>
> THE RECIEVER
> gets file C uses shared secret key to decrypt to file B and
> then decompresses using matching routine of compression to
> get file A. (A may be ascii or may be binary just a file).
>
> THE SPOOKS
> They have all the programs used. They have file C but not the
> secret key. They try to guess a key they then decrpt using
> that wrong key. They get a file D. They notice that when they
> decompress file D to an E and then compress file E to F they
> notice that F and D are not the same. There fore they know
> that D is not your C which they can't see. It is my view
> (it need not be yours) that I would prefer and compress/decompression
> routines that always force F and D to be the same. Even when
> any possible wrong key is used for the decryption.
You said that the analyst has all the programs used. So in one case
according to you he has your compression program to first decompress
a certain file D to E and then compress (again using your program)
E to F. Since compression and decompression are inverse to each
other, D and F are the same (independent of whether in order
compress-decompress or decompress-compress), if the program is
correct. Why do you think that this should be different using
a compression program according to my scheme where an EOF is used
instead of appending terminating 0's?
M. K. Shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: IP encryption: stream cipher or block cipher?
Date: Mon, 10 May 1999 09:29:59 -0700
Cairus wrote:
> I want to encrypt the IP protocol and I would like to reinitialise
> the key (through an IV) at each IP packet.
> I would like to understand if block ciphers fit better than stream
> ciphers and why. The fact that IP is a connectionless protocol
> seems to be not significant, since a new IV is used for each
> packet.
Block ciphers were chosen for IPSec. It would be a good idea to
use the standard framework designed by that IESG working group, in
order to maintain interoperability and market credibility. A good
starting point with pointers to the RFCs and drafts is:
http://www.ietf.org/html.charters/ipsec-charter.html
There's nothing wrong with using a stream cipher for IP encryption,
as long as you use an appropriate IV for each packet, as you suggested.
The IPSec design allows you to substitute your own local "private"
cipher of any kind for the mandated and recommended (block) ciphers.
--
Jim Gillogly
Highday, 19 Thrimidge S.R. 1999, 16:21
12.19.6.3.4, 7 Kan 12 Uo, First Lord of Night
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 10 May 1999 10:54:04 -0600
Reply-To: [EMAIL PROTECTED]
"R. Knauer" wrote:
> Then why does Feller claim that it is fundamentally incorrect to infer
> the properties of random number generation from the time average of a
> single sequence?
>
Feller does not claim this. What he points out is that the model for the random walk
problem is different
for a set of several short walks than it is for a single long walk. Using the correct
model will give the
correct inference. Statistical intuition (collectively) has improved over the past
sixty years.
------------------------------
From: Jay <[EMAIL PROTECTED]>
Subject: Simpliest "Overkill" Crypt Algo beyond "One Time Pad"?
Date: Mon, 10 May 1999 09:53:48 -0700
It seems to me that it is trivial to explain
"overkill" crypt algorthms with huge keys.
Here is one for encrypting a block of bits:
Alternating phases of:
-- Bit Permutation (Bit 63 goes to Bit 13) Which
Permutation is selected by a set of independent
bits in the key.
-- Sub-block substitution: The block is broken
into sub-blocks, each sub-block is translated
by a independent substitution tables (In sub-block 3,
"5" is substituted with "2", "2" is changed to "7",etc).
Each sub-block translator is selected by independent key
bits.
Each phase has its own independent key bits (no key bits
are ever reused in any way.) Just increase the number of
phases, until you have reached overkill. For example,
with a 64 bit block, 4 bit subblocks and 20 phases, I
believe the key size would be about 10k bits.
Given random keys and sufficient # of phases, block size, etc.
I would be amazed that this incredibly stupid algorithm
could be broken.
Jay.
------------------------------
From: "JB" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.misc
Subject: Re: Scramdisk: Security flaw in VxD?
Date: 10 May 1999 12:08:10 -0500
Shaun <[EMAIL PROTECTED]> wrote in article
> The point is that the only way to stop this type of attack is
> to prevent any unauthorized program from running at all. This
> would of course defeat your "sniffer" program, since it wouldn't
> be authorised.
So how do you do that?
JB
------------------------------
From: James Kirkpatrick <[EMAIL PROTECTED]>
Subject: Re: Snuffle -- Source Code -- Where Is It?
Date: Mon, 10 May 1999 11:23:37 -0600
GivenRandy wrote:
>
> I think it's great, and right on target, with the recent Bernstein
> ruling. Does anyone know where to get the complete source
> code referenced in the case (I think it amounts to 4 pages or so)?
>
> Randy Given
> [EMAIL PROTECTED]
> http://members.aol.com/GivenRandy
> public key at http://members.aol.com/GivenRandy/pgpkey.asc
What I read in the paper is that in spite of the ruling, the
restraining order is still in effect until the government decides
whether they will appeal. So technically it should not publicly
available.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: How was this key constructed?
Date: Mon, 10 May 1999 12:32:13 -0500
Alex wrote:
> P.S. How can I overcome the little problem of having to write more than I want
> to in replies because there is a message that states that the reply cannot be
> sent because there is "more included text than new text" or something to that
> effect?
My browser does the same thing. What I do is write the word "filler"
and then copy it across 1 line. If the send doesn't work, I copy that
line and try to send 2 lines. If that doesn't work, I cut and paste
4 lines. Until it goes. sometimes I end up with 16 lines of "filler" :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: public/private key authentication?
Date: Mon, 10 May 1999 12:41:22 -0500
Phil Howard wrote:
>
> I'm still looking for a useable public/private key based authenticate-only
> (i.e. cannot do encryption) algorithm. So instead of:
> D(k',E(k,m)) -> m
> I would have something like
> A(k',m,S(k,m)) -> 1
> But I want to do it without it being just a variant use or protocol of an
> encryption algorithm. Does such a thing exist at all?
I guess I don't understand the point. But you could try to just
use a hash function. If the hash of the contatenation of data is
correct, you have verification. If you want some security, what's
wrong with a digital signiture? Just because somebody else thought
of it doesn't make it useless.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Jean Marc Dieu" <[EMAIL PROTECTED]>
Subject: Time stamping
Date: Mon, 10 May 1999 21:00:10 +0200
Does anyone know about using watermarking to certify a document (i.e:
certify it without encryption)?
JM
------------------------------
From: "Jean Marc Dieu" <[EMAIL PROTECTED]>
Subject: Time stamping (complete)
Date: Mon, 10 May 1999 21:03:30 +0200
Does anyone know about using watermarking to certify a document (i.e:
certify it without encryption)? For example, would it be possible to certify
a date (=time stamp) by watermarking?
JM
------------------------------
From: [EMAIL PROTECTED] (John Kasdan)
Subject: Shamir factoring result
Date: 10 May 1999 15:48:46 -0400
There was a recent thread on the New York Times story that Shamir was
going to present a several order of magnitude speed-up of factoring at
Eurocrypt, but (at least on my reader) it seems to have died out.
Does anyone know what he presented? And, even better, is there a web
reference to it? IMWTK.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Mon, 10 May 1999 19:54:45 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY wrote:
> >
>
> > > > It handles the case of 8 0's. The tree is such that there is
> > > > never a symbol made up of all zeros less than eight.
> > >
> > > (I suppose you wanted to say 'never a symbol containing 8 or more
> > > zeros as prefix.)
> >
> > No I meant table is such that will be always one token (symbol)
that
> > has eight of more zeros. But the table will never have a symbol with
> > less than 8 zeros.
>
> I compressed a file consisting of symbols of one kind (all a's) with
> your program. I looked at the result and found that the a's are
> almost all coded with 1. Could you check this?
>
Yes this is basically what it would do. However to check the routines
when you compresses that file "A" ( the A's ) and got file "B"( the one
full of binary zeros) If you uncompress file "B" to file "C" then
for the compression scheme to be reasonable file "A" must equal file "C"
However my compression has another property most do not have.
Take your file "A"(or any file) run the decompress on it to get
file "X" then compress file "X" to file "Z". Now file "Z" must
equal file "A". Try this with pkzip or whatever. This propery will
not hold.
> > We seem to get to this point over and over and over. I don't
> > think you know what I am driving at. You can use your EOF scheme
> > if you want but I don't think it would be secure for 2 reasons.
> > YOur compressed files we be longer ( write code and we can test
this).
> > Second it lacks the property that I keep trying to explain. You
> > don't have to agree but I had at least hoped you would understand
> > what I state but I think you still don't see it. So here it is
> > again
> >
> > THE SENDER
> > the user compress file A to get file B ( buy what ever compression
> > method). The user then takes file B and encrypts it to file C using
> > a secret key known only to him and the reciver.
> >
> > THE RECIEVER
> > gets file C uses shared secret key to decrypt to file B and
> > then decompresses using matching routine of compression to
> > get file A. (A may be ascii or may be binary just a file).
> >
> > THE SPOOKS
> > They have all the programs used. They have file C but not the
> > secret key. They try to guess a key they then decrpt using
> > that wrong key. They get a file D. They notice that when they
> > decompress file D to an E and then compress file E to F they
> > notice that F and D are not the same. There fore they know
> > that D is not your C which they can't see. It is my view
> > (it need not be yours) that I would prefer and
compress/decompression
> > routines that always force F and D to be the same. Even when
> > any possible wrong key is used for the decryption.
>
> You said that the analyst has all the programs used. So in one case
> according to you he has your compression program to first decompress
> a certain file D to E and then compress (again using your program)
> E to F. Since compression and decompression are inverse to each
> other, D and F are the same (independent of whether in order
> compress-decompress or decompress-compress), if the program is
> correct. Why do you think that this should be different using
> a compression program according to my scheme where an EOF is used
> instead of appending terminating 0's?
Please try it yourself your idea will not work. And I do not
always terminate the file by appending 0's. What happens at end
is rather complicated. You have to look at code or run the program
but if the "A" to "C" and "A" to "Z" do not match then there is
an error in my program.
>
> M. K. Shen
>
P.S. you can now get scott19u legally since someone posted
it for the free world. Due to some court desicsion.
--
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
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How was this key constructed?
Date: Mon, 10 May 1999 20:05:13 GMT
Alex <[EMAIL PROTECTED]> wrote, in part:
>P.S. How can I overcome the little problem of having to write more than I want
>to in replies because there is a message that states that the reply cannot be
>sent because there is "more included text than new text" or something to that
>effect?
Delete as much included text as you can. But if that leaves too much,
replace the little > symbols at the start with . or something your
mail program/server doesn't recognize to mark the quoted text.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: Shaun <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.misc
Subject: Re: Scramdisk: Security flaw in VxD?
Date: Mon, 10 May 1999 21:08:38 +0100
In article <01be9b07$8357d380$66016589@npd-murphy>, JB
<[EMAIL PROTECTED]> writes
>Shaun <[EMAIL PROTECTED]> wrote in article
>> The point is that the only way to stop this type of attack is
>> to prevent any unauthorized program from running at all. This
>> would of course defeat your "sniffer" program, since it wouldn't
>> be authorised.
>
>So how do you do that?
>
Not easily. It depends on the environment (e.g. home or office),
how many people are likely to have access to the machine, the
operating system, and so on. NT and Unix has much better controls
over what users (and hence processes started by the user) can
do than, say, Windows 95/98.
If the machine is reasonably physically secure i.e. strangers
can't just walk up to the machine, then you don't really have
a problem as long as you only install software from "trusted"
companies.
If you are in a more open environment you may consider restricting
access to CDs and floppies (by software or by physically removing
them). You would also want a secured screen saver to lock the
computer when the user isn't around, and some means for preventing
access to the hard disk when booting from a floppy (e.g. by
encrypting the whole disk).
If the machine is connected to a network, then appropriate
measures need to be taken to ensure remote access is not
possible.
As you can see, security is not just about encryption - the
whole environment needs to be considered. In the end you have
to weigh up risk against inconvenience and time.
Shaun
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Crypto export limits ruled unconstitutional
Date: 10 May 1999 19:51:57 GMT
If I read it correctly, it is the *intent*. If the intent is to
communicate algorithms to other people, then whether the program is
runnable is irrelevant. But if what it written is purely a program (ok,
it communicates with its maintainers, but that is not its primary
purpose) then I don't think the decision prohibits applying the
"munitions" argument.
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
)Mike McCarty wrote:
)>
)> Now, in a sense the regs were overturned, because they were all mixed up
)> and didn't attempt to distinguish "speach" from "computer programs". So
)> the regs AS WRITTEN were overturned. But if they go back and re-write
)> them carefully, then they CAN apply them. Just not to speach which
)> happens to be embodied in a computer langugage. But if I understand
)> correctly, PROGRAMS are not speach. Just that this particular case was
)> one where a guy was disseminating his ideas in the form of a program,
)> but was not actuallly writing a program to be run on a computer. Any
)> program written actually to be run, I believe, is still subject (when
)> the regs are rewritten).
)
)A programming language may be rather close (dependent, of course,
)on one's opinion) to natural language, e.g. COBOL. On the other
)hand, whether a piece of text is 'runnable' on a computer may be quite
)difficult to decide. I mean: If one changes a valid program in certain
)places in apparent and trivial ways so that it is syntactically
)incorrect and can't be compiled (but can be restored to the correct
)version by anyone with programming experience) is that piece of text
)'runnable' on a computer or not?
)
)M. K. Shen
)http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: public/private key authentication?
Date: Mon, 10 May 1999 20:25:35 GMT
Medical Electronics Lab <[EMAIL PROTECTED]> wrote, in part:
>Phil Howard wrote:
>> I'm still looking for a useable public/private key based authenticate-only
>> (i.e. cannot do encryption) algorithm. So instead of:
>> D(k',E(k,m)) -> m
>> I would have something like
>> A(k',m,S(k,m)) -> 1
>> But I want to do it without it being just a variant use or protocol of an
>> encryption algorithm. Does such a thing exist at all?
>I guess I don't understand the point. But you could try to just
>use a hash function. If the hash of the contatenation of data is
>correct, you have verification. If you want some security, what's
>wrong with a digital signiture? Just because somebody else thought
>of it doesn't make it useless.
Well, you might have noticed the ham callsign beside his signature.
Since it is strictly prohibited for encrypted data to be sent over
Amateur Radio, he is perhaps looking for a good authentication
algorithm that is fully compliant with the applicable regulations.
One source for help would be the people involved in the amateur
satellite OSCAR.
Note, however, that while it is illegal to send encrypted information,
it is not illegal to send authentication information - and the fact
that the algorithm used to generate it may have involved algorithms
usable for encryption is not of concern.
Thus, for example, if you accompanied a message with a hash of an
encrypted form of the message, you would not be sending anything that
could be decrypted to a secret message, so you would be in compliance.
(Of course, if you're still nervous, there _are_ such things as keyed
hash functions. The simplest thing to do is do an unkeyed hash of your
message concatenated with a key.)
But that requires a shared secret key between you and the recipient.
Can one use public keys in such a way that it is unambiguous that no
encrypted communications are taking place? Nothing - not even a random
key, used only for authentication purposes - is to be transmitted in
enciphered form at any stage of the protocol.
One can exchange messages with RSA signatures; since the signatures
can be verified against public keys, it is verifiable that no
encryption is taking place, even if RSA is an encryption algorithm.
So I think that the available alternatives are:
- Sign every authenticated message with RSA, or
- Use Diffie-Hellman to create a shared secret key (since neither
party controls what that key is, no encrypted communications can take
place) and use that shared secret key for keyed hashing.
There should be people to contact in the Amateur Radio community who
can verify that such simple procedures, although based on encryption
technology, are fully in compliance with FCC regulations.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Simpliest "Overkill" Crypt Algo beyond "One Time Pad"?
Date: Mon, 10 May 1999 20:11:09 GMT
Jay <[EMAIL PROTECTED]> wrote, in part:
>Given random keys and sufficient # of phases, block size, etc.
>I would be amazed that this incredibly stupid algorithm
>could be broken.
Actually, that's true enough. With enough phases, that would probably
be as good an algorithm as many block ciphers.
But it is also desirable to have algorithms that are easy to
implement, and that provide security quickly.
The bit transposition part - how to define that in terms of key bits
isn't answered, and moving individual bits around is not efficient.
The block cipher ICE uses a clever idea to move bits around to some
extent efficiently.
Choosing substitution tables: instead of having a lot of tables to
choose from, it might be better to have fewer tables, and add a step
where the key is XORed to the block.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Mike McCarty)
Subject: Re: Factoring breakthrough?
Date: 10 May 1999 20:01:33 GMT
In article <7h2i7i$ag7$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
)In article <[EMAIL PROTECTED]>,
) [EMAIL PROTECTED] (wtshaw) wrote:
)> In article <7h19ac$aaj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
)> Precison of an analog device depends largely on the observer, which might
)> be finer than the abilities of a digital instrument to quantify, or not.
)> Your first line is not necessarily true; it all depends on the
)> circumstances.
)
) I suspect that one of these, is always traded at the expense of
) the other in the finest level of detail, just as waves are traded
) for particles and vice versa in quantum mechanics leading to
) the idea of the generic wave-particle or quanta which tries to
) manage the dualism wholistically (not necessarily holistically
) since quantum field theory is still in its infancy).
Precision relates to repeatability of a result. Accuracy relates to the
"correctness" of the result.
In probabilistic terms, precision is something like the reciprocal of
dispersion measures, whereas accuracy relates to the location measures.
Any measurement has a variance. If the variance is low, the precision is
high. If the expectation of the measurement is very closely equal to the
actual value, then the accuracy is high.
I don't see any connection. For some distributions, the mean and
variance are independent.
I'm often amused by electronics types who think that they should use
V/F converters for good A/D conversion because they can, in principle,
have as many bits of precision as they like, simply by making the
counter which measures the frequency have more bits. I mean, I've seen
in literature stated that one can get 13 bits of precision out of a
certain V/F (synchronous, crystal driven) by just using a long enough
counter. They didn't mention that when one computes the temperature
drift, that could be achieved only by
characterizing the parts on a piece by piece basis
maintaining temperature within a half a degree C or so
Anyway, this is probably getting pretty far off topic.
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
------------------------------
** 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
******************************
