Cryptography-Digest Digest #245, Volume #10 Thu, 16 Sep 99 09:13:03 EDT
Contents:
peekboo needs help :( (Tom St Denis)
Re: one time pad ("Douglas A. Gwyn")
Re: Ritter's paper ("Douglas A. Gwyn")
Re: one time pad ("Douglas A. Gwyn")
Re: Mystery inc. (Beale cyphers) ("Douglas A. Gwyn")
Re: SCOTT19U.ZIP_GUY/Questions Please ("Douglas A. Gwyn")
Re: SCOTT19U.ZIP_GUY/Questions Please ("Douglas A. Gwyn")
Re: Sources of randomness (Paul Crowley)
Re: Can you believe this?? (Paul Crowley)
Re: Random and pseudo-random numbers ("William Whyte")
Re: Beale (was: Mystery inc.) (Richard Herring)
Re: Can you believe this?? (Michael =?iso-8859-1?Q?=D8stergaard?= Pedersen)
Re: SCOTT19U.ZIP_GUY/Questions Please (SCOTT19U.ZIP_GUY)
Re: NSA and MS windows (fungus)
Re: SCOTT19U.ZIP_GUY/Questions Please (SCOTT19U.ZIP_GUY)
RC4-40 Cracking (yoni)
Re: NSA and MS windows (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: peekboo needs help :(
Date: Thu, 16 Sep 1999 05:07:46 GMT
Yup, my comp was down for a bit and I am behind in some work. I need help in
the following areas
1) Nice Manual, either in .txt or .wri format
2) Beta testers
3) Math/hackers to attack the system
4) Bug finder/fixers
There are two big bugs, first I can't read/write the large nums (but the
public key math works now :)) and the keyschedule in serpent apears to be
inert... :(
Now you are thinking why do I want to help you? Well think of this...
1) Peekboo is free and includes source, it's not a closed/homebrew concoction
2) It's compact (non portable) and reasonably efficient
3) It supports RC5/Cast/Blowfish/RC4 and Twofish (good varierty)
4) I am adding public key crypto to it to facialitate key sharing
5) It's really simple to use, even newbies like the PeekBoo v1.2 more then
PGP even though they have a hard time sharing keys.
Now #5 sounds bad but's its true. Some people admit to liking it despite the
lack of key exchange. I plan to change that. Currently the beta can
make/use keys but not share/save/load them... (arrg!). If I/we can get it
working a free good cryptosystem (that is extremely easy) will be
available... :)
6) It's small... people like fast small programs. Peekboo is still about 40kb
... :)
If you have any questions or want to see the current source just email me at
[EMAIL PROTECTED]
The v1.3 binaries are at
http://www.cell2000.net/security/peekboo/
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 16 Sep 1999 06:36:25 GMT
[EMAIL PROTECTED] wrote:
> I am currently taking a security class and my
> professor has asked us to break two messages
> encrypted with the same one time pad.
Part 1: Determine the relative alignment (slide) via a kappa test.
Part 2: Difference the ciphertexts to produce the difference of the
plaintexts. ("Difference" might be XOR, in your case.)
Part 3: Drag probable words and phrases along the diff.PT, at each
alignment differencing, to see when the result is PT.
Part 4: Extend the result PT and consider that a complementary
probable word, continuing step 3 at the current alignment
to extend the original p.w., and work back-and-forth as
far as you can extend (try lots of guesses).
Part-2 and -3 differencing can be combined into a single operation.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ritter's paper
Date: Thu, 16 Sep 1999 06:14:21 GMT
"Trevor Jackson, III" wrote:
> There are several gaps here. The grlaring one is that we have no
> ciphers (excluding OTP) that are secure. We have only ciphers that
> are not secure or whose security we are unable to determine. Note
> that last: it does not mean we "think" they are secure. It means we
> do not know.
(a) OTP is clearly not secure *in practice*. In a simplified
theoretical framework, it has certain mathematical properties
that are usually summarized by "is secure", but the exact
formulation is important.
(b) Other cipher systems have been described in the open literature
under the appellation "provably secure". Again, one has to examine
the details to know exactly what that means.
(c) Shannon showed one way in which degree of security could be
quantified, in his description of unicity point. An elaboration
of this idea can be used to prove certain bounds on insecurity
for systems on the proper side of the unicity point. (These
might not correspond to systems in actual use, but it shows that
there are non-OTP theoretical counterexamples to your claim.)
(d) By "we" you must mean "Trevor Jackson and people I know about."
How do you know that point (c), or some other approach, hasn't been
developed into a full, practical theory by people you *don't* know
about?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one time pad
Date: Thu, 16 Sep 1999 06:39:21 GMT
Roger Carbol wrote:
> I'd check for collisions. (I'm probably not using the word
> "collisions" correctly within this context.) What I mean is
> that I'd look for the same value in the same location in both
> messages.
> The most common should correspond to "e" or whatever is the
> most common symbol in the plaintext messages. The next common
> is the next common, etc etc.
> You could also look for two-letter combinations (digraphs?) like
> "th".
That doesn't get you very far. Mainly, it has indirect application
via the kappa test, merely to align the two ciphertexts so that they
can then be successfully attacked via differencing.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Mystery inc. (Beale cyphers)
Date: Thu, 16 Sep 1999 06:20:15 GMT
sha99y00000 wrote:
> "Douglas A. Gwyn" wrote:
> > sha99y00000 wrote:
> > >> > ... Communications of the ACM, January 1971, ...
> > > .... I just thought that these papers would
> > > have been freely on the net for a wider feedback.
> > So, have *you* volunteered to create accurate on-line versions of
> > these documents? Very few publications have on-line versions
> > dating back more than a few years. It takes time and money to
> > accomplish that, if it wasn't planned from the start.
> Your comments have no merit.
Sure they do -- they point out that you are cursing the
darkness. I explained why the candle hasn't been lit by
others.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Date: Thu, 16 Sep 1999 07:00:49 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Mr BS in his book (which I don't recomend I read it in a library)
> page 226 2nd edition says theat error handling should be seperate
> from encryption look at bottom of page. I don't trust his advice ...
I'm currently working in this area, and I can assure you that
there are very real advantages to applying error recovery as
a "wrapper" closer to the communication channel than is the
encryption. Mainly, it allows reception errors (which are
*quite common* in modern radio systems) to be detected and
corrected with *no knowledge of the encryption*; so, for example,
a relay station can clean up a signal and retransmit it without
having to be made privy to the crypto key (if any). Also, the
same error-correction scheme can be readily used with *any*
traffic, encrypted with any system. Cell phones are examples of
devices that rely on good error correction technology to allow
them to function *with reduced transmission power requirements*
(thus increased time between battery recharges) compared to
uncoded transmission. Deep-space transmission is another
excellent example of the power of error correction, independent
of any encryption scheme that may also be happening.
Now, there are several error-correction schemes that have
parameters that could be made to vary depending on part of a
crypto key. If enough bits were used, an interceptor would
not be able to ungarble the noisy reception and would thus
stand no chance at all of cryptanalyzing the content.
However, it seems evident that those same key bits would
contribute even more to security if they were part of the
real encryption key and not used in generating the error-control
code.
Along these lines, there could be applications where *routing*
etc. needs to be secured; i.e. the T/A needs to be thwarted as
well as the C/A, or perhaps hacker protection is necessary.
Such applications need some "message header" encryption in
their outer layer, even if they also use error-control coding.
The content could still be encrypted using another system.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Date: Thu, 16 Sep 1999 06:43:55 GMT
tunafish wrote:
> What they seem to have done is deliberaltely weeken these algorithms
> by asking those who submitted to make certain modification to the
> code...
Oh, good grief! That's the old conspiracy theory resurrected
from the early DES debate. What EVIDENCE do you have that this
has occurred?
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Sources of randomness
Date: 16 Sep 1999 08:55:10 +0100
[EMAIL PROTECTED] (Scott Nelson) writes:
> There's a tradeoff here between wasting computing power
> and source bits. Both resources are remarkably cheap,
> and if you can, then waste them both. In my experience tough,
> source bits have always been "cheaper." YMMV.
I think your experience is unusual here. Especially bearing in mind
that Panama is ludicrously, blindingly fast, especially on newer
processors. Are you sure your LFSR approach is faster at all?
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: 16 Sep 1999 09:02:02 +0100
Paul Koning <[EMAIL PROTECTED]> writes:
> The ONLY difference between the two generators is that /dev/random
> limits the number of output bits to <= the estimated amount of
> input entropy, while /dev/urandom does not. Bruce Scheier et al. have
> argued (in the Yarrow paper) that this is unnecessary, given that
> the PRNG is using a cryptographically strong mixing function (as
> /dev/urandom does).
Which suggests that /dev/urandom should make sure to produce *no
output at all* until the input entropy crosses some threshhold (like,
say, 128 bits). Does anyone know if that's what it does?
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "William Whyte" <[EMAIL PROTECTED]>
Subject: Re: Random and pseudo-random numbers
Date: Thu, 16 Sep 1999 10:35:06 +0100
>> Could someone tell what is the rough demand of random bits (per
>> unit of time) for generating session keys in certain typical
>> environments, e.g. for a small office, for a branch of a bank,
>> etc.? I like to know the order of magnitude of such values.
>
>Using current practices, I have tried to estimate an upper bound on RNG
>demands. Assume that a bank/brokerage has a server cluster handling 600 SSL
>connections per second (52 million/day). They would likely use an IPivot
>CD8000 SSL Accelerator (or something like it). Assume further that every
>connection initiates a session, and thus requires new keys. Assume further
>that the most secure algorithm (3-DES) is used for all of them, requiring
>168-bit keys. That yields 100,000 bits/second.
Maybe so, but it's worth drawing the distinction between the number
of bits of (pseudo-) random output used and the number of bits of
entropy needed. Given that brute-forcing a triple DES key requires
2^112 effort, brute-forcing 600 triple DES keys requires 600 * 2^112
effort. So to run our (P)RNG for one second, we want enough initial
entropy to make brute-forcing the PRNG (by searching all the initial
states) less profitable than brute-forcing all the keys individually.
To run for one second, we need 112 + log2(600) bits of true entropy,
or about 122 bits. If we want to run the PRNG for five minutes before
reseeding, we need to supply 112 + log2(600 * 300) bits every time we
reseed, which is about 132 bits.
132 bits is still a fair amount of true entropy. But it's considerably
less than the 30,000,000 which you might think you need.
Cheers,
William
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Beale (was: Mystery inc.)
Date: 16 Sep 1999 09:30:24 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, sha99y00000
([EMAIL PROTECTED]) wrote:
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> [Does that make sense?]
No. It's all in HTML. Please stick to plain text in newsgroups.
> <p>Sha99y
> <br> </html>
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Michael =?iso-8859-1?Q?=D8stergaard?= Pedersen <[EMAIL PROTECTED]>
Subject: Re: Can you believe this??
Date: Wed, 15 Sep 1999 16:02:02 +0200
>
> Can you all believe that someone is actually trying to get $59.95 for a
> program that uses an algorithm that they refuse to publish? It is not mine!
>
> Is this a joke?
>
> http://www.coredcs.com/~encrypt/secure.html
I mailed them and here is some of the "information" they sent me...
=====================================================================
However, let me comment on your question about the algorithm. I am
reasonably confident that if I gave you the complete source code to the
program, you would not be able to decrypt any messages that were
encrypted by the SECURE program. I'm not going to give you the source
code, however, and I doubt that many software companies would
willingly distribute the source code of their products because there
would
be an instant upsurge in competition from others. I believe that
software
is called, in this country, intellectual property.
I'm willing to reveal only the following facts about the SECURE
algorithm:
SECURE accepts the user's password and, combined with other data,
generates a extremely large key that encrypts the data. As a security
feature, the user's password is never stored in the encrypted file or on
the disk.
I can also tell you that the SECURE program first attempts to compress
the input file and then it encrypts it. Files that are already
compressed
will not compress any further.
To decrypt a SECURE encrypted file, the data is first decrypted and then
de-compressed.
=====================================================================
I don't think that this needs any comments...
-Michael
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Date: Thu, 16 Sep 1999 12:25:20 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> Mr BS in his book (which I don't recomend I read it in a library)
>> page 226 2nd edition says theat error handling should be seperate
>> from encryption look at bottom of page. I don't trust his advice ...
>
>I'm currently working in this area, and I can assure you that
>there are very real advantages to applying error recovery as
>a "wrapper" closer to the communication channel than is the
>encryption. Mainly, it allows reception errors (which are
>*quite common* in modern radio systems) to be detected and
>corrected with *no knowledge of the encryption*; so, for example,
You quoted me out of context. I am not condemming the "wrapper"
used with most modern communication data packets that the
communication channel software handles. Becasue that is a good
idea as you well know. What I am condemming is the 3-letter
chaining methods that use "error recovery" since they are implemented
during the encryption process and add little value to the average user
since they can't recover the data if there is an error in the encrypted
message anyway. The 3-letter chaining method are really nothing more
than a "back door" for the NSA or (there Chinese friends) to weaken
your encryption so that it can be broken easier.
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: fungus <[EMAIL PROTECTED]>
Subject: Re: NSA and MS windows
Date: Thu, 16 Sep 1999 10:50:22 +0200
Roger Schlafly wrote:
>
> Yes, it is plausible, but not terribly convincing either. Why did
> MS need 2 keys? Is the concern that MS would lose one private
> key?
That's what they claim, and that's the reason I'm not convinced
by their argument.
Tell me, how does a multinational corporation "lose" a key?
OTOH, I've also heard that the second key can be replaced by
anything you like and strong crypto suddenly appears on your
machine - a bit like Netscape which can be "upgraded" by changing
one byte of the program.
This is a much more interesting possibility, and should be
fully investigated.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Date: Thu, 16 Sep 1999 12:38:39 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>tunafish wrote:
>> What they seem to have done is deliberaltely weeken these algorithms
>> by asking those who submitted to make certain modification to the
>> code...
>
>Oh, good grief! That's the old conspiracy theory resurrected
>from the early DES debate. What EVIDENCE do you have that this
>has occurred?
I don't even have evidence that the guy Mr L.H. the FBI guy with the
license to kill that is so certifed good at killing mothers holding babies
was also in Waco. But I have read articles that state he was there since
he did so good at Ruby Ridge. Of course the evidence if there was any
was destroyed unless the texas rangers can provide a link. But I think
he is the kind of guy the FBI uses when it has to kill woman and
children. But then again maybe I am all wrong. Don't take me wrong
I think V.H. aka D.K was a very very bad sick person.
If you are very well read you should be smart enough to realize there
was much discussion about how fast custom circuits could be made in
the days of DES. Just like most people have no idea how old the SR-171
is. Most people have no idea how good the government with its vast supply
of money is at building custom equipment in the old days. It is a fact
IBM was going to go with a 64 bit system but the NSA stepped in to
make it a 56 bit sytem. Why? Because a 56 bit system is can be
brute force searched 256 times faster. I think the old book "The Puzzle
Palace" covers this somewhat if your interested.
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
------------------------------
Date: Thu, 16 Sep 1999 13:47:46 +0200
From: yoni <[EMAIL PROTECTED]>
Subject: RC4-40 Cracking
Can you help me clarify something ?
When you refer to Cracking the RC4 you mean a "brute force" attack ?
simply try all possible combinations of the key ?
Do you use a known plaintext attack ?
RC4-40 is RC4 initialized with 40 Bits key (5 bytes)?
Thank you,
Yoni.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NSA and MS windows
Date: Thu, 16 Sep 1999 12:45:32 GMT
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
>
>
>Roger Schlafly wrote:
>>
>> Yes, it is plausible, but not terribly convincing either. Why did
>> MS need 2 keys? Is the concern that MS would lose one private
>> key?
>
>That's what they claim, and that's the reason I'm not convinced
>by their argument.
>
>Tell me, how does a multinational corporation "lose" a key?
>
Well maybe Mr Gates has the only copy locked in a vault in
one of his houses. In case an earthquake destroys the house
thus the only copy would be destoryed. However the Back up
key is mostly an only copy in that same vault.
You would think they would just copy the one key and place
it in more than one place. But may be that is why we aren't
all billionares. We can't see the big picture like Gates.
And we can't have the NSA test things for us.
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
******************************
