Cryptography-Digest Digest #407, Volume #11 Fri, 24 Mar 00 01:13:01 EST
Contents:
Re: 2048 Bit Encryption? (Jerry Coffin)
Re: 2048 Bit Encryption? (Jerry Coffin)
Re: Download Random Number Generator from Ciphile Software (Jerry Coffin)
Re: Blowfish Code Question - Applied Cryptography 2nd Ed.
([EMAIL PROTECTED])
Re: 2048 Bit Encryption? ("Joseph Ashwood")
Re: 2048 Bit Encryption? ("Joseph Ashwood")
Re: OAP-L3: Answer me these? ("Joseph Ashwood")
Re: ecc equation ("Joseph Ashwood")
OFB, CFB, ECB and CBC ("Marc Howe")
Re: OFB, CFB, ECB and CBC ("Marc Howe")
Re: OAP-L3: Answer me these? ("Joseph Ashwood")
Re: NIST publishes AES3 papers (David A. Wagner)
Re: Open source or not. (Was: Re: Planet Poker Claims...) ("Joseph Ashwood")
Re: new Echelon article (David A. Wagner)
Re: NIST publishes AES3 papers ("Joseph Ashwood")
Re: 2048 Bit Encryption? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Thu, 23 Mar 2000 21:08:07 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> I think what OAP-L3 does and accomplishes is fundamental and has
> probably been addressed in mathematics and probability often enough.
>
> A professor in this field and in this specialization could probably shed
> much light on the subject with regard to OAP-L3.
Hmm...there _seems_ to have been a doctorate in statistics granted to
somebody by the name of "Coffin" several years ago (and somebody who,
undoubtedly by pure coincidence is also named "Coffin" seems to have
received a doctorate in Computer Science from the University of
Arizona, but I guess that's not particularly relevant to the question
at hand).
In case you're unaware of the fact, you do have to take at least a
couple of math classes and learn a tiny bit about probability to get
a doctorate in statistics. I guess technically professor isn't quite
right though: if there was a Dr. Coffin who stayed in academia long
enough to make it past Assistant Professor, it was somebody other
than me...
> To date: no substantive criticism regarding the merits of the theory has
> been offered. I think this is significant since the theory is so
> fundmental.
>
> We are at a point now where we are looking for a reasonable attack. None
> has been offered.
...and it probably won't be until or unless you release either source
code to at least a minimal program that uses your algorithm, or else
a _complete_ and _exact_ definition of your algorithm. I've looked
at what you publish on your web site, and frankly it's not even
CLOSE. Just for example:
The AddressN address file, as described above, is associated
with this process.
You can't just say it's associated with the process -- you need to
tell us exactly HOW it's associated, how it's used and so on. Your
entire explanation looks to me like it's intended primarily to
impress the unitiated with complexity, while obfuscating things to
the point that nobody can really understand what you're doing, how it
works, or even whether it really works at all. In short, it really
only seems to demonstrate two things: 1) you can do a factorial, and
2) you're willing to force your user to enter an absolutely
inordinate amount of key material -- I went through your explanation
of "operations" and by step 10, it appears that the user had to enter
141 digits of input, and in many cases the user is required to follow
relatively strict rules about groups of 10 and 14 numbers to be
entered at a time. To me, placing this sort of requirement on the
user renders the program uninteresting in any case -- there are
simply too many other methods that require a GREAT deal less work in
the part of the user to justify this. The worst part is that much of
your program seems to depend heavily upon these user inputs being
random when it's long since been proven that this simply isn't the
case. Just for an obvious example, if users are asked to enter the
digits from 0 to 9 in a random order, they often follow relatively
predictable patterns.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Thu, 23 Mar 2000 21:21:38 -0700
In article <#t1Uv#Tl$GA.153@cpmsnbbsa02>, [EMAIL PROTECTED]
says...
[ ... ]
> Can I get a reference on that proof? Just a cursory
> examination fo the situation (not anything approaching a
> proof) tells me that you only need enough key to raise the
> total entropy of the output stream to the length. I might be
> wrong, which is why I'd like to see that proof.
He doesn't give the proof itself, but section 1.13.3 of HAC says: "A
necessary condition for a symmetric-key encryption scheme to be
unconditionally secure is that the key be at least as long as the
message." He gives a couple of references for that section, but I
haven't chased down which one this comes from -- of those given, my
first guess would be Shannon, but I haven't verified it.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Thu, 23 Mar 2000 21:32:30 -0700
In article <eekFu#Tl$GA.262@cpmsnbbsa02>, [EMAIL PROTECTED]
says...
[ ... ]
> > C'mon, this isn't rocket science, this is elementary
> boolean logic!
> Actually in many ways, it's more difficult than rocket
> science. With rocket science we know how to find the
> answers, with anything security oriented we can only
> establish what won't work.
In fact, Rocket Science is quite easy in this regard: when a rocket
has a problem, the effects of the problem tend to be _quite_ easy to
detect -- sometimes from many miles away. The Challenger disaster
comes to mind here. Unless I'm mistaken, it was easily detected by
naked eye over an area of probably millions of square kilometers...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Blowfish Code Question - Applied Cryptography 2nd Ed.
Date: Fri, 24 Mar 2000 04:25:43 GMT
Sir,
The modulo is implied becuase the word size is 32 bits. Most modern C
implementations define unsigned int and unsgined long as 32 bit. C
will let a variable overflow with no comment.
--Matthew
In article
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Night Heir) wrote:
> On page 647-648, within the Blowfish source code, I have a question
about the
> function F. I have not taken time to transpose all of the code here.
The
> excerpt is basically as follows:
>
> ...
> y = bc->S[0][a] + bc->S[1][b];
> y = y ^ bc->S[2][c];
> y = y + bc->S[3][d];
> ...
>
> What happened to the mod operations (there should be two). On page
338 he
> defines the function F as containing S1,a+S2,b mod 2^32 etc. Thanks
in advance
> to the group for your input.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 2048 Bit Encryption?
Date: Thu, 23 Mar 2000 19:36:16 -0000
Crossposted-To: talk.politics.crypto
> Isn't it interesting how so much of this wasted bandwidth
is based upon
> lawyerly interogation? I just don't think a dedicated or
sincere mind
> concerned with encryption and truth would debate or
challenge encryption
> software that is so readily available and tangible by
rhetoric alone.
Isn't it equally interesting, that most of us have said the
exact same things, repeatedly (see deja.com for reference).
That we have all requested you to release either the source
code, or a set of algorithms complete enough for someone
without your help to implement a compatible system.
>
> I do think this behavior might be expected from a law
based mind lurking in
> this news group. Someone concerned with encryption from a
legal point of
> view. Someone with a not so "hidden" agenda.
>
I tend to think that these questions would be asked by
someone with enough knowledge in the area to ask reasonable
questions. It is also worth noting that people first asked
you to reveal your method, and when you failed to they then
proceeded to list your product as probable snake-oil. This
is the same process that each and every person is put
through. The other option is that if your methods are
available, they are examined and you are listed as one of
non-snake-oil, probable snake oil, or snake-oil. The more
you say, the less we think of your methods. However, if
reveal your complete methods, not just hand-waving, it may
be analyzed and we may actually say that to the best of our
knowledge your method is good, or we could at least tell you
where you have problems. In the mean time, all we can do is
point out that it is extremely unlikely that an unrevealed
encryption method is strong, all you're doing is stopping
the legitimate people from analyzing your work.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 2048 Bit Encryption?
Date: Thu, 23 Mar 2000 19:46:11 -0000
Crossposted-To: talk.politics.crypto
Actually most of us are still waiting for your so-called
theory to be expressed properly. Once we have, not only what
you do with the output, but also the details about how you
use the input to create that output, we can present attacks.
As expressed, your "theory" is little more than:
Generate stream
use stream for a stream cipher
We all have some idea how you do the latter, but the
Generate stream is still as-yet unknow. You have stated that
you generate a permutation, but have NEVER said how you do
this, considering that there are a very large number of ways
to do this, each of which generates a different order, I
don't see how we can make statements on your method.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Thu, 23 Mar 2000 19:58:10 -0000
Crossposted-To: talk.politics.crypto
> OAP-L3: Answer me these?
>
> Where is the bias in any of the procedures and processes
in OAP-L3?
First we need to see your algorithms, but you don't want to
reveal those.
>
> Where is any bias introduced into any of the procedures
and processes
> found in OAP-L3 when used according to recommendations?
In the algorithm(s) that generate the ordering.
>
> What conclusions can we draw if there are no biases in any
of the
> procedures and processes, and no biases introduced in
> any of the procedures and processes used in OAP-L3?
We can draw no conclusions from lack of bias. A very simple
example of a completely unbiased, and still completely
useless stream is generated by simply iterating through each
possible output in order. For example
0123456789012345678901234567890123456789.....
There is no bias, but it is certainly not suitable for
random number generation.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Thu, 23 Mar 2000 20:43:19 -0000
Actually the multiple planes to which I was referring would
probably be better called complex elliptic planes. To the
best of my knowledge the complex plane is typically of the
form a+bi, but there is not strict limitation that I can see
that would prevent one to substitute an elliptic curve for
one or both of the (a,b) pair. These elliptic planes (?) are
infinite, and the algebra can be written rather cleanly for
at least a small portion of them. Perhaps I am missing
something that seems quite obvious to you, and I realize
that I lack some of the terminology to know exactly what to
call the entities I have called elliptic planes, as a matter
of fact I do not know if these have been discussed before,
but it seems such a simple extension that I would have
severe doubts that I would be the first.
Joe
"Bob Silverman" <[EMAIL PROTECTED]> wrote in message
news:8bdju7$6mo$[EMAIL PROTECTED]...
> In article
<HXnC4.63163$[EMAIL PROTECTED]>,
> "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> >
> > Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
> > news:e8ZJ7yJl$GA.154@cpmsnbbsa02...
> > > > Hmmm.... I wonder what elliptic curves over the
complex
> > > plain could
> > > > do for crypto :-)
> > > Since there are multiple planes that could be called
complex
> > > (my knowledge of the specific terminology in the realm
is
> > > not even shaky, so pardon if this is mistake).
>
> May I suggest that if you don't have the knowledge to
answer the
> question that you not try to answer???
>
> A Weirstrass curve over C would be (essentially) useless.
> Why? Because if you extend the field over which you are
working
> to ALL of C, then the field in which you work contains all
the roots
> of the right hand side of the curve.
>
> OTOH, it is possible to use elliptic curves over a FINITE
extension of
> Q (rather than its full closure) if the finite extension
does NOT
> contain roots of the cubic.
>
>
> --
> 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/
> Before you buy.
------------------------------
From: "Marc Howe" <[EMAIL PROTECTED]>
Subject: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 05:11:41 GMT
What the heck is this?
OFB, CFB, ECB and CBC
I understand that CBC is a way to check if a file is preserved in its
original state...is this true?
What are the differences among the types and which should I use for an
encryption routine...and why?
I'm wondering this because I am attempting to use a SkipJack routine that
has these various implementations available to me.
Thank you,
Marc
------------------------------
From: "Marc Howe" <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 05:12:45 GMT
Oops...I was thinking of CRC...what is CBC?
Thanks again,
Marc
"Marc Howe" <[EMAIL PROTECTED]> wrote in message
news:hOCC4.3532$[EMAIL PROTECTED]...
> What the heck is this?
> OFB, CFB, ECB and CBC
>
> I understand that CBC is a way to check if a file is preserved in its
> original state...is this true?
>
> What are the differences among the types and which should I use for an
> encryption routine...and why?
>
> I'm wondering this because I am attempting to use a SkipJack routine that
> has these various implementations available to me.
>
> Thank you,
>
> Marc
>
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Thu, 23 Mar 2000 21:08:33 -0000
Crossposted-To: talk.politics.crypto
I think we have to part company a bit on this. I am not
comfortable saying that quantum computers won't become a
reality in my lifetime. With a quantum computer 160-bit
encryption becomes equivalent to an 80-bit cipher on a
standard computer. I'm not comfortable trusting long term
security to only 80 effective bits.
Joe
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:_LBC4.65775$[EMAIL PROTECTED]...
>
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > How is it a waste of resources when it can be broken by
someone? Are
> > you saying that 160 is unbreakable?
>
> Searching 2^160 keys in any cipher is not feasible. You
would have to find
> a faster way to break the cipher.
>
> See my post on 'what is a 2048 bit cipher'.
>
> Tom
>
>
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: NIST publishes AES3 papers
Date: 23 Mar 2000 20:50:27 -0800
In article <OuL2vSKl$GA.241@cpmsnbbsa02>,
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> I still have my doubts about triple-DES, [...]
Well, you are free to hold your own opinions, but
triple-DES seems to be by far the most trusted cipher,
if you poll folks in the field.
The reason to go with triple-DES over an AES candidate
is that triple-DES retains the decades of analysis on
DES; AES candidates have received much less scrutiny
(probably less than 1/10th as much analysis).
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Thu, 23 Mar 2000 21:22:01 -0000
Crossposted-To: rec.gambling.poker
> With any random number generation algorithm based on
modular arithmetic,
> there will be a bias. This bias has been reduced to such
a small
> percentage, and it effects all players equally, that I can
honestly say this
> wasn't the prime motivator for us to use our atomic decay
method. Instead,
> this is the motivation: any random number generation
scheme based on
> non-random events can, with proper information, be
predicted.
There is a way to remove the bias, cheaply. You can easily
precompute the number that is the maximum value that will
not result in biased output (e.g. k such that k*num <= 2^n <
(k+1)*num). By sampling numbers and throwing out any above
k*num, you can eliminate the bias in your modular division.
Joe
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Crossposted-To: talk.politics.crypto
Subject: Re: new Echelon article
Date: 23 Mar 2000 20:57:30 -0800
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> Paul Koning <[EMAIL PROTECTED]> wrote, in part:
>
> >As for "laws that forbid ... encryption" -- what laws are those?
> >There are of course regulations that disallow encryption of ham
> >radio signals, but that doesn't carry over to other radio services.
>
> They do also embrace CB radio and marine band, I'm quite sure, and
> those are a more applicable comparison to cellular telephones than
> amateur radio.
In a relative sense, sure, they may be more applicable
(I'm willing to grant that for the purposes off discussion),
but in an absolute sense, the analogy still seems quite a stretch.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Thu, 23 Mar 2000 21:37:28 -0000
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> > I feel it is well established that changing the
slightest
> > thing about a cipher voids all prior assurances of
strength.
> > In the case of triple-DES , you have tripled the number
of
> > rounds, exponentially increasing the odds of a reduction
> > algorithm.
>
> I don't see that. The three doses of DES use different
keys.
Actually most implementations only use 2 keys, because of
the meet in the middle attack. I agree that making use of
that attack is well out of reach, but even attacks that are
out of reach are generally not ignored.
> If re-enciphering with a different key weakened DES, then
> the cryptanalyst attacking a DES message could just keep
> reenciphering the ciphertext with new random keys until it
broke
> apart under its own weight. Doesn't this sound as silly
to you
> as it does to me?
I never said that it would completely collapse under it's
own weight, only that at some point the strength would be
lower than before. It is quite simple to prove the existance
of such a point, the question is whether or not triple-DES
has reached such a point.
>
> > Also the maximal strength of 3DES if 112 bits,
> > best attacks on the AES finalists put the strength in
excess
> > of 127 bits.
>
> The 112-bit result assumes an intolerable amount of memory
> usage. In any case, for the next few decades (barring a
> breakthrough that will blow <everybody> out of the water),
> there's no significant difference in strength between a
> 112-bit search and a 127-bit one... they're both out
reach.
My statement was with regards to the maximal strength, since
all attacks on the methods are not known, we can only make
estimates, and the current estimates of an AES finalist is
30,000+ times the strength of triple-DES.
I must however admit, that here in reality, you need to go
with what you are comfortable with. If you are more
comfortable with triple-DES than an AES finalist, then you
should use triple-DES. I am most comfortable with Twofish
(yes I have changed my opinion since I stated it a few
months ago), so I should use Twofish. Some other people are
most comfortable with a Vigenere cipher, and while I may try
to dissuade them, the bottom line is that they are
comfortable with the security it offers, so they should use
it.
Joe
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Fri, 24 Mar 2000 05:47:58 GMT
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Anthony Stephen Szopa wrote:
> >
> > > "the algorithm used in key generation will select randomly from
> > > that space" The algorithm does not select the random numbers.
> > > Every process requires random user input. This input is the key.
> > > The user picks the order of the processes. The user enters usually
> > > 10 or 14 different numbers for each process. The user inputs how
> > > many times each process is run with different input. Etc.
> >
> > This is a perfect example of why people dismiss your software. The first
> sentence betrays either a complete ignorance of the issues, or a purposeful
> attempt to confuse the truth. Pure algorithms do not operate randomly, they
> operate deterministically. So the algorithm _cannot_ select "randomly from
> the space".
> >
A side note- In *principle* classical
computation does not have to be
deterministic. Suppose a turing machine could
be enabled to toss an unbiased coin and to
choose its steps randomly. Then it would
follow some *single* randomly chosen path
and the probability of an output X would be the
sum of the probabilities of all computations
leading to X.
[ I don't know anything about OAP-L3 but I'm
dubious towards it due to the seemingly valid
criticisms that are being posted. ]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
