Cryptography-Digest Digest #414, Volume #11 Fri, 24 Mar 00 18:13:01 EST
Contents:
rc-5 plaintext guess. ("Richard Lee King Jr.")
Re: root mod a prime? ("Tom St Denis")
Re: ecc equation ("Tom St Denis")
Re: rc-5 plaintext guess. ("Tom St Denis")
Re: OAP-L3: Answer me these? ("Tom St Denis")
Re: OAP-L3: Answer me these? ("Tom St Denis")
Re: Factoring Large Numbers - I think I figured it out! ("Tom St Denis")
Re: OFB, CFB, ECB and CBC ("Marc Howe")
Re: OAP-L3: Answer me these? ("Trevor L. Jackson, III")
Re: OAP-L3: Answer me these? ("Trevor L. Jackson, III")
Re: Open source or not. (Was: Re: Planet Poker Claims...) ("Trevor L. Jackson, III")
Re: Open source or not. (Was: Re: Planet Poker Claims...) ("Trevor L. Jackson, III")
Re: what is a 2048 bit cipher? (Jerry Coffin)
Re: NIST publishes AES3 papers ("Trevor L. Jackson, III")
Re: nsa patent on new storage device ("Trevor L. Jackson, III")
Re: Next Vernam variety idea. ("Adam Durana")
----------------------------------------------------------------------------
From: "Richard Lee King Jr." <[EMAIL PROTECTED]>
Subject: rc-5 plaintext guess.
Date: Fri, 24 Mar 2000 20:11:27 GMT
here is my guess for the rc5-32/12/8 contest.
1 "The "
2 "unkn"
3 "own "
4 "mess"
5 "age "
6 "is: "
7 "You "
8 "win "
9 "RSA "
10 "labs"
11 " RC5"
12 " pub"
13 "lic "
14 "key "
15 "cont"
16 "est."
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: Fri, 24 Mar 2000 20:28:50 GMT
Mike Rosing <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > Wouldn't that be "the order of a point on the curve" because not all
points
> > will generate the same order set of points.
>
> If you know the order of the curve, then you know all the possible
> orders of
> every point. You can check which order a point belongs to easily.
>
> > Is there any bounds or estimates on randomly chosen points with my
setup...?
>
> There's an easier way. Assume you know the order of the curve #E = r*p
> where r is small and p is a large prime. Pick a random point then
> multiply
> it by r. If you don't get the point at infinity, you will have a point
> of order p. Don't need no stinkin' estimates! :-)
That's the thing I don't know the order of the curve, because it's made at
random.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Fri, 24 Mar 2000 20:30:17 GMT
Mike Rosing <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > So if I make random (a, b) for a curve in GF(p) I must simply check that
> > 4a^3 + 27b^2 mod p != 0?
>
> And you want to avoid 1728 too.
Why 1728?
> I doubt it. That math is pretty thick. Schoof's original work has been
> modified with many improvements starting with Atkin and Elkies. The
> author
> of MIRACL (Michael Scott) is a PhD mathematician (I think he just
> graduated).
> So he can go thru the papers and figure things out easily. At this
> point
> I think that's all there are, published papers directed at professional
> mathematicians.
>
> Finding shortcuts to computing the number of points on elliptic curves
> is state of the art math. It'll be a while be that filters down to the
> pedestrian level.
Well that's just the thing I can't find any descriptions of any of the
algorithms online. Even if I don't understand the algorithm I may be able
to implement it.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: rc-5 plaintext guess.
Date: Fri, 24 Mar 2000 20:30:50 GMT
What the heck is this?
Go back to school junior.
Tom
Richard Lee King Jr. <[EMAIL PROTECTED]> wrote in message
news:PZPC4.1262$[EMAIL PROTECTED]...
> here is my guess for the rc5-32/12/8 contest.
>
> 1 "The "
> 2 "unkn"
>
> 3 "own "
> 4 "mess"
>
> 5 "age "
> 6 "is: "
>
> 7 "You "
> 8 "win "
>
> 9 "RSA "
> 10 "labs"
>
> 11 " RC5"
> 12 " pub"
>
> 13 "lic "
> 14 "key "
>
> 15 "cont"
> 16 "est."
>
>
>
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 20:33:56 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
>
> > Right after quantum computers come out you can use a million bit key :)
>
> Should we re-encrypt all of our old messages with the new keys? How do we
get
> our opponents to let us re-encrypt the messages they have saved that were
> encrypted with the old keys?
The lifetime of a message is normally very short. Even so with the top AES
keysize, and a good aes cipher you are looking at about 2^128 work to solve
the for the key. Not very productive.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 20:34:08 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : A keyspace of more then say 160 bits is a waste of resources....
>
> So, the One-Time-Pad is dead, then? ;-)
Yes it is.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Fri, 24 Mar 2000 20:40:25 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > Richard Anthony Hein wrote:
> > > Oh yeah, I forgot to mention that the method would have enabled us to
solve
> > > for the 3 numbers which multiply to make a number as simply as 2
numbers,
> > > and at the same time. 4 and more would also eventually be possible
... if
> > > it would have worked. Or is this something that we are already able
to do
> > > efficiently?
> >
> > It doesn't much matter, because once one factor is known, division by
> > that factor is very fast, relatively speaking, so you just iterate
> > the factoring method. Compared to the cost of finding even *one*
> > (nontrivial) factor, the rest of that procedure is peanuts.
>
> ...usually. Now and then, numbers have been factored to the point of
> producing a relatively large composite factor that took a great deal
> longer to factor. IIRC, Knuth gives one example like this in V2, and
> others have undoubtedly occurred since then as well. I'm not sure,
> but ISTR there being at least one situation like this right now,
> where one of the factors of a number is known to be composite, but
> nobody knows what its factors are (yet).
>
> Simply being smaller doesn't necessarily mean a number is easier to
> factor.
Actually the NFS will factor numbers regardless of composition in about the
same estimated time/space. So size does matter.
tom
------------------------------
From: "Marc Howe" <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 21:09:16 GMT
Thank you all very much...lots of info!
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
>
>
------------------------------
Date: Fri, 24 Mar 2000 16:50:36 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Volker Hetzer wrote:
> "Trevor L. Jackson, III" wrote:
> > If no one finds any flaws in your product within 60
> > days you keep my money, and you get to advertise the fact that you software is
> > flawless. Otherwise I'll split your money with the people who find the flaws
> > in your software.
> Of course, this only works if he posts the source code that he actually uses.
I don't see the problem. If he posts flawed code he forfeits. If he posts flawless
code (har), he can reasonably claim the code he did not post was equally flawless.
------------------------------
Date: Fri, 24 Mar 2000 16:57:41 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Anthony Stephen Szopa wrote:
> Thanks for showing us again that you are unable to address the theory,
> and specification of the procedures and processes, and have chosen to
> challenge the implementation.
False.
I have already addressed the theory and specifications of your software, in
detail, several months ago. It was my considered opinion that your entire
product, including theory, specifications, procedures, processes,
implementation, and documentation and sales material demonstrate a complete
ignorance of _all_ of the fundamentals required of cryptographic software. It
has no redeeming social value and thus should be prohibited under obscenity
statutes; I know it when I see it.
But since you persist in making silly claims in spite of multiple explanations
from multiple credible sources (most of which are more credible than I), I
offered you a chance to prove everyone wrong, and make money while doing so.
I call your bluff.
N.B., Karnak predicts that you will not rise to the challenge because in your
heart you know the truth: your software is worthless.
>
>
> http://www.ciphile.com
>
> OAP-L3 Version 4.3 to be released in about a week. Six new MixFile
> processes are being added.
>
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Anthony Stephen Szopa wrote:
> >
> > > OAP-L3: Answer me these?
> > >
> > > Where is the bias in any of the procedures and processes in OAP-L3?
> > >
> > > Where is any bias introduced into any of the procedures and processes
> > > found in OAP-L3 when used according to recommendations?
> > >
> > > 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?
> >
> > The more important conclusion is drawn from the fact that you refuse to
> > provide sufficient information for an objective observer to determine
> whether
> > biases exist or not. But I'll offer an inducement that you may find
> useful as
> > an endorsement. I'll put up $1,000.00. You put up $10,000.00, and
> publish
> > all of your source code. If no one finds any flaws in your product within
> 60
> > days you keep my money, and you get to advertise the fact that you
> software is
> > flawless. Otherwise I'll split your money with the people who find the
> flaws
> > in your software.
> >
> > Now if you are are right about the quality of OAP-L3 you stand to make a
> quick
> > grand. You _do_ believe in your software don't you?
> >
------------------------------
Date: Fri, 24 Mar 2000 17:00:57 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
[EMAIL PROTECTED] wrote:
> In article <8bdtgp$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (A. Prock) wrote:
> > According to A. Prock <[EMAIL PROTECTED]>:
> > >Going directly to the heart of the matter, Planet Poker, Paradise
> Poker,
> > >and all of the other online poker rooms are asking us to play with
> > >cards which we haven't seen shuffled. In a live game it would be
> analogous
> > >to bringing out a new deck of cards each hand, which have been
> "shuffled"
> > >in the back room somewhere, and dealing it "cold".
> >
> > I may not have been clear here. What I'm trying to say is that the
> > online card rooms are asking us to play *without* knowing how the
> > deck was shuffled.
> >
> > In a real card room we get to see how the deck is shuffled. Simply
> > knowing how the cards are mixed up is important. If a live dealer
> > hid the cards while they were being shuffled, we would be much more
> > suspicious.
> >
> > Hiding the shuffling algorithm is the electronic equivalent of hiding
> > the cards when they are shuffled.
> >
> > - Andrew
> >
> >
> It is commonplace in Bridge to play with pre-delt cards. It is also
> common
> knowledge that these pre-delt cards are distributed differently from
> cards delt at the table.
Are you referring to Duplicate?
> The difference being of course that the pre-
> delt hands are delt randomly, while the hands shuffled 'badly' at the
> table are not random.
Is this a recent change? When I played bridge clubs the Director was
responsible for overseeing the shuffles, but they were no more random than
human shuffling.
------------------------------
Date: Fri, 24 Mar 2000 17:01:40 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Gary Carson wrote:
> --
> Gary Carson
> [EMAIL PROTECTED]
> http://garycarson.home.mindspring.com
> [EMAIL PROTECTED] wrote in message
> <8bg6uf$26k$[EMAIL PROTECTED]>...
> >In article <8bdtgp$[EMAIL PROTECTED]>,
> >>
> >It is commonplace in Bridge to play with pre-delt cards.
>
> It's common in duplicate bridge, typically played for bragging rights.
Or Red points and Gold points. ;-)
> It's
> not common in rubber bridge, typically played for money.
>
> Gary Carson
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Fri, 24 Mar 2000 14:57:41 -0700
In article <MaNC4.67100$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> > Indeed. Pumping up your keyspace is very likely to increase the
> > difficulties experienced by analysts. Of course, even 2048 bit
> > cyphers can be broken...
>
> You are so wrong. Making the keyspace large is only effective if your
> algorithm is secure. So even a cipher with a 80 bit key would be secure by
> todays computer standards [maybe not 20 years from now..., but for now].
Keep in mind that crytanalysis _typically_ results in a reduction of
the work by some _factor_ of what it takes to exhaust the key-space.
Stated in a different way, it reduces the effective key size by some
number of bits.
If you start with an 80-bit key, you have to be essentially
_absolutely_ certain (which you can't be) that nobody can find an
effective attack that'll reduce the strength at all, even if you only
need relatively short-term security.
If, OTOH, you start with a larger key, somebody can find a fairly
significant attack without being able to compromise your security.
Just for example, if you start with a 256-bit key, even if they can
reduce the effective key size to 128 bits, they're nowhere close to a
practical attack. If they reduced an 80-bit key by the same factor,
they'd only need to search a 40-bit keyspace which is quite feasible.
At the same time, it should be noted that if you're going to try to
be conservative by using a large key, you also (generally) need to be
relatively conservative in other areas as well to stand a good chance
of making any real use of the key -- a larger key normally requires
either greater complexity in each round or else a larger number of
rounds to get full diffusion.
With that said, there's really no question that your basic idea is
still correct: 100 bits or so is enough for security for quite a
while unless there's a major break against the cipher, or a major
breakthrough in computing technology. Of course it's handy for the
key size to be a power of 2, so 128-bit keys are fairly common.
There's honestly little practical purpose for keys a lot larger than
that -- I realize AES requires support for a 256-bit key, and to
_some_ extent I can sympathize with NIST requiring: the small key
used with DES has been a sore point for years, and they're probably
just (over-)reacting to that criticism. The other point is that it's
not a _lot_ of extra work to support a larger key, so they might as
well.
Despite this, it's still basically overkill, and the dramatically
larger keys some people use are basically pointless as well.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
Date: Fri, 24 Mar 2000 17:10:50 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Paul Koning wrote:
> "Trevor L. Jackson, III" wrote:
> >
> > Paul Koning wrote:
> >
> > > Trevor,
> > >
> > > It would be much easier to read your posts if you could configure
> > > your software so it wraps lines, or wrap them by hand. Reading
> > > 1000-characters lines by horizontal scrollbar is a major pain.
> > >
> > > paul
> >
> > Sorry, I'm trying to get away from
> > the
> > effect of having a word-wrap
> > setting
> > that doesn't match the setting
> > of
> > the readers or writer. I'm sure
> > you
> > know what I mean. ;-)
>
> Yes, I surely do! :-(
>
> > P.S. Is wrap-to-window rare?
>
> Beats me, but I do know that Netscape doesn't have it, not
> on my Sparc at least.
Netscape on Windoze has
Edit/Preferences/Mail&Newsgroups/Messages which includes
Message wrapping: [x] Wrap incoming., plaintext messages to window width.
But since it's a problem I'm back to double wrapped text. ;-)
>
>
> paul
------------------------------
Date: Fri, 24 Mar 2000 17:26:56 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: nsa patent on new storage device
John Savard wrote:
> "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote, in part:
>
> >but appears to lack any aspect of content addressability
>
> It's true that holographic techniques are hoped to provide some type
> of content addressability, since content-addressable memories are
> specialized, and most present types of memory do not provide
> content-addressability, a very high density and low cost memory
> device, simply because it isn't content addressable, is hardly
> something to be dismissed as useless!
Yes. But we should _expect_ memory cost to continue their precipitous
descent. Another decrement is a welcome thing, even from gov't labs.
The most significant benefit did not appear to be information density or cost,
but energy expenditure. If the power savings are as extreme as they appear
these things may scale into remarkable densities, with attendant further drop
in cost. But I first heard that magnetic disks were up against physical
limits over 20 years ago. The engineering investment in established
technology is a fearsome obstacle to the introduction of new technology. It
typically start in niche markets unaddressable with existing technologies.
NSA may be just such a niche.
Who else would really want to actually built a machine that could store 2^56
or 2^64 code words? ;-)
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Next Vernam variety idea.
Date: Fri, 24 Mar 2000 17:31:05 -0500
You could/should use chaining or a salt for each encryption, depending on
what type of cipher you use.
Like I said your system is highly over complicated.
- Adam
"RecilS" <[EMAIL PROTECTED]> wrote in message
news:8bgela$1h4$[EMAIL PROTECTED]...
> The reason I transmit new keys is to avoid encryption with the same key.
I
> thought that'd be a good idea.
> No?
>
>
------------------------------
** 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
******************************
