Cryptography-Digest Digest #413, Volume #11 Fri, 24 Mar 00 15:13:02 EST
Contents:
Re: ecc equation (Mike Rosing)
Re: OFB, CFB, ECB and CBC (John Savard)
Re: new Echelon article (Mok-Kong Shen)
Re: Card shuffling (wtshaw)
Re: root mod a prime? (Mike Rosing)
Re: Open source or not. (Was: Re: Planet Poker Claims...) ("Gary Carson")
Re: bigfloat works (kinda) (Mike Rosing)
Re: And those doubtful minded who may not believe that I have had any (Ferdinand
Talan)
Re: Pegwit for windows (Mike Rosing)
Re: Prime numbers? (newbie alert -- again) (proton)
Re: Next Vernam variety idea. ("RecilS")
Re: Download Random Number Generator from Ciphile Software (Eric Lee Green)
Breaking crypt(1) (Remove NO_SPAM to reply)
Re: 2048 Bit Encryption? (Xcott Craver)
Re: OFB, CFB, ECB and CBC (Eric Lee Green)
Re: 2048 Bit Encryption? (Xcott Craver)
Re: NIST publishes AES3 papers (Paul Koning)
Re: Fastest DES implementation on Intel PIII ? (Paul Koning)
Re: new Echelon article (Paul Koning)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Fri, 24 Mar 2000 12:16:16 -0600
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.
>
> I saw a program called schoof.exe from MIRACL that calcs the order of a
> point on a curve. I tried searching for it, and I found the reference, but
> I can't find a copy of the description online.
>
> Anyhelp?
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.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 11:25:54 GMT
"Marc Howe" <[EMAIL PROTECTED]> wrote, in part:
>What the heck is this?
>OFB, CFB, ECB and CBC
ECB is just encrypting the blocks of the file with the block cipher,
one after another.
The other modes are explained on my web site, at
http://www.freenet.edmonton.ab.ca/~jsavard/co0409.htm
basically, they're just ways of making sure that, if you send two
similar files with the same key, there are no blocks encrypted the
same to give that away.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: new Echelon article
Date: Fri, 24 Mar 2000 19:27:23 +0100
Arturo wrote:
>
> Sixth: what I am really concerned is about the fact that Echelon
> (along with their little brothers, cousins and the like) is after our
> communications. All of them. No matter if we behave or not, if we are
> law-abiding citizens or the bad guys. If you read Orwellīs 1984, Big
> Brother was just that: the big brother that listens, sees and knows all,
> regardless of what the people think or make.
>
> We are all treated as guilty until proven otherwise, and to hell
> with our constitutional rights. If they want it that way, I want to hear it
> loud and clear from them. At least, that would let us know where we all
> stand.
>
> And as for Thomson or Boeing, stop crying and protect your secrets
> better. I donīt care; after all, we donīt get a buck out of their profits
> do we?
It is a pleasure to read what you have so clearly and sentimentally
expressed. Yes, the persons (natural or legal, whose secrects
have been intercepted and misused) themselves are in fact 'mainly'
to be blamed. (If someone living in a big town never locks the door
of his house, he is unlikely to get any indemnity from the insurance
in case thieves visit him.) One has indeed to take one's own
initiative to appropriately protect all communications that are
security sensitive. The recently proclaimed relaxation of EAR and
a probable consequently induced relaxation sometime later of the
Wassenaar Arrangements seem to point to some hope (though I am yet
suspicious) that people all over the world would in the near future
be able to protect their communications with crypto algorithms of
ANY strength without getting in trouble with the justice departments.
In that situation, Echelon and its less-well-known counterparts
would become obsolete. Should that for any reasons be not realizable,
I would like to take this opportunity to recall a recent suggestion
of mine in another thread, namely to undertake to jam these powerful
malicious machineries though providing them with a big surplus of
bogus ciphertexts to work on, thus exhausting their spectacular
albeit finite and limited available resources. (The bogus ciphertexts
can e.g. be some random sequences of hex digits that one appends to
normal e-mails regularly or else puts onto one's web page with very
frequent updates. Any analysis attempts by the big-brothers must
evidently be futile, since these ciphertexts do not have any
corresponding natural language plaintexts.)
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Card shuffling
Date: Fri, 24 Mar 2000 11:45:34 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> A ideal random device will produce every permutation with equal
> chance, but it doesn't follow from this that each permutation has
> equal 'ordered-ness' which is a (independent) quantity that we could
> yet define. (The six surfaces of a perfect dice have equal chance
> of being on the top, but it doesn't follow that they carry the
> same number of dots.)
The most important attribute of cards or dice is that they are impartial,
they don't care. If dice are loaded, or cards are shaved, then they have
a proclivity to be biased.
> A reverse order is not the same as the original
> but it has some amount of order in it, right? If someone arbitrarily
> shuffles the deck, then one normally gets more disorder. So in some
> global sense it should be possible to compare two occurences of
> 'disorder' even though that comparison might not be precise enough
> and subject to an fair amount of uncertainty.
All shuffles are honest if the person does not know how to manipulate the
deck' therefore, all such shuffles of neutral decks are equal. If somone
knows a bit too much about how to manage the cards, he can not usually
perform an honest shuffle at all.
> >
> > > 'Convincing to an ordinary person that it is disordered' is well
> > > sufficient (for my enquiry at least, see my previous posts). The big
> > > question remains how to find such a (not necessarily scientifically
> > > impecable) measure.
> >
> > But my point is, there is no scientific meaning at all! Much
> > less an impeccable measure.
> >
> > This is not mathematics, it is psychology.
But, the goal of shuffling is to level all to feel psychologically equal.
Otherwise, there is little point in it.
>
> Playing games is also certainly not mathematics. But we can apply
> mathematics to game playing and psychology and finance and many many
> scientific disciplines.
>
It is still a game for a card counter, but the rules of the game have
changed to those of mathematics and to whether they can be effectively
used in a game of wits with the house. Almost all games are
mathematically interdependent.
When some shuffling technique is used that is easy to appreciate but hard
to anticipate, the results are useful in the area of games.
Consider those that use a random generator to shuffle. If someone can set
the seed and knows its effect, he is an unfair player. Otherwise, such is
fine.
Other than random, cards may be obscurely, but deterministically
shuffled. Which place at the table is important. Consider a deck,
starting in natural order, clubs to spades, duces to aces; using a to z
and A to Z for 52 values, the first 52 alphabetic characters of this
paragraph will yield an order as follows:
GRtoJSuaDKbElHAicLmOBdYfpIgPjWMqyZhXTnrUsNCvFwQVxkez
The cards are {clubs}, <diamonds>, (hearts), and [spades] as follows:
(8)[6]<8><3>(J) [7]<9>{2}(5)(Q) {3}(6){K}(9)(2) {10}{4}(K){A}[3]
(3){5}[K]{7}<4> (10){8}[4]{J}[J] []<5><K>[A]{9} [Q][8]<2><6>[9]
<7>[2](4)<10>(7) <J>[5][10]<Q>{Q} {6}<A>
If poker or blackjack is the game, OK as is to some partial use limit. If
bridge is the game, deal the cards, and *hash* the deal by reordering your
hand to ascending order. So, in bridge, etc., a deal can involve many
optional equivalent shuffles.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: root mod a prime?
Date: Fri, 24 Mar 2000 12:25:15 -0600
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! :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Gary Carson" <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Open source or not. (Was: Re: Planet Poker Claims...)
Date: Fri, 24 Mar 2000 12:07:44 -0600
--
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. It's
not common in rubber bridge, typically played for money.
Gary Carson
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: bigfloat works (kinda)
Date: Fri, 24 Mar 2000 12:35:09 -0600
Tom St Denis wrote:
> Does your code work with prime fields yet? I wouldn't mind playing with it.
Not well, but it could. You're better off with a large integer package
for that. The main reason is that with floating point I'm never exact
and with prime fields there's no reason not to be exact. If you just
want to play, it'd be real easy to make a "mod()" function or to make
a global number the prime and just return the mod of every operation.
You can just round the results to get nice integer results.
I'll be happy to explain it offline, send me e-mail and remind me.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Ferdinand Talan <[EMAIL PROTECTED]>
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.europe,soc.culture.nordic,alt.security,soc.culture.usa,soc.culture.ukrainian
Subject: Re: And those doubtful minded who may not believe that I have had any
Date: Fri, 24 Mar 2000 13:42:52 -0500
That is such a bad scan. It looks like it is scanned side ways or
something. I can't even make out who it is addressed to. Now why was
it again the CIA tried to recruit you?
Markku J. Saarelainen wrote:
>
> And those doubtful minded who may not believe that I have had any dealings
> with SCIP or any other people .. here is SCIP (http://www.scip.org ) renewal
> form that was mailed to me ...
>
> ------------------------------------------------------------------------
> [Image]
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Pegwit for windows
Date: Fri, 24 Mar 2000 12:48:23 -0600
[EMAIL PROTECTED] wrote:
>
> ###
> I made pegwit gui for windows
>
> it is a program for performing public key encryption
> and authentication using elliptic curve
> based on Pegwit v8.71 by George Barwood
>
> if you can get and try it from:
> http://disastry.dhs.org/pegwit/
Nice job! I like the screen shots on the web page.
Patience, persistence, truth,
Dr. mike
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: Re: Prime numbers? (newbie alert -- again)
Date: Fri, 24 Mar 2000 18:37:21 +0100
Tom St Denis wrote:
>
> proton <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
[-yadayadayada-]
> > ... when Im programming.
> Well please don't market your software until you know what you are doing.
> And of course feel free to ask questions here, this is of course a
> newsgroup.
Actually I already have made one program with a silly little password-
hashing thingy in it. Random bit-shuffling mostly. But its possible
that someone with some crypto knowhow could weaken it. Dont think it
could be reversed tho... anyways. Its GPL. Im one of those insane
geeks that dont really think my software is worth anything money-wise.
Heck I just do it for fun =)
One other program also has a tieeny weeny text-scrambling-routine in it
but thats for obscurity, not security.
Works something like,
P = some number
e = seed * P
E(n) = n^e, e *= P
I used a prime for P, which is one of the reasons for my original
question
about primes and randomness (since I wanted to scramble the ciphertext
good).
P in my routine is 16-bit, all others 8-bit.
/proton
------------------------------
From: "RecilS" <[EMAIL PROTECTED]>
Subject: Re: Next Vernam variety idea.
Date: Fri, 24 Mar 2000 14:11:54 -0500
The reason I transmit new keys is to avoid encryption with the same key. I
thought that'd be a good idea.
No?
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Fri, 24 Mar 2000 19:17:54 GMT
Anthony Stephen Szopa wrote:
> So, now, when you try to sell this software to your superiors, in
> the hope of adding value to the company you work for, and getting
> that promotion, raise, and those stock options, I hope I have given
> you enough information in all my posts to give you enough confidence
> to make that pitch a success.
Not really. The Yarrow paper (http://www.counterpane.com/yarrow/ ) gave me
enough information to raise my confidence level, including much info about
possible attacks and what steps were made in the Yarrow design to counter
those attacks. If I were using the Windows platform, I would be using Yarrow
as the random number generator. (I'm not, so I use other mechanisms, such as
the /dev/random available on FreeBSD or Linux, or a PRNG inspired by Yarrow
that I wrote for other Unix platforms using off-the-shelf cryptographic
components).
There are some things that I've recommended buying rather than doing inhouse
(compression algorithms come to mind -- the good ones are patented), but
random number generation isn't one of them. There's just too many good ones
out there in the public domain.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Subject: Breaking crypt(1)
Crossposted-To: comp.security.unix,alt.2600
Reply-to: [EMAIL PROTECTED] (Remove NO_SPAM to reply)
Date: Fri, 24 Mar 2000 19:26:43 GMT
One of my users made the silly mistake of accidentally encrypting a
Very Important File when editing it in vi. Of course, they have no
idea what the encryption key is, though I would expect it's something
like "<ESC><ESC>:q!". Anyway, I've recovered from last night's
backup, but it would be really nice if I could crack the encryption.
I've found the source to Crypt Breakers Workbench (CBW). Only
problem is it's got loads of compile errors when trying to make
it under Irix 6.5.6m. I get _much_ further when compiling on a
SUSE Linux machine with gcc 2.91.66 but it still doesn't complete.
Does anyone know a place I can get the most recent sources for CBW
(mine are kind of old (from October, 1986)) or know of another tool
for breaking crypt(1) encryption?
Damian Menscher
--
--==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign ##==--
--==## <[EMAIL PROTECTED]> www.uiuc.edu/~menscher/ Ofc:(217)333-0038 ##==--
--==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819 ##==--
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: 24 Mar 2000 19:24:56 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>""OTP" is a misnomer" Then why doesn't the Patent Office agree
>with the purists? Look up their definition.
This is SCI.crypt. Get your definitions from actual books
on cryptology, please. The Patent Office is not a cryptologic
organization.
Typically, a "OTP" tends to refer to systems where the number
of key bits is as much as the number of plaintext bits.
I.e., each unit of key information is used "one time."
Using a 64-bit key to encrypt a 1 MB file isn't "one time,"
as each bit of entropy is stretched across multiple plaintext
bits.
Besides, _real_ "one-time pads" are associated with
theoretically perfect secrecy. Someone who uses the term
"one-time pad" to sell a piece of software is, probably,
trying to take advantage of this association.
-X
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 19:35:59 GMT
[EMAIL PROTECTED] wrote:
> You may make CFB and CBC modes sound better than they are. In fact, if you
> know then key and cipher (= E_k) and only two adjactent plain text blocks
> p(n-1) and pn, then you know ahead of time what the cipher block cn will be.
The point of CBC mode is to hide patterns and fight replay attacks (since an
injected block probably won't decrypt to the text that the attacker thinks, a
situation that can be caught with CRC's or whatever). If the attacker knows
the key and cipher then you're screwed anyhow.
> Hence, the complexity is increased compared to ECB mode, but not that much.
> Using a stronger cipher would probably often be a better way to increase
> security than to go from ECB mode to either CBC or CFB mode.
You are correct about CFB mode, which actually reduces security because it
suffers from the same flaws as a one-time pad -- two messages encrypted with
the same keystream (i.e. combination of "salt" and key) can be attacked.
However, CBC mode does not suffer from that problem. To quote Schneier (page
194): "While the IV [for CBC] should be unique for each message encrypted with
the same key, it is not an absolute requirement". As for increasing security,
no amount of increased cipher strength will solve the inherent problem of
replay and visible patterns that come with ECB. It's like that old WWII story
about attacks on Japanese ciphers, where every time spies reported news about
a particular subject, a pattern appeared in the communications. The Americans
could not always decrypt what the message said, but that pattern meant that it
was a message about that particular subject.
> It should also be noted that any cipher in OFB mode is vulnerable to any
> attack that works against OTPs (= one time pads), and some of these attacks
> does not work against a cipher in ECB mode. Hence, for e.g. financial
It depends what you are talking about when you say "OFB mode". If you are
talking about a mode that uses the output of a block cipher as a keystream
generator for a pseudo-one-time-pad stream cipher, such as CFB mode, you are
correct. But CBC does not use the output of a block cipher as a keystream
generator -- it uses the output of the block cipher as, well, the output.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: 24 Mar 2000 19:43:36 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>In article <#t1Uv#Tl$GA.153@cpmsnbbsa02>, [EMAIL PROTECTED]
>says...
>
>> Can I get a reference on that proof?
You can find it in Douglas Stinson's book, _Cryptography:
Theory and Practice."
It basically goes like this: a cryptosystem is considered
"perfectly secure" if, given any intercepted ciphertext c,
the probability that it encodes plaintext p is the same
as the probability of p being sent in general: P(p|c) = P(p).
That is, the ciphertext offers no extra information about
the distribution of possible plaintexts, and so it is worthless
as information; one might as well not intercept c at all and
just randomly guess what p might have been.
Now, if P(p|c)=P(p|encrypt(k,p))=P(p), then P(p,c)=P(p)P(c)
--- that is, ciphertext and plaintext are independent of one
another. Assuming the key is chosen independently from the
plaintext, we simply have
H(k) + H(p) >= H(p, f(k,p)) = H(p,c) = H(p)+H(c)
And so H(k)>=H(c). Since c must eventually be decrypted,
it follows that H(c)>=H(p).
>> 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.
This is kind of backwards. What you really need is
enough key to match the total entropy of the input stream.
After all, the input stream can be compressed all the
way down to the entropy, making its entropy and its
length the same.
-S
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES3 papers
Date: Fri, 24 Mar 2000 14:49:14 -0500
"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.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Fastest DES implementation on Intel PIII ?
Date: Fri, 24 Mar 2000 15:02:01 -0500
Pascal JUNOD wrote:
>
> Hi, I'm seeking the fastest DES implementation on the Intel platform.
Don't know if it's the absolute best, but I'd think it's quite
close at least -- look for Eric Young's libdes, in
ftp://ftp.psy.uq.oz.au/pub/Crypto/DES
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: new Echelon article
Date: Fri, 24 Mar 2000 14:55:27 -0500
John Savard 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...
Well, there's CALEA, which requires carriers to cooperate with
wiretappers. But that doesn't prevent *users* of cellphone service
from applying their own crypto. Quite apart from CALEA, the feeble
crypto skills of that part of the comms industry suggests that using
your own crypto would be wise indeed...
paul
------------------------------
** 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
******************************
