Cryptography-Digest Digest #191, Volume #10 Mon, 6 Sep 99 21:13:03 EDT
Contents:
Re: examples of twofish? ("Brian Gladman")
Re: n-ary Huffman Template Algorithm (Mok-Kong Shen)
Re: Random bits on a PC (Mok-Kong Shen)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: Pincodes ([EMAIL PROTECTED])
ARGUEMENT TOWARDS RANDOMNES & TIGHT COMPRESSION BY TERRY J. ALLEN
([EMAIL PROTECTED])
Re: Alleged NSA backdoor in Windows CryptoAPI YOU are correct in
([EMAIL PROTECTED])
Re: Pincodes/Call me @ 4055980428/TERRY ALLEN / I WILL HELP YOU!
([EMAIL PROTECTED])
Help with CryptoAPI: can not do the simplest thing!!! (Taavo Raykoff)
Re: Number of k-smooth numbers less than x (Bob Silverman)
Re: arguement against randomness ("Trevor Jackson, III")
Re: _NSAKey ("Microsoft Mail Server")
Re: NSA and MS windows ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: examples of twofish?
Date: Mon, 6 Sep 1999 22:09:50 +0100
Shaun Wilde <[EMAIL PROTECTED]> wrote in message
news:7r0m5r$[EMAIL PROTECTED]...
>
> Can anyone point me to code which has working examples of how to implement
> twofish?
>
> Also how do you go about generating keys? (from a passphrase/password?)
>
> I have used the MS Crypto API (shame on me) however I'd like to implement
> other block ciphers that haven't had MSs
> sticky paws all over.
>
> TIA
>
> --
> http://www.many-monkeys.freeserve.co.uk
>
>
Its on my page at:
http://www.seven77.demon.co.uk/cryptography_technology/Aes/
Brian Gladman
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.image.processing,sci.math,alt.comp.compression
Subject: Re: n-ary Huffman Template Algorithm
Date: Mon, 06 Sep 1999 23:44:28 +0200
Alex Vinokur wrote:
>
>
> The difference is that Template Huffman can use
> not only numerical weights.
> What is non-numerical weight?
> That must be defined by user (if his problem requires such weights).
I have tried a few times to ask you to show us the applications
of your supposedly generalized Huffman scheme, but yet of no avail.
Hence here once again:
Could you give us at least ONE single CONCRETE example of practical
applications of your scheme??? Writing a program is in my conviction
a different kind of undertaking than, say, doing abstract mathematics.
While in the latter one needs only to have a nice self-consistent
theory that offers opportunities of further development, in the
former there MUST be a justification of the work. It is never the
case (in fact it would be absurd) that a program awaits for its
applications and it is always the case that one has problems or
class of problems that await programs to be written to solve them.
If you can't give us an example of PRACTICAL applications, then
your program is useless. (I am sorry to say that. Please note that I
have nothing against you personally at all, but only against the way
of doing things.) From what you cited in a previous post concerning
the supposed possibility of comparing {cow, tulip} with {orange}
as a basis for defining the operator '>', I suspect (unless you can
concretely show the opposite) that "applications", if any, of your
program must be belonging to an imaginary world that is quite
different from the one we are living in. Note that I am not
asking you to explain the programming methodology (which your
most recent follow-up intends to illustrate). I am asking you
to show us a (practical, real-life) field where the application
of your program leads to substantial (practical) benefit.
If there are already publications of USERS of your program, then it
certainly suffices that a literature reference be given. Otherwise
please kindly give us a bit (concrete, down to the earth) details,
including the name of the particaular discipline in which the
program has been found to be useful, the nature of the problem or
problems being solved and above all the specific meaning
(semantics) of the operators '>' in those particular problem
settings. For without that no one can evaluate your new scheme any
better than those stuffs that are commonly presented in science
fictions. Let me close by repeating the question in my previous post
as a summary:
What does your encoding scheme achieve?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random bits on a PC
Date: Tue, 07 Sep 1999 00:57:22 +0200
Scott Nelson wrote:
>
> Let me elaborate on that - Some versions of Diehard have crash bugs.
> The known crash bugs were fixed in my C translation DiehardC.
> ( ftp://helsbreth.org/pub/helsbret/random/ )
> These bugs, while annoying, only occur with extremely biased data.
> So as long as Diehard doesn't crash, you can be reasonably
> confident of it's results. As far as I know, the status of the
> Fortran version of Diehard has not changed since the 1980's.
>
> Also, a few of the tests do not normalize perfectly -
> In theory, Each test in Diehard condenses a stream of
> random numbers into a single random number between 0 and 1.
> If the original stream really is random, then the condensed
> numbers will be evenly distributed. However, the
> imperfect normalization means some tests can produce
> results greater than 1 if the original data is biased enough.
> Annoying again, but also unlikely with any real test data.
It's very nice that you give the address for download of your software.
Once I tried to give that to someone of this group, but unfortunately
I made an error in my note book and hence didn't succeed. I believe
one should use your corrected version in C instead of the original
version in Fortran. I remember that one error of the origianl version
is that it takes input only up to a certain amount after which it
silently ignores what is above that amount. Another one is the
'endian' problem. (But it is quite a time since I met with these
errors. I can't give precise details of them now.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: point of a cipher
Date: Mon, 06 Sep 1999 23:59:06 GMT
In article <[EMAIL PROTECTED]>, Enterrottacher Andreas
<[EMAIL PROTECTED]> wrote:
>
>
>"SCOTT19U.ZIP_GUY" schrieb:
>>
>> In article <[EMAIL PROTECTED]>, Enterrottacher Andreas
> <[EMAIL PROTECTED]> wrote:
>> >"SCOTT19U.ZIP_GUY" schrieb:
>> >>
>> >> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>> >> >Dave Scott's compression idea, "one-to-one compression" is intended to
>> >> >totally frustrate a brute-force search. Normally, if a file is being
>> >> >compressed using Huffman compression, the resulting file will consist of
>> >> >any old number of bits. For transmission, it might be padded out to an
>> >> >even number of bytes: then, some indication of how many bits of padding
>> >> >are applied is needed.
>> >> >
>> >> >Usually, this means that there is a way to check an attempted decrypted
>> >> >file for validity; if we remove the bits claimed to be padding, do the
>> >> >remaining bits end on a Huffman symbol, or in the middle of one?
>> >> >
>> >> >Mr. Scott is trying to devise a method of Huffman compression which
>> >> >removes this (very weak) opportunity for the attacker to narrow down the
>> >> >space of possible keys. However, he is doing so at the price of
>> >> >introducing other forms of redundancy, which I think are worse.
>> >> >
>> >> >John Savard
>> >>
>> >> Ok John I bite. What are those worse form of redundancy that make it
>> >> worse.
>> >>
>> >> David A. Scott
>> >
>> >At least the output of the one-to-one-compression is compressable while
>> >encrypted text isn't: In a brute-force-attack one could try keys until
>> >he
>> >gets compressable data. The weak one-to-one-compression can be broken
>> >afterwards.
>> >
>> >Other attacks may be based on the fact that there exists redundancy
>> >without
>> >knowledge of the kind of redundancy.
>> >
>> >
>>
>> What are you talking about. I don't think your "one to one" is the
>> "one to one" I have been talking about these several days.
>
>As far as I understand your method you aren't using the huffman-table
>that
>would allow an optimum of compression. But this way you are creating a
>file
>that is larger than a huffman-compressed one, isn't it?
>
>
No you have it wrong I am using "HUFFAN COMPRESSION" if you
checked my site http://members.xoom.com/ecil/compress.htm you
would know that. What I have done is drop the headers that are added
when people try to account for the fact huffman compression can often
end not on a byte boundary. How can one end the huffman compression
so that it ends nicely on a byte boundary. I think I have the solution
to this problem If you care to look. I do it by requiring the "one to one"
property the easest form of the solution involves sometimes padding
the last byte sometimes leaving it alone and sometimes droping the
last byte. This is done in a way that every file can no be uniquely compressed
or decompressed since there are no headers. But I see you like many
wade in to attack based on zero knowledge.
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: [EMAIL PROTECTED]
Subject: Re: Pincodes
Date: Mon, 6 Sep 1999 18:23:59 -0500 (CDT)
Getting older is not for Sissies!
http://community.webtv.net/janfromtecuokla/FALLISCOMING
------------------------------
From: [EMAIL PROTECTED]
Subject: ARGUEMENT TOWARDS RANDOMNES & TIGHT COMPRESSION BY TERRY J. ALLEN
Date: Mon, 6 Sep 1999 18:17:25 -0500 (CDT)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Alleged NSA backdoor in Windows CryptoAPI YOU are correct in
Date: Mon, 6 Sep 1999 18:22:27 -0500 (CDT)
findings/ TERRY ALLEN ///OKLA CIPHER
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pincodes/Call me @ 4055980428/TERRY ALLEN / I WILL HELP YOU!
Date: Mon, 6 Sep 1999 18:25:10 -0500 (CDT)
------------------------------
From: Taavo Raykoff <[EMAIL PROTECTED]>
Crossposted-To:
microsoft.public.win32.programmer.networks,microsoft.public.win32.programmer,comp.os.ms-windows.programmer.win32
Subject: Help with CryptoAPI: can not do the simplest thing!!!
Date: Mon, 06 Sep 1999 20:39:13 -0400
I would like to do the _simplest_ thing with MS CryptoAPI, but after
much time looking at the docs, I can find *no* way of doing this, with
either the MS Base or MS Enhanced crypto providers.
I would like to do 3DES ECE3 encryption / decryption. The Enhanced
provider has this functionality. However, I have the DES keys and IV's
from outside the crypto API (i.e. as vectors in my program). So I need
to do 3DES using my own keys. The problem is that the CryptoAPI
functions take a handle to a key. There seem to be only several ways of
getting a key handle for 3DES in CryptoAPI:
- Generating random keys and putting them into your key store.
- Importing the keys from a key-blob, which is a CryptoAPI data struct.
The keys in the key-blob I understand must be enveloped using a PK
alogrithm, for example. At any rate, it sure seems that the only way to
get one of these key blobs is to have CryptoAPI produce it for you from
a key handle :-(.
- Attaching to keys already in your key store.
How hard is it to allow importing the raw keys into CryptoAPI? Help!!
If CryptoAPI can not do this, it is quite useless for any sort of
protocol encryption programs.
It seems impossible to do the most simple task with CryptoAPI. Given a
key vector and a data vector, encrypt the data with <RC2, RC4, DES,
whatever>. E.g. given a 56-bit key and a 64-bit vector, ecrypt with
DES. Should be possible for any crypto API!!!? How would you do this
with MS crypto API??
Any help would be much appreciated!! Send some sample code if you have
some, or any thoughts if you faced the same problem. I hope that it is
possible, but I am just not reading the doc the right way.
Thanks!!
tr.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Number of k-smooth numbers less than x
Date: Tue, 07 Sep 1999 00:23:28 GMT
In article <7r1l74$fcj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Would anyone here be able to send me the expression used for the number of
A slight correction. Your use of the term 'the' expression is incorrect
since it assumes there is only one. In fact, one can estimate
psi(k,x) in a number of ways. I give one (a theorem of Canfield,
Erdos, & Pomerance) below. One can also do it in terms of
Dickman's function (see Knuth vol 2) or using some more recent
and more accurate (but more complicated!) methods of Tenenbaum,
of Sorenson and several others.
> k-smooth numbers less than x (which is denoted \psi(k,x) in the literature I
> have read). I have the original journal reference but do not believe I can
> gain access to it in paper form.
>
psi(k,x)/x ~ u^(-u + o(1)) where u = log x/log k
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 06 Sep 1999 20:37:20 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: arguement against randomness
elarson wrote:
> If we are speaking within the context of this newsgroup, it is my
> understanding that there is no such thing as a random event when it comes to
> the bit processing on a computer. All functions of randomness, if allowed to
> run long enough, will show a pattern.
Statistically, the expected wait for a detectable pattern is less than
infinite. Another way of saying this is that if you wait long enough the
accumulated noise will pass into a region that makes it compressible (removal of
patterns). However, the pattern you find will not help you predict the future
behavior of the generator.
> Randomdess does occur in Nature. The
> question I have is how do you monitor a natural event in such a way that
> random numbers may be derived and processed on a computer?
Trivially the answer to your question is contained in the statement preceeding
it. If you _know_ randomness occurs in Nature you must have found a way to
monitor Nature and also a proof that the Natural Process contains nothing but
disorder. Quite an accomplishment.
More rationally, you can capture a natural process with appropriate hardware.
The only tough part of this is ensuring, as far as possible, that the capture
mechanism does not contaminate the signal it is sensing. Proving that negative
is theoretically impossible, but practically quite feasible.
>
>
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> >
> > > (pardon my ignorance....)
> > >
> > > Isn't one of the laws of thermaldynamics stating the spontaneuous
> creation of
> > > energy is impossible (or something to that effect)?
> > >
> > > Also wouldn't something truly random fall into this category?
> > >
> > > If I am dead wrong, please let me know.
> > >
> >
> > I think you are wrestling with the phrase "truly random". For our
> purposes this
> > means "completely unpredictable". This is equivalent to saying that the
> output
> > of the generation process has no use in predicting the future of that
> process.
> > The easiest way to get this condition is to measure a sequence of physical
> events
> > where the events are all independent. Proving that independence can be
> tough.
> > Quantum events such as beta decay are supposed to be completely
> unpredictable,
> > but we still do not understand entanglement completely. There's wiggle
> room for
> > a claim of complete interdepence of all particles that share a light cone
> (have
> > been "within reach of each other" at some point following the big bang).
> >
> > None of this has anything to do with the creation of energy. In fact
> there's
> > research that shows there is no fundamental lower limit on the amout of
> energy
> > needed to perform a calculation. There is a physical limit on the amount
> of
> > energy required to detect an event (see Plank's constant).
> >
------------------------------
From: "Microsoft Mail Server" <[EMAIL PROTECTED]>
Subject: Re: _NSAKey
Date: Mon, 6 Sep 1999 20:23:37 -0400
Crossposted-To: talk.politics.crypto
very true, selection is what it's all about. mates are indeed very
non-discriminating when it comes to whoever is about to succeed.
(ie: "why does johnny have red hair mommy? he's my brother isn't he?")
oh, these rosy colored hues make my life so blissfull indeed! ;-D
--
best regards,
hapticzemail at email.msn.com
remove first email, sorry i had to do this!!
------------------------------
Date: Mon, 06 Sep 1999 20:18:45 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Geoff Thorpe wrote:
> Hi there,
>
> Bruce Schneier wrote:
> [various speculations about the NSAKEY story]
>
> As Peter Gutmann pointed out quite some time ago (see
> http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms3.txt for some
> background), CryptoAPI has such gaping holes in it that to call it swiss
> cheese would be to bestow too much structural value to it. Cheese
> requires a lot more heat (or time) to melt.
>
> The CryptExportKey() API function, present in the base CSP providers (as
> used by Outlook, IE, etc etc), will happily export private keys. It also
> doesn't take a password. Perhaps one possible use of NSAKEY is that it
> somehow simplifies the process of planting executable (executing would
> be more accurate) code on the destination PC to call this function?
>
> The fact this API call is there is scary, but one still needs code to
> call it. If NSAKEY is as dark and sinister as some would like to
> speculate, then it could possibly provide away to exploit this deformity
> of CryptoAPI with minimal fuss and bother. Whether this key allows one
> to do such things, or whether it's there purely to sign CSPs, I do not
> know. I'd welcome anyone's thoughts (except David Scott) on this idea.
This is an interesting aspect of the situation. Given than an "extra" key
exists, whaty other functionality might it have? Any answer to that
question is going to be speculation at this point. However, we cannot rule
out the possibility that the NSAKEY has capabilities that the main
crypto-signing key does not.
What possible "other" uses could be made of the "extra" key that one would
not want to have managed by the main crypto key? It may be that there are
places where the capabilites of the secondary key exceed those of the main
key. This of course due to the fact that having the main key control the
extra capabilities would reveal those capabilites that should not be
revealed.
------------------------------
** 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
******************************
