Cryptography-Digest Digest #574, Volume #10 Tue, 16 Nov 99 11:13:03 EST
Contents:
Re: High Speed (1GBit/s) 3DES Processor (Justin)
Re: more about the random number generator (Tom St Denis)
Re: more about the random number generator (Tom St Denis)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: S/MIME plug-in for Eudora? Strong Encryption (Lincoln Yeoh)
Re: International crypto restrictions (Peter)
Re: International crypto restrictions (Peter)
Re:SCOTT16U SOLUTION ON THE WEB (Tom St Denis)
Re:SCOTT16U SOLUTION ON THE WEB (Tom St Denis)
Re:SCOTT16U SOLUTION ON THE WEB (Tom St Denis)
Re:SCOTT16U SOLUTION ON THE WEB (Tom St Denis)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (john baez)
Re: intelligent brute force? (Keith A Monahan)
Re: High Speed (1GBit/s) 3DES Processor ("Tim Wood")
Re: Proposal: Inexpensive Method of "True Random Data" Generation
----------------------------------------------------------------------------
From: Justin <[EMAIL PROTECTED]>
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Tue, 16 Nov 1999 04:27:27 -0500
On 14 Nov 1999 [EMAIL PROTECTED] wrote:
> We have developed a prototype Encryption system which runs 3DES at 1
> GBits/sec (this is not just processing but with real IO at 1 GBit/sec).
> Are there any commercial applications for this type of technology? It
> would be interesting to get some feedback. Possibly bulk encryption with
> ATM switches etc? It should also be possible to multiplex multiple high
> speed inputs into our system.
How about encryption for backbone links? Keeps people from being able to
go out on a country road in Kansas and splice into an OC48.
Justin
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Tue, 16 Nov 1999 11:47:58 GMT
In article <80qrm0$bb1$[EMAIL PROTECTED]>,
William Rowden <[EMAIL PROTECTED]> wrote:
> The *cryptographic* security of a PRNG is generally described in
> complexity-theoretic terms. My first question is therefore "What's
the
> algorithm?" Security relies on the presumed intractability of an
> underlying number-theoretic problem.
>
> Nevertheless, statistical tests (e.g., FIPS 140-1) can be used in
> security applications.
Truly random generators should not have any theoretic explanation
though. I mean I can explain why this rng works, but not predict the
output without knowing all the nicks and nannies of the win32 task
scheduler.
>
> I assume these are the program's results with the bitstream option.
ent -b test.bin
Yup.
> > Entropy = 1.000000 bits per bit.
>
> That's wonderful.
I dunno if it's a simple order-0 predictor or something. But it does
indicate when files have low entropy [such as text] which at least can
show good from bad... or better from bad.
> > Optimum compression would reduce the size of this 417792 bit file
by 0
> > percent.
>
> Since this compression is based upon a reading frame of one bit, it
> doesn't mean much at all. You'd get better compression information by
> not using the bitstream option, or by attempting to compress the file.
> (Look out! The compression/randomness thread could begin again.)
The file will not compress with deflate.
> > Arithmetic mean value of data bits is 0.5003 (0.5 = random).
>
> With 208771 zeros and 209021 ones, it passes the monobit or frequency
> test at a higher confidence level than my chi-square table shows (and
> good enough for FIPS 140-1).
BTW where can I get FIPS 140-1?
> > Chi square distribution for 417792 samples is 0.14, and randomly
> > would exceed this value 50.00 percent of the times.
>
> Oops. Maybe it's 208776 zeros and 20916 ones. The table option
should
> show this.
>
> > Serial correlation coefficient is 0.001254 (totally uncorrelated =
> > 0.0).
>
> This looks good. I assume this is equivalent to a two-bit test,
though
> I don't know how to calculate one statistic from the other.
>
> Since PRNGs have a period, an autocorrelation test for shifts greater
> than one (which should be the serial correlation above) would be
useful.
>
> > Is this good or bad? From what I read at the site this is really
good
> > for a first pass at it...
>
> I think it's a good first pass. Since it's an easy option to change,
> I'd also try a poker test with m = 8, using the 8-bit byte option of
the
> program.
I would have to make a huge file for diehard to use though, and this
generator only outputs about 4 to 6 cps.... [32 to 48 bits per second].
> What does a runs test show? You could calculate the number of blocks
of
> ones or gaps of zeros of various lengths, e.g., 1 to 6 (you're a C
> programmer, after all). What's the longest run in the file?
I will try a run test on a 1MB file ...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Tue, 16 Nov 1999 11:42:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> These sorts of tests can't really be "good" only "not bad."
> It's "not bad."
>
> The issue I have with the RNG in question isn't "does it
> perform well on some systems." It's "how well it works
> on a variety of systems, and can you predict under what
> conditions (if any) it will fail." I.e. If there are no
> other tasks running, it's fails rather spectacularly.
> Are there any other, more realistic, conditions which
> would cause it to fail? Hi or low speed computers,
> running in virtual mode, if a task consumes huge amounts
> of processor time, etc.
For my purposes it can't fail because of inactivity. I can't imagine
people sending messages/files with my program [which we all know the
title of] without interacting with the computer. Also in windows there
are many tasks that can interrupt. I can leave the RNG go with only my
email+winamp going and it performs well.
I am trying to make a 1MB file todo a runs test on and also any other
test anyone might suggest.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (john baez)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 14 Nov 1999 12:48:20 -0800
In article <[EMAIL PROTECTED]>, Coen Visser <[EMAIL PROTECTED]> wrote:
>I only know of
>Kolmogorov complexity in the context of infinite sets of
>strings.
Hey, now you're saying it again! So I'll repeat my remark:
the Kolmogorov complexity of a single string is well-defined
once you fix a language: it's the length of the shortest
program that prints out that string. (There are probably
other definitions floating around too, but anyway, this is
a definition that applies to a single finite-length string.)
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Crossposted-To:
comp.security.misc,comp.security.pgp.tech,alt.security.pgp,comp.mail.eudora.ms-windows
Subject: Re: S/MIME plug-in for Eudora? Strong Encryption
Date: Tue, 16 Nov 1999 12:29:51 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 13 Nov 1999 18:31:09 -0500, Adam Kippes <[EMAIL PROTECTED]>
wrote:
>In <[EMAIL PROTECTED]>, amateur wrote:
>
>> Hmm, I thought that there was an option that allowed the PGP key to expire but
>> I can't seem to find
>> it......
>
>If you do find such an option, please post. I would like to be able to do
>that. Or a least get one off of the server; not exactly the same thing, I
>realize, but I'll be satisfied.
When you create the key, choose the expiry date.
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: Peter <[EMAIL PROTECTED]>
Subject: Re: International crypto restrictions
Date: Tue, 16 Nov 1999 04:28:14 -0800
I have been trying to follow this discussion with regards the use of
BLOWFISH internationally and still find myself a little confused after
reading several newsgroups. Please excuse my ignorance if this has been
raised many times before or is a little basic for this group..
Is it correct to say that the use of blowfish - limited to say 40bit
keys - built within an application (for encrypting data files) outside
of the USA and "written" by a non-us citizen is still subject to the US
export laws ?. Does blowfish not fit within the definition of 56BIT DES
or equivalent algorithms ?
Is there a clear definition on the use of blowfish internationally
(i.e. has somebody recently requested a export licence (over the 32bit
mentioned) and been accepted/rejected.
Are there any problems if the application will never be "imported" into
the US (in fact have very little to do with the US).
Any help would be appreciated before I begin to program.
Peter
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Peter <[EMAIL PROTECTED]>
Subject: Re: International crypto restrictions
Date: Tue, 16 Nov 1999 04:24:42 -0800
I have been trying to follow this discussion with regards the use of
BLOWFISH internationally and still find myself a little confused after
reading several newsgroups. Please excuse my ignorance if this has been
raised many times before or is a subject to basic for this group.
Is it correct to say that the use of blowfish - limited to say 40bit
keys - built within an application (for encrypting data files) outside
of the USA and "written" by a non-us citizen is still subject to the US
export laws ?. Does blowfish not fit within the definition of 56BIT DES
or equivalent algorithms which are now exportable ?
Is there a clear definition on the use of blowfish internationally
(i.e. has somebody recently requested a export licence (over the 32bit
mentioned) and been accepted/rejected.
Are there any problems if the application will never be "imported" into
the US (in fact have very little to do with the US).
Any help would be appreciated before I begin to program.
Peter
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Tue, 16 Nov 1999 12:43:17 GMT
In article <80p1ff$21vc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I don't use them. I use "wrapped PCBC" but most people have no
idea
> how to do it. The crypto gods do there best to conufse people about
secure
> chaiing when it comes to encrypting files.
We understand your method, and find it to be totally useless. It adds
no real security to the system. If you can't figure this out, at least
tell me why don't you encrypt the file 2n + 1 [n is large] times with
2n + 1 different keys. If you can figure that out you are set.
> You don't know if IDEA CAST and the such have with stood the
> test of time and analysis. You may knwo that there are no widely
published
> attackes that are readily available. But it is foolish to think
otherwise.
There are attacks against BOTH ciphers out in the public. These
attacks do not work [generally] against the entire cipher [all the
rounds, with whitening, etc...] but do outline why it's hard to break
the cipher.
> Obviosuly you don't understand the problem and the crypto gods
have done
> a great job giving you misinformation. It works on all block cipher
that have
> no internal feedback to change state from one block to the next.
But again only the holder of the symmetric key will ever realize the
bytes have changed.
> it other than Wagner repeated comments on how it would obviously fail
> his Slide Attack. Which he repeatedly stated over and over. But when
> push came to shove he was full of shit.
He merely proposed it may work. I haven't heard him talk about the
slide attack for about 3 months now. Maybe you should let it go? [btw
his attack does work against other [modified] ciphers and does present
another good methodlogy for attacking ciphers]].
> The chaining method is not isolated and can be used any block
cipher
> method. However it requires at least three passed through the
encyption
> system. However it gives you and "all or nothing" type of encryption
and
> you can encrypt files without changing the file size. I think people
should
> be very careful about any crypto system that can't encrypt files with
out
> first forceinf the file to be in some unnatural multiply of bytes.
Um, if you use a block cipher, you will most likely have padding bytes
at the end. You cannot get around this. IF you have 1 byte of info,
and a 8 byte block, you can't simply store 1 byte of ciphertext. Your
thinking is seriously flawed.
I think maybe you should accept the fact that others may have good
ideas as well. It's nice to see you are playing with crypto and all,
but seriously you have to think a little more open minded. You never
respond to questions about your cipher [such as why the size of the
sboxes, or num of passes, etc...] and just try to flame people.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Tue, 16 Nov 1999 12:35:42 GMT
> Take your favortie AES code and your favortie 3 letter chaining
method
> encrypt a large file. Then reverse the file byte for byte and take
> another AES method or the same of lazy and encrypt the file again.
>
> Then take a hex editor and change a byte in the middle to file.
> Then do the reverse of above to decrypt the mess.
> know to a byte cmpare with original file. Only a few bytes
> in the area of the changed byte are corruptted. This is because
> the ecnryption is only a localized thing with these piss poor
> chaining methods. To the stupid the crypto gods call this
> erro recovery. But to the NSA it is a toe hold into breaking
> your code since only small fragments need to be analyzed
> in trying to break it.
>
> This should be obvious to anyone.
The problem is that only the person with the key will actually realize
there are bytes changed. If you don't have the key you can't simply
magically decrypt the file.
So although you are correct that avalanche does not go back and
forwards this is not a security threat. A security threat is something
were an intruder can fake messages and/or read them.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Tue, 16 Nov 1999 12:46:56 GMT
In article <80pk42$1nae$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> obviously you have not tried what I said since your anwser makes
little sense
> the work I did was based on CBC which does have the weaknesses I
describled.
> Since you don't seem to know this I assume you have never got off
your ass to
> test this.
Obviously you need a demo
agaqaaayqaBf4JSOvlcYsrO1LlP7eaaaagaaaae{kWTeYWm9{kbnHx9wlT2vuVokY
{0AzGJM2n0g5LGEV
tell me which byte of that message is invalid. I used the 'weak'
Twofish and 'weak' CBC mode [as you call them].
[P.S Yes I know we are not suppose to send ciphertext here, but this is
a graphic illustration of my point.]
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re:SCOTT16U SOLUTION ON THE WEB
Date: Tue, 16 Nov 1999 12:49:32 GMT
In article <[EMAIL PROTECTED]>,
Anonymous User <[EMAIL PROTECTED]> wrote:
> Hey cool it. Dont assume that everyone has rushed to read your
site...I
> for one has not...
>
> So you are saying you have tested all aes candidates and all known
block
> ciphers, 3DES, IDEA , CAST, Blowfish...etc in CBC mode and you have
> demonstrated this weekness in all these ciphers????
>
> If that is what you are saying, then you are turning the Crypto world
> upside down....well done...you deserve a medal. But surely the answer
to
> this problem according to you is to use 1-1 compression, then the
problem
> disappears....
Actually he is perfectly correct in saying that CBC/CFB type chaining
modes do not cause avalanche in BOTH directions.
He is however not correct in saying this is a weakness [if you want a
demo read one my earlier posts to this thread where I included a line
of ciphertext from my Peekboo].
So let's not flame him, he is afterall quasi-correct.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (john baez)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 14 Nov 1999 12:31:42 -0800
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
>Coen Visser wrote:
>> Again I am not claiming that the K-complexity definition of
>> randomness is *the* standard definition. As I am not claiming
>> that the idea of a random process is bad. What I am claiming is that
>> K-randomness is a *very* useful definition. It is very close to the
>> mathematical definition of randomness (even for finite strings).
>> And you can put the fact that there are random strings to good use
>> in all kinds of situations.
>There is a fundamental linguistic issue that you have failed to address. The
>term "a random string" is actually shorthand for the phrase "a randomly
>selected string".
In the theory of Kolmogorov-Chaitin complexity, one can legitimately speak
of a *single string* being random, or not random. Of course this is not
true with some other definitions of randomness. But Coen Visser made it
clear above that he's using the Kolmogorov-Chaitin definition.
>You can call a tail a leg, but a dog still has only four.
Four tails, eh? I'd like to see your dog. :-)
>We have already
>experienced the confusion this overloading of the term random creates. Since,
>contrary to your statement above, the definitions are not at all close,
>treating them as substitutes for each other is a great way to make mistakes.
Indeed, nobody in his right mind would want to mix up these various
definitions of randomness. Unfortunately it's too late to strike any
of these definitions from the textbooks, so we just have to be clear
about which one we're using at any given moment.
------------------------------
From: [EMAIL PROTECTED] (john baez)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 14 Nov 1999 12:44:28 -0800
In article <80igm9$n7b$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In conclusion, there is no meaning in talking
>about whether a given string by itself is random,
>in either the sense of Shannon's entropy or
>Kolmogorov complexity.
As you note, there *is* a meaning to the randomness of
a single string if you use Kolmogorov complexity *and* fix a
representation language.
Language-independence has theoretical advantages, but it comes
at the price of turning entropy from an exact number into
a number "plus a constant of order 1", which prevents you
from talking about the entropy of any given string. It's
a bit like in computational complexity when people say
"this algorithm is linear-time" - that's nice as far as
it goes, but if the time were actually n + 10^10000,
it would still be a crappy algorithm.
------------------------------
From: [EMAIL PROTECTED] (john baez)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 14 Nov 1999 12:51:00 -0800
In article <80h6lq$s9q$[EMAIL PROTECTED]>,
Patrick Juola <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Coen Visser <[EMAIL PROTECTED]> wrote:
>>No, most strings are hardly compressible. This can be shown as follows:
>>Say you want to compress binary strings of length N. There are 2^N such
>>strings.
>This is a false assumption, in context. Specifically, there are 2^N
>*possible* strings, each of which occurs in some probability distribution.
You're really talking past each other, since Visser is talking about
Kolmogorov-Chaitin compressibility, which has nothing to do with probability
distributions... while Juola is talking about some other notion based
on probability distributions.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: intelligent brute force?
Date: 16 Nov 1999 13:57:26 GMT
JPeschel ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] (CoyoteRed) writes in part:
: >If you have this much, do you have access to his machine? Can you get
: >a key logger installed onto his machine? If you are on a LAN you can
: >monitor the log and when you have the key stroke sequence then you can
: >erase the logger and all traces that it was there.
: I believe Keith is still trying to crack one of his own forgotten passwords.
Right you are JP! And I will succeed given enough time and effort.
The problem is trying to fit breaking my own pw in between work & school &
new house & etc etc. You know, one typically designs a passphrase to be
secure from adversaries. Me, I designed one to be secure from EVERYONE,
including myself. I don't think my data has ever been THIS secure!
BTW, I do now have a working brute-force(or to be PC, an intelligent
cryptanalysis engine which does not search out EVERY key, but takes patterns)
program. It works OK despite its speed. I also have my machines at home
on a UPS system now, so flickers in the power don't make me restart the
days work.
I am making progress, but I have to develop a coordinated game plan in
order to make my attacks more effective. Currently, I'm in the process of
creating LARGE sets of test passphrases to feed into the BF'er. This is
the reasoning behind my recent posts.
Keith
P.S. And just so you know, the data is no longer important. This is now
a mission. :)
: Joe
: __________________________________________
: Joe Peschel
: D.O.E. SysWorks
: http://members.aol.com/jpeschel/index.htm
: __________________________________________
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Tue, 16 Nov 1999 14:08:19 -0600
Paul Koning wrote in message <[EMAIL PROTECTED]>...
>Tim Wood wrote:
>>
>> [EMAIL PROTECTED] wrote in message
>> <[EMAIL PROTECTED]>...
>> >We have developed a prototype Encryption system which runs 3DES at 1
>> >GBits/sec (this is not just processing but with real IO at 1 GBit/sec).
>> >Are there any commercial applications for this type of technology?
>>
>> Isn't it usual to find out if there are commercial applications before
you
>> develop something?
>> Unless of course you just do it as a hobby ;-)
>
>Or academic, or a researchy type person. Or you had an application
>but it evaporated and you're looking for others. Or you know of one
>niche but suspect there might be 5 more outside your field....
Good point well made ;-)
> paul
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 16 Nov 99 14:22:22 GMT
Trevor Jackson, III ([EMAIL PROTECTED]) wrote:
: This verges on the claim that RNG outputs should be filtered for compressibility
:prior to use.
: The definition of incompressible as random contributes to this suggestion.
And of course any filtering does make them slightly compressible, since
random-looking sequences are a subset of all sequences. Yet using an
all-zero one-time pad is something people are unlikely to do in reality.
This is an interesting philosophical problem.
: How would you address the following issue? An incompressible string used once is no
:more
: compressible than prior to use. But an unpredictable sequence (shorthand for a
:sequence generated
: stochastically) is no longer unpredictable after use.
The following quote gives part of the answer: if one uses the same
one-time pad used twice, since the *plaintext* is compressible, the first
message can be used to give the pad for the second in terms of the
difference between them...
: > 14159 26535 89793... compresses to "the decimal part of pi", but any
: > sequence of numbers can compress to "the contents of the one-time-pad that
: > I secretly photographed"...
: By this definition all [sufficiently long] strings, even infinite ones, are
:compressible. What
: ever mechanism specifies/describes/locates the string is a compressed reference to
:the string
Not "are compressible", but "are potentially compressible". A description
of a string as "the contents of the third one-time-pad in my safe" is
useless if you can't open that safe.
: > There _is_ a sense in which true incompressibility means "as good as
: > random", since it does mean haphazard, not generated by a simple rule.
: What is the disctinction between "true" incompressibility and (I suppose) "pseudo"
: incompressibility? Are references to sequences pseudo-compressions?
No, I meant "true incompressibility" in the opposite sense; incompressible
even when compressions making use of side information were allowed. As
distinct from mere _intrinsic_ incompressibility, which is the more
well-behaved mathematical concept.
: Is there an instance of a truly incompressible sequence?
One that is genuinely random, and drawn from a uniform distribution.
Anything else _might_ be truly incompressible, but one can never be sure.
John Savard
------------------------------
** 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
******************************
