HDTenEightyP/NetNews huggingface dataset:
From: res@colnet.cmhnet.org (Rob Stampfli)
Subject: Re: Limits on the Use of Cryptography?
Organization: Little to None
Date: Tue, 15 Dec 1992 03:43:58 GMT

>>Iain McCord raises the possibiity that the police will "plant" an
>>encrypted file, or worse, plant an incriminating encrypted file of 
>>their own design.
>>
>>This is not a cryptographic issue. They could do the same with any
>>other kind of evidence. One's protections against this are also
>>the same, including the ability to challenge the 'chain of evidence'
>>in court, the ability to introduce contrary evidence, etc.
>
>Oh, but it IS a cryptographic issue.
>
>With a public key system you can be ABSOLUTELY certain that a particular
>ciphertext was created with one key if you can decode it with the other.
>Therefore, if the keys are not compromised you can, with certainty,
>prove whether or not it was written by the individual in question.

I am going to presume you are talking about "signing" a message.  If you
are talking about using a public key to encrypt a message, then presumably
anyone could have done this.

While I am not going to try to refute the essance of what you say, I think
you make a giant leap of faith with your supposition "if the keys are not
compromised".  It is darn neigh impossible to conclude this once you no
longer have control of the computer.  If the police are of a mind to, they
could generate a public/private key pair, sign a message with it, and
claim it was signed by you.  "How can you prove it was signed by me?"
"Because it can be decrypted with your public key"  "How do you know that
is my public key?"  "It was on your own public keyring with you as the
indicated owner."

Once the police have sole control over the computer, if the police are both
technically competant and corrupt, all bets are off:  Your defense is to
convince a jury that the police have not been impartial.  About the only
thing cryptography adds in this regard is a degree of complexity that makes
it beyond the scope of the average judge and jurist to understand.
-- 
Rob Stampfli  rob@colnet.cmhnet.org      The neat thing about standards:
614-864-9377  HAM RADIO: kd8wk@n8jyv.oh  There are so many to choose from.
From: luckey@rtfm.mlb.fl.us (Jon Luckey)
Newsgroups: sci.crypt
Subject: Re: More RSA questions
Date: 20 Dec 92 18:26:59 GMT
Organization: We don't need no stinkin' batches!

Pat_Barron@transarc.com writes:

>I was tinkering around with the RSA algorithm last night, using really
>small primes (e.g., 13 and 17) to generate keys.  The idea was that I
>only wanted to use a 16-bit modulus, so I could avoid doing any
>extended precision arithmetic, and so I could do the exponentation via
>a naive "compute x^y by looping and multiplying by x, y times
>(remember, this is just a toy implementation, and it's not intended
>to do any "real" work).  But I ran into a few snags:

>1)  During the exponentiation, the numbers get *really* big.  Like, I
>was shocked at how quickly they got big.  Is there any shortcut for
>computing m^e mod n, without actually computing m^e first?  Like, can
>I loop somehow, accumulating partial results, until at the end I have
>the value m^e mod n, without having actually computed m^e first?  Even
>if I choose, say, 3 or 5 as the private key, the public exponent tends
>to be big enough that m^e is way beyond the capacity of a 32-bit
>unsigned integer.

> [another RSA question ommitted]

There are already a few replies to your message giving better
ways to calculate z=x^y mod n.  But if all you want to do is simply
modify your original program, keeping your brute force expotentiation
method, then just do a modulus after each multiply.

I.E change your code that looks like

      Z:=1;
      FOR I:= 1 TO Y DO Z:= Z*X;

into
      Z:=1;
      FOR I:= 1 TO Y DO Z:= (Z*X) MOD N;

which will keep you from running into interactions with the implict
modulo that computer interger arithmatic involves.

you might even be able to stay within 16 bit integers and not have to
worry about 32 bits at all.
Newsgroups: sci.crypt,alt.security.pgp
From: strnlght@netcom.com (David Sternlight)
Subject: Re: PKP/RSA comments on PGP legality
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Tue, 15 Dec 1992 18:38:43 GMT


Since posting the previous message I've heard from a couple of
people that Miller's role in the pgp list is a mechanical/administrative
one and not a substantive/moderator one.

Apologies to those on that list who felt lumped in with my comments
about Miller.

David
From: tsa@cellar.org (The Silent Assassin)
Newsgroups: sci.crypt
Subject: RSA questions
Date: 15 Dec 92 00:47:07 GMT
Organization: The Cellar BBS and public access system

I read the article in popular mechanics and have a few questions about how
RSA works.  You take the ASCII value of the number, raise it to an arbitrary
high power, and mod it by the public key, correct?  But how do you decrypt
it?

I finally discovered, at the age of 21, what all of my friends had found out
at 12 or 13-that your parents are just as fucked-up and wierd as everyone
else.  Politically Correct:  Socially, Politcally, and Environmentally
concious to the point of nausea.  tsa%cellar@tredysvr.tredydev.unisys.com
Newsgroups: sci.crypt,alt.security.pgp
From: uni@acs.bu.edu (Shaen Bernhardt)
Newsgroups: sci.crypt
Subject: Re: Spies using PGP
Date: 15 Dec 92 18:32:40 GMT
Organization: Boston University, Boston, MA, USA

In article <1992Dec10.064145.21209@fasttech.com> zeke@fasttech.com (Bohdan Tashchuk) writes:
>In <2229.517.uupcb@grapevine.lrk.ar.us> jim.wenzel@grapevine.lrk.ar.us (Jim Wenzel)  writes:
>
>>    Other interesting note.  He spoke with the FBI  about the matter and
>>    they indicated that they have also run into PGP. Once case involving
>>    espionage.
>
>In hindsight, I guess this is quite obvious.
>
>WOW. I don't envy the FBI. Their job is getting a lot harder. While I don't
>agree with their wiretap proposals I can now understand, a little, why they
>are so determined to get them.  (Please, no more FBI wiretap discussion here!)




It's real hard for me to understand why this hasn't been asked yet:

So did they break PGP and charge someone with espionage or what?

uni
-Dark-
-- 
uni@acs.bu.edu  ->  Public Keys by finger and/or request
Soverignty is the sign of a Brutal Past.
Newsgroups: sci.crypt
From: strnlght@netcom.com (David Sternlight)
Subject: Re: PKP/RSA comments on PGP legality
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sat, 19 Dec 1992 06:02:26 GMT


Marc VanHeyningen asks "what license fee?" for RSAREF.

I guess I have to spell it out. Some have argued that the most PKP
could collect in a successful patent lawsuit is damages, i.e. license
fees not paid, i.e. zero since RSAREF carries none.

My post pointed out that PKP could also get legal fees.

David

Newsgroups: sci.crypt,alt.security.pgp
From: strnlght@netcom.com (David Sternlight)
Subject: Re: PKP/RSA comments on PGP legality
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Thu, 17 Dec 1992 00:14:31 GMT


In response to Christopher Davis, yes, I believe the RSA patents expire
in 1997.

Newsgroups: sci.crypt
From: betz@gozer.idbsu.edu (Andrew Betz)
Subject: Re: drug dealers on the high seas (was Risks of Using PGP 2.0)
Organization: SigSauer Fan Club 
Distribution: usa
Date: Mon, 14 Dec 1992 22:34:45 GMT

In article <BD.92Dec14070358@fluent.UUCP> bd%fluent@dartmouth.EDU writes:
>Ear, Nose and Throat M.D.s use it too, as a local
>anesthetic for nasal surgery.  They buy it from medical 

this is absolutely correct.  i have a friend that had a broken nose
misheal, and they had to rebreak it (i always ribbed him about getting
a nose job!).  the docs packed it with a tape that was sprinkled with
cocaine as a local anesthetic.

drew 
--
betz@gozer.idbsu.edu
*** brought into your terminal from the free state of idaho ***
"Now I am become death, destroyer of worlds." - Oppenheimer

Newsgroups: sci.crypt
From: strnlght@netcom.com (David Sternlight)
Subject: Re: PKP/RSA comments on PGP legality
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 18 Dec 1992 23:06:42 GMT


Arthur Rubin says:
" R should then have been prosecuted for
writing his Scientific American article, as Scientific American is sent
world-wide."

In this he fails to distinguish between ideas and algorithms (permitted
via footnote in ITAR) and programs and software code (specifically
prohibited).

David
Newsgroups: sci.crypt
From: gerben@rna.indiv.nluug.nl
Subject: Re: PKP/RSA comments on PGP legality
Organization: G.R.O.S.S.
Date: Sun, 13 Dec 1992 15:31:44 GMT

Hopefully, the US Congress will ban software patents altogether *), making  
political issues like the legality of using a cypher at all the only question left.

*) Not much hope, since the text of the GATT treaty does not offer the possibility  
to exclude *anything* from patentability (except in the case of national  
emergencies).

-- 
Gerben Wierda                 Tel. (+31) 35 833539
  "If you don't know where you are going, any road will take you there."
  From the Talmud(?), rephrased in Lewis Carroll, "Alice in Wonderland".

Newsgroups: sci.crypt
From: robert.heuman@rose.com (robert heuman)
Subject: RFD:comp.security.ema
Organization: Rose Media Inc, Toronto, Ontario.
Date: Fri, 18 Dec 1992 07:26:35 GMT
X-Gated-By: Usenet <==> RoseMail Gateway (v1.70)


Date Entered: 12-18-92 02:15
Ran Atkinson <atkinson@itd.nrl.navy.mil> wrote:

RA> PROPOSAL:
RA> Create a new newsgroup:   comp.security.email
RA> Moderation status:        unmoderated
RA> Charter:                  Discussions of security issues in electronic
RA>                           mail, discussions of applications software
RA>                           purporting to provide additional security in
RA>                           electronic mail, discussions of security issues
RA>                           in SMTP and ESMTP.

I personally am against it. It will simply end up being a 4th 
conference carrying the same material, and one more for me to go 
through on a daily basis.  Personally I wish that .crypt carried all of 
the material, and I would NOT find it replicated in alt.security, the 
pgp conference, etc.  As all of the discussion revolves around privacy 
through the use of cryptology, and .crypt is the conference for 
discussion of cryptology, lets END THE REPETITION. That, in any event, 
is MY independent vote.  I suggest that this ALSO be a proposal to be 
voted on. Finding the same 70 messages in three conferences today is a 
case in point!

Bob Heuman <robert.heuman@rose.com>
---
   RoseReader 1.70 P001886: This Canadian has an Opinion...His Own!
   RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
Newsgroups: sci.crypt,alt.security,alt.security.pgp
From: moore@cs.utah.edu (Tim Moore)
Subject: Re: PGP as a World Standard
In-reply-to: mathew's message of Fri, 18 Dec 92 15:24:21 GMT
Organization: University of Utah CS Dept
Date: 18 Dec 92 10:15:41

In article <aZHZVB15w165w@mantis.co.uk> mathew <mathew@mantis.co.uk> writes:

    PGP
   does not use any techniques which are patented in the EC.

The IDEA cipher is patented in Switzerland.  I admit that I don't know
if Switzerland is considered part of the EC or not.

From pgp21/src/idea.c:

 *	The IDEA(tm) block cipher is covered by a patent held by ETH and a
 *	Swiss company called Ascom-Tech AG.  The Swiss patent number is
 *	PCT/CH91/00117.  International patents are pending. IDEA(tm) is a
 *	trademark of Ascom-Tech AG.  There is no license fee required for
 *	noncommercial use.  Commercial users may obtain licensing details
 *	from Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502
 *	Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761.

--
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush
Newsgroups: sci.crypt,alt.security.pgp
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: Re: PKP/RSA comments on PGP legality
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Sun, 20 Dec 1992 11:59:04 GMT

In article <1992Dec19.002110.17682@netcom.com>, strnlght@netcom (David Sternlight) writes:
>I said that government takes cryptographic violations of munitions
>laws much more seriously than the building of airplane models.
>
>Steve Gardner's response that nobody is harmed by cryptography is
>appalling. Consider the lives lost or saved through cryptographic
>activities during wars, anti-terrorism, drug enforcement, etc.

Youy are apparently talking about the violence done by the U.S.
government.  Yes, it is true that many lives have probably been lost
and ruined with the help of cryptography, but on the other hand
cryptography is a very useful tool in fighting against the kinds of
oppression and terrorism you are talking about.  I'd say it levels the
field somewhat.

//Jyrki
Newsgroups: sci.crypt
From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: Multiple-round DES
Date: Wed, 16 Dec 1992 20:59:32 GMT
Reply-To: lwloen@rchland.vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <6703@tuegate.tue.nl>, bartjan@blade.stack.urc.tue.nl (Bartjan Wattel) writes:
|> Hi,
|> 
|> This question sort of belongs to my other question(s) in "Enlarging key size
|> of the DES".
|> 
|> Does anybody know publications about multiple-round DES and/or implementations
|> of it ?
|> 
|> If someone has other interesting info about multiple-round DES, all information
|> is welcome !!
|> 
|> Thanks in advance,
|> 
|> Bartjan Wattel at Eindhoven University of Technology, the Netherlands
|> (Email: bartjan@blade.stack.urc.tue.nl)
|> --------------------------------------------------------------------------------
|> 
|>                     You may be insane, but you're not crazy.

Merkle and Hellman are said to recommend the following:

   ciphertext =  DESEncrypt(k1,DESDecrypt(k2,DESEncrypt(k3,plaintext)));

and that this step be substituted wherever one does  
   
   ciphertext = DESEncrypt(kx,plaintext);

today.

I don't know exactly how much additional security this gives.  For instance,
there are known problems with the obvious:

   DESEncrypt(k1,DESEncrypt(k2,plaintext))
   
and claims of problems with:

   DESEncrypt(k1,DESDecrypt(k2,DESEncrypt(k1,plaintext))) 

(I say "claim" in the second case only because I haven't had time to read
that particular literature :-) ).  In the first case, at least, a table of
2 to the 67 bytes will keep the decryption in the range of 2 to the 55th 
average iterations.

Based on those issues, I would guestimate that Merkle & Hellman's security 
is probably around 2 to the 112 iterations, assuming no shortcut is found 
for the underlying DES proper or for the joint cipher.  Does anyone know
how many iterations Merkle and Hellman claim for the scheme?

This is the simplest approach to increasing DES key size I know of and it
is "off the shelf" with a correct protocol in the implementation of it.

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: sci.crypt
From: violett@indiana.edu (AJ Violette)
Subject: Anyone have a FAQ?
Reply-To: violett@indiana.edu
Organization: Indiana University, Bloomington
Date: Fri, 18 Dec 1992 17:52:28 GMT


Does someone out there have an FAQ for this newsgroup that they can mail me or 
repost?  Thanks.
	
Andrew Violette
violett@ucs.indiana.edu

Newsgroups: sci.crypt,alt.security.pgp
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: RSA Data Security Not All Bad
Organization: /usr/local/lib/news/organization
Date: Fri, 18 Dec 1992 21:57:46 GMT

strnlght@netcom.com (David Sternlight) writes:
>In article <SOWA.92Dec17133825@netcom.com> sowa@netcom.com (Erik Sowa) writes:
>>
>>Then the export restriction isn't protecting much, either.
>>
>referring to piracy of products overseas.
>
>I don't know if I understand him correctly, but it seems to me
>that's arguing that if there are lots of thieves one shouldn't
>bother with locks.

Locks actually work in detering theft. Export restrictions on things
that can be transported by phone line do virtually nothing. They are a
joke. Unlike locks, which are successfull, such regulations succeeds
only in breeding contempt for the law.

--
Perry Metzger		pmetzger@shearson.com
--
"They can have my RSA key when they pry it from my cold dead fingers."
Newsgroups: sci.crypt
From: sscalsk@nswc-wo.? (Stanley Scalsky)
Subject: RSA alternative
Organization: NSWC White Oak
Distribution: sci
Date: Fri, 18 Dec 1992 15:43:00 GMT

Not to get off the facinating PGP legality thread but ...


In the Jan'93 issue of Dr. Dobb's Journal there is an interesting
article on LUC public-key encryption. From the article ...

"RSA has dominiated public-key encryption for the last 15 years as research
has failed to turn up a reliable alternative - until the advent of LUC.
Based on the same difficult mathematical problem as RSA, LUC uses the
calculation of Lucas functions instead of exponentiation.

Becasue we're working in the area of mathematics, we can formally prove
that LUC is a true alternative to RSA. Furthermore, we can show that a
cipher based on LUC will be at least as efficient. ..."

Anyway it seems timely. There is a good explanation in "How the Lucas
Alternative Works" within the article and some code.

See the article for further information.

We now return to the catfight ...

stan      sscalsk@nswc-wo.navy.mil
From: strnlght@netcom.com (David Sternlight)
Newsgroups: sci.crypt
Subject: Re: PKP/RSA comments on PGP legality
Date: 19 Dec 92 00:02:07 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)


In order to stop the silly discussion about "technical data", 
is source code o.k., etc., by some here who are making it up
as they go along, here are some facts:

"(c) Disclosures. Unless otherwise expressly exempted in this
subchapter, a license is required for the oral, visual, or documentary
disclosure of technical data...  A license is required regardless
of the manner in which the technical data is transmitted (e.g., in
person, by telephone, correspondence, electronic means, telex, etc.)."
                
What is "export?" Section 120.10, "Export," begins:

"'Export' means, for purposes of this subchapter: ...(c) Sending or
taking technical data outside of the United States in any manner
except that by mere travel outside of the United States by a person
whose technical knowledge includes technical data; or..."

Is pgp subject to the ITAR? See Part 121, the Munitions List, in
particular Category XIII, of which paragraph (b) reads, in part,
"...privacy devices, cryptographic devices and software (encoding and
decoding), and components specifically designed or modified
therefore,..."

A further definition in 121.8, paragraph (f) reads: "Software 
includes but is not limited to the system functional design, 
logic flow, algorithms, application programs, ..."
Newsgroups: sci.crypt
From: smb@research.att.com (Steven Bellovin)
Subject: Re: Enlarging key size of the DES algorithm
Date: Wed, 16 Dec 1992 16:47:04 GMT
Organization: AT&T Bell Laboratories
Keywords: DES, key size

In article <6681@tuegate.tue.nl>, bartjan@blade.stack.urc.tue.nl (Bartjan Wattel) writes:
> Hi,
> 
> I'm currently working on a project which involves the design of a DES cryto-
> chip. When reading some papers on this subject, it appeared to me that there
> is a great need for enlarging the number of bits used in the cipher key. I read
> about an implementation of the DES with a cipher key of 768 bits in the paper
> of T.Kropf, J.Fr"ossl, W.Beller and T.Giesler: A hardware implementation of a
> modified DES-algorithm, in North-Holland Micorprocessing and Microprogramming
> 30, 1990.
> 
> Questions:
> 
>   1)  Does anybody know the reason(s) for the number of circular left shifts
>       which are performed on the cipher key each iteration in the original
>       DES algorithm ?
>   2)  Does anybody know of other modifications concerning the key size ?
>   3)  Do modifications exist which have been published or proposed by the
>       NBS, or do other (de facto) standard modifications exist ?

First of all, when adopting any sort of cryptosystem, you have to decide
who the enemy is.  Increasing the key size is useful in defending against
brute-force attacks.  The Biham/Shamir paper showed that picking all 768
bits independently did not make a significant difference in how long it took
to use differential cryptanalysis.  To me, that says that the strength
of DES, under that attack at least, is something on the close order of 56
bits.  I would not be at all surprised to learn of other attacks that
showed the same property.

There are weaknesses that come about from picking the bits independently.
Specifically, DES now has the property that changing 1 key bit will change,
on the average, 50% of the bits in the output for constant inputs.  That
wouldn't be the case with the proposed change.  Key bits near the end
of the 768 bits should be much easier to recover.

And that, in turn, brings up the reason for shifting the key bits around
to produce the 16 subkeys.  The intent is to have each key bit operate
on each plaintext bit as soon as possible.  The E-box is tied in to this,
too, and as I recall Shamir's talk it in turn interacts with the S-boxes.

I'm certainly not saying that you can't design a better cipher than DES.
But I doubt that the sort of localized tampering you're suggesting is
likely to result in a cipher that's stronger overall.  What you may
accomplish is to confound some canned techniques -- possibly even including
NSA's -- simply because the attacker has bothered to invest the upfront capital
to attack DES.  Your system may be more effective in practice, though not
stronger in theory, simply because it may not be worth attacking.
Newsgroups: sci.crypt