Cryptography-Digest Digest #386, Volume #9 Tue, 13 Apr 99 22:13:04 EDT
Contents:
Re: LFSR polynomial testing (Terry Ritter)
Re: Blowfish Source Code? (Casey Sybrandy)
SNAKE#6 is oil as well, SNAKE#7 hisses into life (Peter Gunn)
Re: SCRAMDISK question (Paul Koning)
Re: Comments to DOJ re NICS (Eric Williams)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: a simple sequence that stays near zero ([EMAIL PROTECTED])
Re: a simple sequence that stays near zero ([EMAIL PROTECTED])
Re: discreate logarithm problem ([EMAIL PROTECTED])
PGP, The Big Lie (Theorem with Incomplete Proof) ("Charles Booher")
PGP 6 DO NOT USE!!! ("Charles Booher")
PGP 6 Is garbage ("Charles Booher")
Re: HELP ME! ("Charles Booher")
You are asking the wrong question. ("Charles Booher")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: LFSR polynomial testing
Date: Wed, 14 Apr 1999 00:15:57 GMT
On Tue, 13 Apr 1999 22:19:42 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
(Philip Koopman) wrote:
>[EMAIL PROTECTED] wrote:
>>I found a program on the net for testing LFSR polynomials, it isn't a really
>>helpful program (works backwords....), anyways, I was wondering if anyone had
>>a program to test for valid LFSR polynomials (LFSRs of any bit length)? In C
>>would be the best, or MS-DOS .EXE format.
>
>I have complete primitive polynomial lists of the smaller ones and
>samples of medium-size ones at http://www.ices.cmu.edu/koopman/lfsr/ as
>well as C source code.
>
>However, the bad news is that the algorithm I used was brute force
>search (is that what you mean by "works backwards"?). Once you get
>above about 40 bits you can just forget it. If anyone has something
>more efficient I'd be interested in seeing it. (I can easily believe
>that one can be more efficient than brute force; but it did the job for
>what I needed and I didn't have time to be fancier.)
There is an efficient algorithm in my crypto glossary:
http://www.io.com/~ritter/GLOSSARY.HTM#PrimitivePolynomial
also see the many related and linked terms.
And there are many references in my crypto RNG article:
http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect6.5
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Casey Sybrandy <[EMAIL PROTECTED]>
Subject: Re: Blowfish Source Code?
Date: Tue, 13 Apr 1999 19:28:49 -0400
www.counterpane.com
This is the company that made it. I believe that it is C/C++ code.
Jon Kadilak wrote:
> I'm not sure if this is the right group to post to, apologies if it is
> not. Can someone point me in the direction of some Blowfish encryption
> algorithm source code? Or some source code that will encode files with
> the Blowfish encryption method.
>
> --
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Jon Kadilak The Internet Access Company
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: SNAKE#6 is oil as well, SNAKE#7 hisses into life
Date: Wed, 14 Apr 1999 01:14:35 +0100
Thomas Wu wrote:
> Peter Gunn <[EMAIL PROTECTED]> writes:
> > "Roll up, Roll up, come and try the new miracle elixer..."
> >
> > Thanks to Bryan & Thomas for pointing out that key=H(P,<DH private>)
> > is easily cracked when <DH private> is known and P is short.
> >
> > I order to stop a man-in-the-middle calculating <DH private>
> > I would have to munge the <DH public>s with P... which
> > basically leads to EKE and friends.
>
> Either that or go to an asymmetric scheme like SRP or B-SPEKE, yes.
>
> > [ NOTE: ^ means to-the-power-of, % means mod ]
> >
> > 1) A->B: y1=(g^x1)%p, U, z1=(g^H(P,x1))%p
> > 2) B: z2=(g^H(P,x2))%p, key=H((y1^x2)%p)
> > 3) B->A: y2=(g^x2)%p, z2
> > 4) A: key=H((y2^x1)%p)
> >
> > What happens is...
> >
> > 1) Client sends to Server his DH public value y1,
> > his user identifier U, and z1=(g^H(P,x1))%p
> > 2) Server looks up user list using U to find password P,
> > to work out z2=(g^H(P,x2))%p, disconnecting the client
> > if (z1^H(P,x2))%p != z2.
>
> I'm not sure I follow here: If z1 = g^H(P,x1), then
> z1^H(P,x2) equals g^[H(P,x1)*H(P,x2)]. You have z2 = g^H(P,x2),
> though, so the server always ends up disconnecting the client
> unless H(P,x1) == 1.
>
> There's no way for the server to authenticate z1, since the
> server doesn't know x1.
Many thanks for the reply, dont know what happened there,
my brain failed for some reason... engineers are currently
investigating the problem :-)
I am starting to come to the conclusion though that I am naturally
skilled at producing vast quantities of snake oil, without intending
to do so. There is probably several different thesis in this just
awaiting documentation by a brave psychologist ;-)
Funnily enough, SNAKE#5 failed to accurately document my intentions...
which was something like the following snake oil... only small problem
I can see is that the c1 & C2 values which were intended to show
proof of possesion of P actually do no such thing... here it is anyway...
SNAKE#6...
1) A->B: y1=(g^x1)%p, U, z1=(g^H(P,x1))%p
2) B: z2=(g^H(P,x2))%p, key=H((y1^x2)%p)
3) B->A: y2=(g^x2)%p, z2, c2=(z1^H(P,x2))%p
4) A->B: c1=(z2^H(P,x1))%p
5) A: key=H((y2^x1)%p)
What happens is...
1) Client sends to Server his DH public value y1,
his user identifier U, and z1=(g^H(P,x1))%p
2) Server looks up user list using U to find password P,
to work out z2=(g^H(P,x2))%p, disconnecting client if
U is not found.
3) Otherwise, he returns his DH Public value along
with z2, and works out the DH secret value.
4) Client works out c1=(z2^H(P,x1))%p, and disconnects if
c1 != c2.
5) Otherwise Client sends c1 to Server, which disconnects
if c1 != c2.
==============================================================
But wait, there is more... SNAKE#7
Ok, Im still on trying to authenticate the Server and Client
by proving to one another that they both know the user's
password P... without spilling the beans to this Ted guy
who is always snooping in on peoples conversations (what is
the relationship between Ted & Alice anyway? sounds to me like
somethings going on there :-)
So, how am I going to prove possesion of P...
Ideas...
#1 => Encrypt DH public values (but thats just EKE)
#2 => exchange H(P,x)... x would need to include DH public
in order to verify its origin... and some other
info (salt?) to stop it being broken because of
short P. H(P,key) is no use since MITM knows key,
but what about (g^H(P,key))%p?? This doesnt look
easily reversed when key is known...
SNAKE#7 here we go...
x1 is a random number (<p-1)
x2 is a random number (<p-1)
g is an agreed 'generator' (<p-1)
A is the Client.
B is the Server.
H() is a one way crypto hash function (SHA or similar)
p a fixed large safe prime
key is the resulting shared key
U is the userid (short, probably <=8 chars)
P is the user's password (short, probably <=8 chars)
1) A->B: y1=(g^x1)%p, U
2) B->A: y2=(g^x2)%p
3) A: key=H((y1^x1)%p)
4) B: key=H((y2^x2)%p)
5) A->B: H(g^H(P,key))%p)
6) B->A: H(g^H(P,key))%p)
What happens is...
1) Client sends DH public value, and user identifier to
Server.
2) Server returns its DH Public value.
3) Client works out DH private value and hashes for key.
4) Server works out DH private value and hashes for key.
5) Client sends H(g^H(P,key))%p) to server which disconnects
if it doesnt match its own calculation.
5) Server sends H(g^H(P,key))%p) to client which disconnects
if it doesnt match its own calculation.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: SCRAMDISK question
Date: Tue, 13 Apr 1999 11:45:59 -0400
Subscriber wrote:
>
> After downloading version 2.02h from the download
> page, I notice the zip file has two files within:
>
> 1 - SdInstal.exe
> 2 - sd.vxd
>
> When I first tried running the SdInstal program, it came
> up with some error screen about not finding the sd.vxd
> file. I followed the instructions about placing that file into
> my IOSUBSYS file and rebooted, then I tried running
> the SdInstal program again. ...
You masically did what the install program does.
The intended use is very simple: unzip the zip file (both
files in it) into a scratch directory. Run sdinstal there.
It will ask you a very small set of questions, move
itself one place and sd.vxd another, and you're all set.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "Be wary of strong drink. It can make you shoot at tax collectors
! -- and miss!"
! -- Robert A. Heinlein, "The Notebooks of Lazarus Long"
! in "Time Enough for Love"
------------------------------
From: Eric Williams <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.guns
Subject: Re: Comments to DOJ re NICS
Date: Tue, 13 Apr 1999 16:37:43 -0700
Paul Rubin wrote:
> Credit card verifications involve the card number, expiration date,
> and amount going in one direction, and a 6-digit authorization code
> coming back. Note that at most retailers these days, this is done
> automatically--the merchant swipes the card through a reader and keys
> in the amount. The authorization code (if approved) is automatically
> printed on the ticket. At places with no card reader, they normally
> don't phone in the card numbers unless the transaction is over a
> certain amount. (Because of the increased exposure, they pay a higher
> fee to the card company than if they had a card reader.)
>
> In your system, the stuff going to the DOJ in place of the card number
> and expiration date would be *all* the data from the form (name, address,
> etc.) plus the MAC. Also, in the case of a field audit of a dealer,
> they'd want to verify a whole stack of registrations and not just
> a single one. So it's just not workable unless the data is machine
> readable.
How can you say it's unworkable? FFLs are *ALREADY* transmitting all
that information to the DOJ. The only difference in my plan is how the
DOJ handles it once it gets there. On the other side of the
transaction, once the background check is completed, there is a long
digit/character string that is sent back to the FFL for him to record.
But there is *ALREADY* a "NICS Transaction Number" that the FFL needs to
record, so, again, there is no real difference in procedure, only a
requirement for some measure of improved accuracy compared to existing
transfers.
And ATF does not verify whole stacks of registrations, they spot-check
the records of the FFL (unless there is evidence of wholesale fraud, in
which case they're no worse off than they are under the current system).
> >I think a MAC would be sufficient for this application, the key (or
> >keys) would remain with DOJ. Since the government is the only party who
> >is interested in generating and verifying signatures, I don't think the
> >complexity of a public key system is necessary.
>
> I guess that's plausible. It means though that field auditors have
> to carry equipment containing the secret key. If the auditors can be
> robbed or bribed, the key is vulnerable.
Not at all, they only need to transfer the information from the form to
the DOJ, who will re-calculate the MAC and read it back for
verification. If key vulnerability is still a problem, the keys can be
changed every day. (Or even for every transaction -- it doesn't matter
as long as DOJ saves the keys.) Compromising a single key would not
give you the ability to generate MACs for future gun transfers.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Wed, 14 Apr 1999 01:09:43 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 14 Apr 1999 00:04:50 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>For example, based on your statement above, it appears that you
>>don't believe that a quantum computer programmed to calculate a true
>>random number is proveably secure?
>>Please explain why you think that..
>No.
Then we must conclude that your comments in that regard are not
"expert".
At least you are honest about the limits of your understanding, which
is something more than we can say about the other "experts" around
here.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: a simple sequence that stays near zero
Date: Wed, 14 Apr 1999 01:08:37 GMT
In article <7f09l8$ko5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7evj32$vi6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> Right! Q must be a real number with -1 < Q < 1. Right, the numbers
> just lie on a sine wave. The amplitude of the wave is 1/sqrt(1-QQ).
> I should have seen that before because an amplitude of 1 would have
> forced a_1 = sqrt(1-QQ). Q doesn't have to be rational.
How dou you suggest we might use this for crypto purposes if
Q isn't rational?
> You could do the same thing by just taking powers of (Q,i*sqrt(1-QQ)),
> but that's slower. Also, the recurrence I gave isn't the only stable
> one, ones with more terms work too. I don't know if having more terms
> makes for a more interesting sequence. I suspect not.
No, but one could use Pisot sequences or choose the polynomial so
its roots are P-V numbers.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: a simple sequence that stays near zero
Date: Wed, 14 Apr 1999 01:09:01 GMT
In article <7f09l8$ko5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7evj32$vi6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> Right! Q must be a real number with -1 < Q < 1. Right, the numbers
> just lie on a sine wave. The amplitude of the wave is 1/sqrt(1-QQ).
> I should have seen that before because an amplitude of 1 would have
> forced a_1 = sqrt(1-QQ). Q doesn't have to be rational.
How do you suggest we might use this for crypto purposes if
Q isn't rational?
> You could do the same thing by just taking powers of (Q,i*sqrt(1-QQ)),
> but that's slower. Also, the recurrence I gave isn't the only stable
> one, ones with more terms work too. I don't know if having more terms
> makes for a more interesting sequence. I suspect not.
No, but one could use Pisot sequences or choose the polynomial so
its roots are P-V numbers.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: discreate logarithm problem
Date: Wed, 14 Apr 1999 01:32:58 GMT
In article <7f04b4$fnd$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> > I'm a begineer in cryptographic area.
> > and I have a question related with discreate logarithm.
> > In the presentation, y=g^x mod n,
> > It is easy to compute y from x but computing x from y is very difficult.
>
> If gcd(g, n) = 1 yes. Also g^x = 1 (mod P)
>
Where did P come from?? What makes you assert g^x = 1 mod P?
> > This is the discreate logarithm problem.
>
> Not to be picky... Discrete Logarithm Problem (you spelt it wrong...)
>
Not to be picky, but you shouldn't criticize the spelling of others
when your spelling is wrong. (e.g. 'spelt'). I recall a parable about
people who live in glass houses.....
Also, you should not criticize others' spelling when your math is (grossly)
wrong.
> >
> > If that is so, What is the time complexity of
> > discreate logarithm problem?
>
> Hard. You have to try all the possible combinations that would make y.
Where did you get this piece of mis- information?
Assuming n is prime, the complexity of solving the DL problem is:
g(n) := exp( (c + o(1)) (log n)^1/3 (log log n )^2/3)
where c = (64/9)^1/3
via the Number Field Sieve.
If n isn't prime, factor it. The complexity is then
time to factor n + sum of g(p) for all p dividing n
i.e. solve the DL for each prime factor, then use the CRT.
>
> > and if g is not a primitive root modulo m, (sic; this should be n)
> > How is the time complexity changed ?
>
> Easier. Since you eliminate alot of possibilities. Given gcd(g, n) = 1, each
> output (y) is equal probable (meaning find x is hard).
Your second sentence here is gibberish. Where does probability enter?
More mis-information. The complexity does not change. But y does
have to be in the orbit of g for a solution to exist. i.e. y might not be in
the sub-group generated by g.
(I ignore special, very small subgroup attacks because unless the order of
g is very small, general methods in the full group will still be faster)
>
> I am a beginner (sorta, I have about 1 year experience... :) )
So why didn't you check sources before posting your (incorrect)
reply?
I suggest you do some reading as well. It is not fair for you to mislead
other novices.
> > if g is now known, how is it differ?
>
> G can be known. Usually it's 2, 17 or 65537
Huh? I'll assume that your use of G (as opposed to g) is a typo. However,
your assertion that 'G can be known' is misleading. g is ALWAYS known. And
your assertion that it is usually 2,17 or 65537 is also wrong. It looks as
if you have this confused with (some of) the commonly used public exponent
values for RSA.
Do us all a favor. Don't answer technical questions until you have studied
the subject. It will save me time from having to write corrections.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP, The Big Lie (Theorem with Incomplete Proof)
Date: Tue, 13 Apr 1999 19:12:15 -0700
Theorem: There is no PGP Book.
It is claimed by previous Network Associate Personnel that PGP the book in
source form was available from Printers Inc. In Palo Alto.
Poof:
I am going to go into Printers Inc. with a video camera in Palo Alto in the
near future and attempt to the Book. If it ain't their I am going to assume
that such a book does not exist.
Lemma to support Proof:
The dumb asses at PGP gave me some shit that they call source code. None of
it builds, but hey, Windows is not really all that important.
I also noticed that the PGP server in Norway is not NAI.
Those corrupt swine at NAI are probably also responsible for the Mellisa
virus, but hey, who am I to judge the malevolent intent of another
programmer.
SOME ADVICE TO THE AUTHOR OF MELLISA:
Tell your story to the Grand Jury, I did and I feel so much better for it.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP 6 DO NOT USE!!!
Date: Tue, 13 Apr 1999 19:13:46 -0700
1,000,000 possible key pairs.
I am certain that the NSA has them all computed by now.
Boy and they make it so easy and quick to get your key indexed off of a
server.
Use PGP go to jail.
Use SecureOffice if you want to stay out of jail.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: PGP 6 Is garbage
Date: Tue, 13 Apr 1999 19:17:15 -0700
PGP 6 will only generate around 1,000,000,000 possible key pairs.
I am certain that the NSA has run all the possible sets.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: Re: HELP ME!
Date: Tue, 13 Apr 1999 19:23:22 -0700
H(K, P, C) = H(C|K, P) H(K,P).
Is true only for a restricted subset. You can always find a Mapping that
will have this property.
The questions, when applying this relationship to a mapping H, on the sets
K,P,C are
1. Is the set finite? (Dependent on H, Dependent on K,P,C)
2. Is the set contiguous? (Dependent, again on H, K, P, C)
3. If the set is contiguous for a particular subset then is it the entire
set Piece wise contiguous? (Again Dependent on H,K,P,C)
You will need to refine your problem further in order to gain any
understanding of the issue at hand,.
You people really need to get back to basic analysis and point set topology
before you hurt yourself.
------------------------------
From: "Charles Booher" <[EMAIL PROTECTED]>
Subject: You are asking the wrong question.
Date: Tue, 13 Apr 1999 19:24:32 -0700
Before you asking this question you really should be asking another
question.
What will happen to me if SSL is not secure?
------------------------------
** 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
******************************
