Cryptography-Digest Digest #536, Volume #11 Wed, 12 Apr 00 16:13:01 EDT
Contents:
Re: Corellations (Mike Rosing)
Re: GSM A5/1 Encryption (David Hopwood)
Re: Skipjack algorithm. (tango)
Re: Compaq invents more efficient RSA?! (Bodo Moeller)
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Mike Rosing)
Re: More on self-shredding documents (Johnny Bravo)
Re: SHA2 (Irene Gassko)
Re: Geneneral Criptanalysis Information (Mike Rosing)
Re: Encode Book? ("Stou Sandalski")
Re: More on self-shredding documents (Paul Koning)
Re: GSM A5/1 Encryption (Paul Koning)
Re: Encode Book? (mark carroll)
Re: Quantum Teleportation (Ichinin)
Re: Compaq invents more efficient RSA?! (DJohn37050)
Re: SHA2 (DJohn37050)
Re: GSM A5/1 Encryption ([EMAIL PROTECTED])
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Bob Silverman)
Re: More on self-shredding documents ("David C. Oshel")
Re: O(...) - Newbie question (Bob Silverman)
Re: SHA2 (John Savard)
Re: US crypto laws? (Paul Koning)
Stream Cipher - Mark 2. ("Simon Johnson")
Re: Compaq invents more efficient RSA?! (Eric Bach)
----------------------------------------------------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Corellations
Date: Wed, 12 Apr 2000 11:08:06 -0500
mark carroll wrote:
>
> Your subject line says it all. An obvious first step would be, for
> every bit of the card number and for every bit of the unique data,
> find the probability that one is a 0 given that the other is a 0.
You might also want to sort things in different order and look
for patterns. Compare increasing card number with code order,
bit reversed card number order, various choices of code block ordering
and plot card number, etc. Specific knowledge you have about how the
code is generated would help a lot too, but I assume you don't know
much.
Cross correlations of card numbers vs cross correlations of codes
might show up some interesting patterns too.
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Wed, 12 Apr 2000 17:25:12 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: GSM A5/1 Encryption
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > > ...
> > > I would like your opinion as to what you think is a suitable
> > > ("strong") stream cipher for something like a GSM crypto system.
> > > As I said in my previous post, one Euro company has developed a
> > > strong GSM crypto phone..but they are using a block cipher for
> > > some strange reason ( the only reason I can think of is that
> > > they are using a crypto core which has an embeded symmetric
> > > algo)... interested in your comments....
> >
> > Why does it have to be a stream cipher?
> >
> > Anyway, any block cipher can be turned into a stream cipher, that's
> > elementary stuff.
It's not necessary to do that, since the data is sent in fixed-size
frames. Any mode will do; I would suggest CBC.
> > So pick a good block cipher: 3des, idea, cast, etc.
>
> This is tooo slow for GSM...
No it isn't. GSM is typically 8 kbit/s; you don't have to have a very
fast cipher to keep up with that (even taking into account that phones
are low-power, resource-constrained devices). Any of the widely respected
modern block ciphers would be more than fast enough (and would be able
to encrypt or decrypt with sufficiently low latency).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOPPjATkCAxeYt5gVAQFgigf+PzpQMGcdJRvu3YoDNfJig2B3a39iGXdo
G+cLJLrizheafqigHNWJzg3AzeMUDUJT1pZyYUkhEwGKxjbu5k2HTtxHXBWst3ET
z+rBJv085UK1phOdKALuXSDligJRsVgHQQJiaz5tStyAUqUjjF6bEB1Ni0ofO1D8
7lyP3Em2W1FF4B+sPEhRWdFonl7SFgnefO7DuBC6E6t0yvKXy7CYKkTn6S7kp94a
BGRHxGjQihs+Fi5xqlmuW8TLW9g2Pm1XyBmM5QAIwc5ax4xSBhhqv3LLnDpVq21O
ict5mxcVYDJhObkaBzBU0PTE07sX0TtdXc75PtEionGD5ftge9E+4w==
=ZQvh
=====END PGP SIGNATURE=====
------------------------------
From: tango <[EMAIL PROTECTED]>
Subject: Re: Skipjack algorithm.
Date: 12 Apr 2000 17:19:59 GMT
[EMAIL PROTECTED] wrote:
> http://ingrato.penguinpowered.com/~fastwalker, httpd was not running but is now and
>will continue to.
The source for skipjack.dll in asm is at
http://ingrato.penguinpowered.com/~tango
now.
------------------------------
From: [EMAIL PROTECTED] (Bodo Moeller)
Subject: Re: Compaq invents more efficient RSA?!
Date: 12 Apr 2000 17:01:39 GMT
Michael Scott <[EMAIL PROTECTED]>:
> Good God they have some nerve patenting the idea.
>
> I came across the idea first as an end-of-chapter example in a crypto book
> about 10 years ago. In our own RSA example source code (which hasn't changed
> in many years) there is a
>
> #define NP 2
>
> statement at the top which allows the RSA method to be trivially generalised
> to more than 2 primes
The idea of using an RSA modulus with more than two prime factors has
already been patented, and in fact the patent expires in a few months.
See <URL: http://www.patents.ibm.com/details?&pn=US04405829__&s_clms=1#clms>,
claim 38 (also at <URL:
http://www.patents.ibm.com/gifcache/US04405829__.tif.19.s0.35.r0.gif>).
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 11:20:52 -0500
Gadi Guy wrote:
>
> My algorithm fails miserably most of the time, which lead me to
> believe that maybe there's something more to inverting boolean
> matrices than they teach in numerical analysis.
It's a lot easier really, but you do have to avoid division by 0.
I've got code that will invert boolean matricies and similar code
which will look for vector solutions. The latter is probably more
useful, although you'd have to modify it to look for arbitrary vectors.
If the matrix is singular, you can find a set of vectors which allows
you to find solutions to the equivelent system of equations the matrix
represents. The vectors can take on any coefficients, and the result
is all the possible solutions to your matrix. The vectors might help
you find a similar sparse matrix which is invertable rather quickly
rather than doing a random search each try.
Send me e-mail at [EMAIL PROTECTED] and remind me to send it :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: More on self-shredding documents
Date: Wed, 12 Apr 2000 13:23:39 -0400
On Wed, 12 Apr 2000 08:52:42 -0500, "David C. Oshel"
<[EMAIL PROTECTED]> wrote:
>Sorry, I missed the beginning of this thread, but yes, self-shredding documents
>are very easy to implement. For example, if you are using an OTP, you destroy
>your pad, which effectively turns anything encrypted with it into waste paper.
The question was if you could create a document that could only be
read once, no matter what the recipient does. The answer is no.
There are too many ways to copy the document as it was being read, or
copy it before being read. There is no way to prevent the recipient
from making a copy of the sent message is they wanted to.
It wasn't a question of the recipient shredding the message. There
are plenty of ways to do that. :)
--
Best Wishes,
Johnny Bravo
BAAWA Knight, EAC - Temporal Adjustments Division
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Irene Gassko <[EMAIL PROTECTED]>
Subject: Re: SHA2
Date: 12 Apr 2000 17:35:37 GMT
David A Molnar <[EMAIL PROTECTED]> wrote:
: John Savard <[EMAIL PROTECTED]> wrote:
:> Volker Hetzer <[EMAIL PROTECTED]> wrote, in part:
:>>Any reason they don't do a contest like with AES?
:> I guess they felt that in this case no problem would be caused to
:> national security by accepting more fully the benefit of the NSA's
:> expertise for this one.
: Speaking of that, any odds on whether this hash function will need
: a bug fix as well? and if it does, will that be SHA2.1 or SHA3?
What about SHAH?
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Geneneral Criptanalysis Information
Date: Wed, 12 Apr 2000 11:39:02 -0500
[EMAIL PROTECTED] wrote:
> I'd like to learn something about ciptanalysys, but I can't find
> information about the methods that are used. I've read a lot about
> criptography, and I wish to expand my knowledge.
> Can anyone recomend me some information source??
Check out www.counterpane.com and look for "a course on cryptanalysis".
Lots of good things to read.
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Wed, 12 Apr 2000 10:51:33 -0700
"Diet NSA" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> A female biologist (an Australian whose
> name I forget) claims that intelligence is
> primarily linked to the X chromosome.
I haven't heard anything about this X chromosome linkage but I am reluctant
to belive (until I have seen research on this) that inteligence can be pin
pointed to one chromosome.
> Supposedly, then, intelligence is more
> likely to average out in females and is
> more likely to be abnormally low or high
> in males. Among peolpe with high IQs
> there are about 50 times as many men as
> women.
Ummm and you have seen these numbers where exactly?
>Also, there is evidence that
> testosterone contributes to intelligence
> and that spatial reasoning abilities are
> greater in men than in women.
Testosterone contributes to intelligence? I haven't heard anything about
that either... can you like put some urls or name some people or ...
anything that can back this point?
>These may
> be some biological reasons why there are
> more men than women in mathematics.
I suggest you look at the structure of our society before saying something
so ridiculous
>From an evolutionary standpoint it doesn't make sense for a male to be more
intelligent then the female, since in the majority of the animals on earth
after conception the male is not needed. of course since there are cases
where the male plays a major role (i.e. penguins) you can argue that the
male is important in the human species but that's way OT here.
Stou
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: More on self-shredding documents
Date: Wed, 12 Apr 2000 13:39:33 -0400
"David C. Oshel" wrote:
>
> Sorry, I missed the beginning of this thread, but yes, self-shredding documents
> are very easy to implement. For example, if you are using an OTP, you destroy
> your pad, which effectively turns anything encrypted with it into waste paper.
>
> Also, if you are using a proprietary bytestream system (the simple kind with
> good statistical properties, such as winding the output from a couple of lagged
> fibonacci generators through TEA), then destroying the codebook used to initialize
> the lfgs will render anything previously encrypted useless. There is an existence
> proof, and it takes about 2 seconds to shred any number of tons of backup disks this
>way.
Fine, but that's not "self-shredding". You're doing the
shredding there. Sure, shredding a small key can lock down
a large amount of data, that's not news.
The issue is in the claim -- which to me and numerous
others is nonsensical -- that you can build a scheme where
data is accessible at time T but guaranteed not to be
accessible at time T+1. The problem: if I could get the
data at time T, I could have copied it. Therefore,
zapping the key is no help. Furthermore, even ignoring
that part, the notion seems to be that vendor X has a
policy that they won't give out expired keys. Yeah sure,
even when confronted with a search warrant? Get real...
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: GSM A5/1 Encryption
Date: Wed, 12 Apr 2000 13:33:29 -0400
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Paul Koning <[EMAIL PROTECTED]> wrote:
> ...
> > Why does it have to be a stream cipher?
> >
> > Anyway, any block cipher can be turned into a stream cipher, that's
> > elementary stuff. So pick a good block cipher: 3des, idea, cast,
> > etc.
>
> This is tooo slow for GSM...yes any Block cipher can be turned into a
> stream cipher using CFB for sure....tooo slow...GSM is real time voice
> encryption,
> and its better to use a stream cipher for performance reasons...
No way.
3DES at 100 Mb/s or more is off the shelf technology. That translates
to less than a microsecond per block. Just about any other high
grade block cipher will do significantly better. GSM has a data
rate of about 13 kb/s, which even for a wimpy software implementation
of a block cipher is just a few spare cycles in the DSP you already
have. (Come to think of it, I have an apps note from TI that's
about 10 years old, for their very first generation TMS320 DSP,
discussing how you can do DES in under 20% of that CPU's capacity,
for GSM type data rates. Given the speed increases, that means
it should take a percent or two of capacity for a current-generation
DSP to do 3DES at those rates, never mind more software-efficient
ciphers like IDEA or Blowfish.)
So speed is absolutely not a valid argument not to use a block
cipher.
> > Alternatively, pick a stream cipher with a good reputation, such
> > as RC-4.
> >
> > The way I look at this: one of the first things any good student of
> > crypto learns is that he isn't qualified to design a good cipher,
> > and won't be for many years if ever. Clearly, no good students of
> > crypto were involved in the A5 process, because they flunked that
> > test...
>
> I dont think that is the case. Read David Wagner's threads here. I
> think the designers of A5 new exactly what they were doing...and the
> they were surely no students of crypto...
Well, you cannot possibly have a valid argument that (a) they
knew exactly what they were doing and also (b) they were surely
no students of crypto. Apart from that, the fact that they
ignored the established ciphers, designed a cipher substantially
weaker than even the absurdly weak goals they set, and the fact
that they kept it secret rather than releasing it to public
scrutiny all support my comment.
Re David Wagner's comments, you mean comments like:
"In the world of crypto, there are plenty of "tried and true"
strong ciphers (strong enough for the context of GSM that
there was no need to go with an "on the edge" cipher like
64- or 54-bit A5/1)."
?
paul
------------------------------
From: [EMAIL PROTECTED] (mark carroll)
Subject: Re: Encode Book?
Date: 12 Apr 2000 18:45:09 GMT
In article <aJ2J4.16172$[EMAIL PROTECTED]>,
Stou Sandalski <tangui [EMAIL PROTECTED]> wrote:
>
>"Diet NSA" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
(snip)
>>Also, there is evidence that
>> testosterone contributes to intelligence
>> and that spatial reasoning abilities are
>> greater in men than in women.
>
>Testosterone contributes to intelligence? I haven't heard anything about
>that either... can you like put some urls or name some people or ...
>anything that can back this point?
(snip)
I suppose that, as testosterone is thought to contribute to causing
left-handedness (so you get more left-handed males than females), and
there's some evidence that there is more variance in intelligence in
left-handers than in right-handers (i.e. more lower IQs and more
higher IQs), there may be a disproportionate number of men in the top
percentile of IQ. It's an entertaining idea I'd not really thought
about before, but anyway this armchair embryology and neuroscience
doesn't belong on sci.crypt.
-- Mark
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Quantum Teleportation
Date: Sat, 08 Apr 2000 08:47:38 +0200
Doug Goncz wrote:
>
> ...quantum teleportation.
Perhaps you are refering to Quantum Tunneling, Nasa is doing some cool
research on this. Could be used for Secure(?) key exchange.
Try a search on the nasa website.
Regards,
Ichinin
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Compaq invents more efficient RSA?!
Date: 12 Apr 2000 18:56:20 GMT
It would be interesting to see exactly the claims of the Compaq patent.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: SHA2
Date: 12 Apr 2000 18:58:56 GMT
For encryption algs, I guess the thinking is if done by open process, less
chance of a back door. But that hash algs are hard to do. Also, I have heard
a rumor that the name might be AHA for Advanced Hash Algorithm. We will see.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: GSM A5/1 Encryption
Date: Wed, 12 Apr 2000 19:11:22 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > In article <[EMAIL PROTECTED]>,
> > Paul Koning <[EMAIL PROTECTED]> wrote:
> > ...
> > > Why does it have to be a stream cipher?
> > >
> > > Anyway, any block cipher can be turned into a stream cipher,
that's
> > > elementary stuff. So pick a good block cipher: 3des, idea, cast,
> > > etc.
> >
> > This is tooo slow for GSM...yes any Block cipher can be turned into
a
> > stream cipher using CFB for sure....tooo slow...GSM is real time
voice
> > encryption,
> > and its better to use a stream cipher for performance reasons...
>
> No way.
>
> 3DES at 100 Mb/s or more is off the shelf technology. That translates
> to less than a microsecond per block. Just about any other high
> grade block cipher will do significantly better. GSM has a data
> rate of about 13 kb/s, which even for a wimpy software implementation
> of a block cipher is just a few spare cycles in the DSP you already
> have. (Come to think of it, I have an apps note from TI that's
> about 10 years old, for their very first generation TMS320 DSP,
> discussing how you can do DES in under 20% of that CPU's capacity,
> for GSM type data rates. Given the speed increases, that means
> it should take a percent or two of capacity for a current-generation
> DSP to do 3DES at those rates, never mind more software-efficient
> ciphers like IDEA or Blowfish.)
>
> So speed is absolutely not a valid argument not to use a block
> cipher.
It would be true to say that a Stream Cipher is much faster for this
type of application...I accept the fact that you can use a block cipher
and it will be ok....that is if you have to include a second dsp into
the phone...which is what Siemens did with their Topsec GSM
phone..it uses a 128 bit symmetric cipher...the set up time is pretty
lousey...20 secs...for DH etc
You as a designer...would you use a Block Cipher or a Stream Cipher for
a GSM Secure phone ....and why?
>
> > > Alternatively, pick a stream cipher with a good reputation, such
> > > as RC-4.
> > >
> > > The way I look at this: one of the first things any good student
of
> > > crypto learns is that he isn't qualified to design a good cipher,
> > > and won't be for many years if ever. Clearly, no good students of
> > > crypto were involved in the A5 process, because they flunked that
> > > test...
> >
> > I dont think that is the case. Read David Wagner's threads here. I
> > think the designers of A5 new exactly what they were doing...and the
> > they were surely no students of crypto...
>
> Well, you cannot possibly have a valid argument that (a) they
> knew exactly what they were doing and also (b) they were surely
> no students of crypto. Apart from that, the fact that they
> ignored the established ciphers, designed a cipher substantially
> weaker than even the absurdly weak goals they set, and the fact
> that they kept it secret rather than releasing it to public
> scrutiny all support my comment.
>
> Re David Wagner's comments, you mean comments like:
> "In the world of crypto, there are plenty of "tried and true"
> strong ciphers (strong enough for the context of GSM that
> there was no need to go with an "on the edge" cipher like
> 64- or 54-bit A5/1)."
> ?
>
No the reference here is to the fact that the designers...were not
amateurs...this design was to produce a deliberate week cipher...see the
messages in this thread...mine and David Wagner's..you can also read
about it in Applied Crypto
> paul
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 19:17:17 GMT
In article <[EMAIL PROTECTED]>,
Gadi Guy <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've been looking around for this algorithm for a long
> while, can't find it in any books, journals or articles.
>
> I need to create a large (N = O(10000)) boolean matrix
10K rows is not large by current standards.
which
> has a small number (n = O(3)) of ones in each row, and its
> inverse.
If the matrix is sparse it is virtually certain that its inverse
will be 50% done. But computing the inverse should only take about
a minute on a modern PC.
>
> Real methods (such as Gauss elimination) don't work.
This is news to me, considering that I've had working code to
do this for over 15 years.....
Why doesn't it work?
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "David C. Oshel" <[EMAIL PROTECTED]>
Subject: Re: More on self-shredding documents
Date: Wed, 12 Apr 2000 14:35:33 -0500
In article <[EMAIL PROTECTED]>, Johnny Bravo
<[EMAIL PROTECTED]> wrote:
> On Wed, 12 Apr 2000 08:52:42 -0500, "David C. Oshel"
> <[EMAIL PROTECTED]> wrote:
>
> >Sorry, I missed the beginning of this thread, but yes, self-shredding documents
> >are very easy to implement. For example, if you are using an OTP, you destroy
> >your pad, which effectively turns anything encrypted with it into waste paper.
>
> The question was if you could create a document that could only be
> read once, no matter what the recipient does. The answer is no.
> There are too many ways to copy the document as it was being read, or
> copy it before being read. There is no way to prevent the recipient
> from making a copy of the sent message is they wanted to.
> It wasn't a question of the recipient shredding the message. There
> are plenty of ways to do that. :)
Uhhh... Are you guys talking about the DOCUMENT or the information IN the document?
I'll grant you, information likes to propagate itself, but it sounds like the delivery
system is what they're talking about. Also, I was supposing (and gee I know how dumb
it is to suppose user will do the right thing) the idea was to automate "Your Eyes
Only,
Burn After Reading."
My main interest is in private backup systems, so the channel between sender and
receiver is
pretty short. Different user mindset, I guess.
Never mind :)
--
David C. Oshel mailto:[EMAIL PROTECTED]
Cedar Rapids, Iowa http://pobox.com/~dcoshel
``Tension, apprehension, and dissension have begun!" - Duffy Wyg&, in Alfred
Bester's _The Demolished Man_
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: O(...) - Newbie question
Date: Wed, 12 Apr 2000 19:32:40 GMT
In article <8d18ju$3u9$[EMAIL PROTECTED]>,
"ink" <[EMAIL PROTECTED]> wrote:
> Hello
>
> I've been reading this group for quite a while
> and I've been wading through cryptography literature
> and papers. I see recurring references to the function
> described like O(n^3) or such
This isn't a function. It is a shorthand notation.
A function f(x) is said to be O(g(x)) [read as 'order of g(x)']
if lim n--> oo of |f(x)/g(x)| < c for some constant c.
In other words f(x) grows at a rate which is bounded by a constant
times the rate at which g(x) grows as x becomes sufficiently large.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SHA2
Date: Wed, 12 Apr 2000 19:34:23 GMT
David A Molnar <[EMAIL PROTECTED]> wrote, in part:
>John Savard <[EMAIL PROTECTED]> wrote:
>> I guess they felt that in this case no problem would be caused to
>> national security by accepting more fully the benefit of the NSA's
>> expertise for this one.
>Speaking of that, any odds on whether this hash function will need
>a bug fix as well? and if it does, will that be SHA2.1 or SHA3?
Meow.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: US crypto laws?
Date: Wed, 12 Apr 2000 16:00:08 -0400
JONATHAN DINERSTEIN wrote:
>
> Does anyone know what the new US laws are for exporting crypto software? I
> know the laws just recently changed. Can even software using new algorithms
> (MARS, Twofish, etc) be exported?
> thanks!
They are online at http://www.bxa.doc.gov/. You may need legal
help to figure out all the details, but a fair part is reasonably
clear once you figure out the terminology. Particularly interesting
is the new rule for exporting open source stuff (i.e., you can
just post it on your website, but you must notify them first --
but you do *not* have to get permission first).
paul
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Stream Cipher - Mark 2.
Date: Wed, 12 Apr 2000 21:01:48 -0700
My last attempt at generating stream characters was pretty poor.... ( and a
total clone) I hope this algorithm is a little more robust, altough this
is probably not the case. :). This stream-generator seems to produce a
random looking stream. Altough i havn't analyised it in any shape or form.
The following function produces one stream character:
Function StreamCharacter {
For i = 1 to (length of key)
a = (a + (a * b * (ascii of the i'th character of key))) mod 65536
b = (b + (a * b * (ascii of the (i+1)'th character of key))) mod 65536
Next i
outputchar = (a+b) mod 256
}
N.B. the (i+1)'th character is calculated by 'a=(i+1) mod len(key): if a=0
then a= len(key)'
I'd like to ask a few questions about my algorithm:
1.) Any stupid errors I didn't find?
2.) Whats the period of it?
3.) Is it a clone of anything?
4.) Whats the chance of collsion in the 'a' & 'b' values?
Please don't be too saracastic, i'm just a beginner :)
Thanxs in advance,
S. Johnson
------------------------------
From: [EMAIL PROTECTED] (Eric Bach)
Subject: Re: Compaq invents more efficient RSA?!
Date: 12 Apr 2000 19:59:28 GMT
>> Compaq claims a major breakthrough in cryptography by inventing an RSA
>> variant called MultiPrimes that uses more than one prime factor for the
>> secret key. The white paper is at
>
>> http://www.tandem.com/brfs_wps/esscpttb/esscpttb.htm
>
>> Does anyone care to comment on this?
Systems with more than 2 primes were discussed in the literature a long
time ago, e.g. V. Varadharajan, Trapdoor Rings and Their
Use in Cryptography, Proc. CRYPTO 85, Springer-Verlag LNCS 218.
They are usually considered risky because there are already several
factoring methods that are sensitive to the size of prime divisors.
How do you know that the next factoring algorithm won't have this
property?
>
>I have a vague feeling that the idea of using multiple prime factors in
>the secret key is almost as old as RSA itself. At least, chinese
>remaindering methods to speed up decryption seemed to appear early;
Quisqater and Couvreur, Electronics Letters v. 18, 1982
>the generalization to multiple smaller factors seems natural.
Yes. It certainly doesn't deserve to be called a "technology".
More like a security/performance tradeoff.
-Eric Bach
------------------------------
** 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
******************************
