Cryptography-Digest Digest #257, Volume #10 Fri, 17 Sep 99 16:13:03 EDT
Contents:
Re: The good things about "bad" cryptography (Tom St Denis)
Re: crypto export rules changing (Paul Koning)
Re: Comments on ECC (John Myre)
Re: The good things about "bad" cryptography (SCOTT19U.ZIP_GUY)
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Charlie Stross)
Re: Is this key-exchange OK? (Medical Electronics Lab)
Re: unix clippers that implement strong crypto. ("Christopher J. Mattern")
Re: Analogues to ECC over higher dim. abelian groups (Medical Electronics Lab)
Browser encryption explanation needed (Bill Lynch)
Re: unix clippers that implement strong crypto. (Alwyn Allan)
Re: What is XOR? (John McDonald, Jr.)
Re: What is XOR? (Jean-Jacques Quisquater)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The good things about "bad" cryptography
Date: Fri, 17 Sep 1999 15:33:35 GMT
In article
<[EMAIL PROTECTED]>, Eric
Lee Green <[EMAIL PROTECTED]> wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > Would you call some one who designs a million byte plus key method
> > where the whole file is a single block Paranoid.
>
> Yes. Not that it may not be a useful paranoia under certain
> circumstances. Doesn't work for my particular applications in any event,
> I need a combination of speed and "streamability" (i.e., so I can start
> streaming data out before the entire file is encrypted). But then I
> don't have to be too paranoid in my particular case because the file is
> presumably already going over a "secured" network, this is just an
> additional layer of security on top of it...
>
> > Or just some one who
> > wants something better for the real world of file encryption than a toy
> > method that use a tiny key on tiny blocks.
>
> It's a tradeoff. 128-bit blocks allow me to stream data in real time, at
> the cost of being possibly succeptible to known-plaintext attacks and
> possibly other attacks. 19U may actually be more secure than Twofish,
> but it doesn't meet the primary criteria, which is to be able to do this
> in real time.
> As far as key size goes, I stopped at 128-bit key size because I
> don't have more random bits than that in my particular environment.
> 256-bit key size would not have gotten me anything because I had no way
> of generating more than 2**128 possible keys no matter what the key
> length. Again, this is a case where your algorithm would not have worked
> for my particular situation. I'm sure you had to do a lot of work to get
> adequate random bits to make long keys work in your environment (e.g.
> have them wave the mouse around, type random characters, etc.), and I
> don't have access to that kind of stuff (most of my boxes live in wiring
> closets somewhere far from human interaction).
> Which doesn't mean 19U is cr*p, just that it's suited for what it's
> suited for, not for what I'm doing. You must admit that if the goal is
> speed and streamability rather than absolute security, 19U is not the
> right choice.
First off Scottu19 has a 19-bit block, second there is no proof it's any
better then any other cipher out in existance. We have proven it to be slow
and memory intense however.
I would strongly recommend against it in any situation, primarly because it's
inefficient. [cheap plug] like in peekboo I used RC5/cast/blowfish/rc4 and
twofish because they are well designed, documented and efficient. The
executable is only 40kb and it can encrypt messages realtime without taking
more then about 512kb of ram (I think much less but it is windows...).
Now he is going to say 'but nobody has broken scottu' and this is true but I
could simply use RABIN or any large-num thingy for a block cipher, why don't
I? Cuz they are SLOW!!!. I want to encrypt a message now and quick. I want
to have a 1000 copies of the cipher running at once and I want to run them in
under 2MB ... :)
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: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: Fri, 17 Sep 1999 11:45:05 -0400
David Wagner wrote:
>
> In article <VqiE3.5630$[EMAIL PROTECTED]>,
> Dmitri Alperovitch <[EMAIL PROTECTED]> wrote:
> > Um. Question - if they are willing to allow open export of unlimited
> > size keys (except when the destination is a terrorist state), why do they
> > still want a one-time review of your application? If there is no limit on the
> > size of the key you can use anymore, it shouldn't be any of their business
> > about the way you algorithm works or how strong it is, right?
>
> I've heard more than one person conjecture that the main goal of the
> one-time review process is _not_ to review your product for compliance
> with export rules, but rather to gather intelligence about your product.
>
> If they have the source, they can look for buffer overruns, bad RNGs,
> and all sorts of other bugs they can exploit, in case anyone ever uses
> your crypto for anything interesting. And, they get a chance to ask
> you to go change that magic constant in the corner over there before
> you ship...
>
> I see no easy way to confirm or refute this conjecture, but it's an
> interesting hypothesis.
FWIW...
"One time review" is a term that is used in the current export
procedures.
It may be, of course, that the meaning of the term will change. But
right
now in the cases I've been involved in, we did not show our source code
to others. What we did was to supply a fairly brief design spec (mostly
references to RFCs) and answer some followup questions. You definitely
would not be able to find exploitable bugs (or any other kind) from the
information provided.
paul
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Comments on ECC
Date: Fri, 17 Sep 1999 10:03:14 -0600
Alexander S Coventry wrote:
>
> > Alex's query about whether ECC's properties are really proven
> > (whatever *that* means...)
>
> I meant is there a mathematical proof that the time-complexity of any
> algorithm for solving an ECDLP is aymptotically at least exponential in
> the size of the finite field over which the EC is defined. The post I
> was responding to asserted that solving an ECDLP is much harder than a
> hard factoring problem of the same size, and I was wondering whether
> this assertion was absolute, or relates only to current algorithms for
> solving ECDLP's.
Yes, I understood, and I think your question is important. My
parenthetical remark was not directed at your post. I meant to
imply that arguments about the precise definition of "proven" are
not germane. You know how sci.crypt can get out of hand with
stuff like that. Obviously my remark was not well put.
Sorry about that.
John M.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: The good things about "bad" cryptography
Date: Fri, 17 Sep 1999 17:23:48 GMT
In article <7rtn0e$d1l$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article
><[EMAIL PROTECTED]>, Eric
>Lee Green <[EMAIL PROTECTED]> wrote:
>
>> "SCOTT19U.ZIP_GUY" wrote:
>> > Would you call some one who designs a million byte plus key method
>> > where the whole file is a single block Paranoid.
>>
>> Yes. Not that it may not be a useful paranoia under certain
>> circumstances. Doesn't work for my particular applications in any event,
>> I need a combination of speed and "streamability" (i.e., so I can start
>> streaming data out before the entire file is encrypted). But then I
>> don't have to be too paranoid in my particular case because the file is
>> presumably already going over a "secured" network, this is just an
>> additional layer of security on top of it...
>>
>> > Or just some one who
>> > wants something better for the real world of file encryption than a toy
>> > method that use a tiny key on tiny blocks.
>>
>> It's a tradeoff. 128-bit blocks allow me to stream data in real time, at
>> the cost of being possibly succeptible to known-plaintext attacks and
>> possibly other attacks. 19U may actually be more secure than Twofish,
>> but it doesn't meet the primary criteria, which is to be able to do this
>> in real time.
>> As far as key size goes, I stopped at 128-bit key size because I
>> don't have more random bits than that in my particular environment.
>> 256-bit key size would not have gotten me anything because I had no way
>> of generating more than 2**128 possible keys no matter what the key
>> length. Again, this is a case where your algorithm would not have worked
>> for my particular situation. I'm sure you had to do a lot of work to get
>> adequate random bits to make long keys work in your environment (e.g.
>> have them wave the mouse around, type random characters, etc.), and I
>> don't have access to that kind of stuff (most of my boxes live in wiring
>> closets somewhere far from human interaction).
>> Which doesn't mean 19U is cr*p, just that it's suited for what it's
>> suited for, not for what I'm doing. You must admit that if the goal is
>> speed and streamability rather than absolute security, 19U is not the
>> right choice.
>
>First off Scottu19 has a 19-bit block, second there is no proof it's any
>better then any other cipher out in existance. We have proven it to be slow
>and memory intense however.
I guess again little grass hopper you need help. IDEA which is considered
a 64 but cipher only deals with 16 bits at a time. Just becasue scott19u only
works with 19 bits at a time does not make it a 19 bit block cipher. Try
learning something from what you actaully read. And is far as speed it is
slower than many during the table building process. But the actual encryption
is quite fast especially for scott16u. THere have been people who have done
beinchmarks. I can't rember who may be Ritter or Parker. I no long have DES
and never had blowfish on my machine so I have not done benchmarks. I did
do one with IDEA but that is gone now.
>
>I would strongly recommend against it in any situation, primarly because it's
>inefficient. [cheap plug] like in peekboo I used RC5/cast/blowfish/rc4 and
>twofish because they are well designed, documented and efficient. The
>executable is only 40kb and it can encrypt messages realtime without taking
>more then about 512kb of ram (I think much less but it is windows...).
>
>Now he is going to say 'but nobody has broken scottu' and this is true but I
>could simply use RABIN or any large-num thingy for a block cipher, why don't
>I? Cuz they are SLOW!!!. I want to encrypt a message now and quick. I want
>to have a 1000 copies of the cipher running at once and I want to run them in
>under 2MB ... :)
Good for you. Then I would suggest don't use it for peeaboo it was not
meant for everything.
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: [EMAIL PROTECTED] (Charlie Stross)
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Fri, 17 Sep 1999 16:29:39 GMT
Reply-To: charlie @ nospam . antipope . org
Stoned koala bears drooled eucalyptus spittle in awe
as <[EMAIL PROTECTED]> declared:
>"bad people?" C'mon. Saddam Hussein has been "monstorised" by the west, when
>all he is is a clever man,
>who keeps trying to work out ways to improve his country, working out how he
>can sneak around "laws" and aqquired resourced.
And Adolf Hitler was a poor, misunderstood painter, and Stalin was kind
to, um, spiders or something.
(There's an interesting book called "The Republic of Fear" that you could
do with reading. Published before the gulf war, incidentally.)
-- Charlie
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Is this key-exchange OK?
Date: Fri, 17 Sep 1999 12:35:41 -0500
Douglas Clowes wrote:
>
> Gee, I hope that the lack of response means that nobody can see anything
> wrong with it.
>
> I also hope that is because it's OK, rather than too obscure.
It was pretty obscure to me, but that doesn't mean anything.
>
> OK, cryptanalysys challenge: can anybody figure out what it does,and accepts
> that it's OK?
Could you re-write it with some "standard" symbols?
Use || to mean "concatenate"
^ to mean XOR
F(x1, x2, ...) to mean "perform operation F with these inputs"
then specify what A and B do before transmission, what they
actually transmit and what they do after transmission. On very
separate lines. It'd be a lot easier for me to see what it does
then :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Christopher J. Mattern" <[EMAIL PROTECTED]>
Subject: Re: unix clippers that implement strong crypto.
Crossposted-To: comp.security.unix
Date: Fri, 17 Sep 1999 17:47:00 GMT
In comp.security.unix Alwyn Allan <[EMAIL PROTECTED]> wrote:
> Bill Unruh wrote:
>> IDEA is patented. It is illegal to use it without a license.
>> For Blowfish, try Gutman's libcrypt.
> "Illegal" is too strong a word. If you make commercial use of a patented technology,
> and if the patent holder sues for infringement, and if the patent holder prevails in
> the suit, then you can be enjoined by a court against continuing to use the
> technology without a license.
> A lab instument maker I have worked for was advised that they needed $1million to
> mount infringement litigation, even though their patent was stong and the
> infringement clear.
"Illegal but perhaps difficult to prosecute" is *still* illegal...
Chris Mattern
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Analogues to ECC over higher dim. abelian groups
Date: Fri, 17 Sep 1999 13:09:14 -0500
Robert Harley wrote:
> At the moment we are working on counting points in genus 2. We know
> how to do up to about 10^34 points in a few days, by counting modulo
> 40320 using a Schoof-type algorithm and then going at it with a
> birthday-paradox algorithm on a 500MHz Alpha Linux workstation.
How'd you pick 40320? Sounds like a hard problem at any rate!
>
> Here's an example. Take:
>
> y^2 = x^5 + 1597*x^4 + 1041*x^3 + 5503*x^2 + 6101*x + 1887
>
> modulo p = 1000000000000037. Then #J = 999999957656830999779505994685.
>
> But that's tiny. Counting a random group big enough to make the
> discrete logarithm impossible for the next ten years (say) is
> something nobody can do yet, AFAIK.
How can #J be that big? At most there are 5 points on any line thru
a given y, and 2 y's for any x, so that's 10p. Can you try to
explain what I'm missing?
> "Hyperelliptic Cryptosystems"
> Neal Koblitz
> Journal of Cryptology (1989) 1
> -- chooses curves some of which are completely broken (supersingular)
>
> "On the performance of hyperelliptic cryptosystems"
> Nigel Smart
> HP Labs report 98-162
> -- chooses curves in characteristic two with no 2-torsion (a.k.a.,
> "very special") but warns of the danger.
>
> "A Subexponential Algorithm for Discrete Logarithms [etc]"
> Leonard Adleman, Jonathan DeMarrais, Ming-Deh Huang
> Algorithmic Number Theory 1, 1994.
> Springer Verlag LNCS 977
Thanks! Sounds like the bleeding edge, good luck with your
counting algorithm.
Patience, persistence, truth,
Dr. mike
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
fillerfillerfillerfillerfillerfillerfillerfiller
------------------------------
From: Bill Lynch <[EMAIL PROTECTED]>
Subject: Browser encryption explanation needed
Date: Fri, 17 Sep 1999 13:07:55 -0500
Everyone,
Here's how I understand Netscape Navigator (for example) encrypts and
sends data to a trusted server:
Take the info (ie, credit card #) and encrypt it with DES. Then take
that ciphertext and a des key and encrypt that with the merchant's (say
Amazon.com's) public key. Send it. Amazon decrypts the rc5 ciphertext
and then has the des ciphertext and key and then decrypts that.
If that is correct, what i don't understand is why they go through the
step of the DES encryption since the cc# is transmitted securely via rc5
(seems redundant). Is it for verification?
I consider myself relatively new to this subject - so please no flame
mail if my question is too obviously easy to answer. :)
Thanks in advance,
--Bill Lynch
------------------------------
Date: Fri, 17 Sep 1999 11:06:02 -0400
From: Alwyn Allan <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: unix clippers that implement strong crypto.
Bill Unruh wrote:
> IDEA is patented. It is illegal to use it without a license.
> For Blowfish, try Gutman's libcrypt.
"Illegal" is too strong a word. If you make commercial use of a patented technology,
and if the patent holder sues for infringement, and if the patent holder prevails in
the suit, then you can be enjoined by a court against continuing to use the
technology without a license.
A lab instument maker I have worked for was advised that they needed $1million to
mount infringement litigation, even though their patent was stong and the
infringement clear.
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: What is XOR?
Date: Fri, 17 Sep 1999 16:58:00 GMT
On Fri, 17 Sep 1999 12:22:46 GMT, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>BTW, the OR symbol is an upsidedown v and the AND is a v (or is that
>backwards they always confused me... I like the | and & symbols )
a ^ b == a & b
a v b == a | b
I remember it because v is closer to 'o' than to 'a' (as in or).
That carret really should be further down to be and, because some
people like to use the ^ to mean XOR... Of course the symbol I learned
is (+) (close the circle), but whatever.
Hope this helps.
(PS: I prefer the + for OR and the � for AND... The notation just
makes a whole lot more sense to me...)
---
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
--
"I speak for me and not this company"
TO SPAMMERS:
Please note important defininitions:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Subject: Re: What is XOR?
Date: Fri, 17 Sep 1999 21:20:04 +0200
Oh, oh.
For me (and many people I'm sure :-)
OR (in French OU) is denoted by \/ (V) and is coming from Vel (the latin OR)
and
AND is the opposite (converse, inverse, complement, ...) and it is easy
to remember it because as said A is like /\.
(the notation is coming from the notation for max and min in a lattice).
Thinking in terms of Boolean algebra:
OR is like max (meet or sum)
AND is like min (join or product)
------------------------------
** 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
******************************
