Cryptography-Digest Digest #523, Volume #11 Mon, 10 Apr 00 21:13:01 EDT
Contents:
Re: Q: Entropy (Xcott Craver)
Re: Please help (Tom St Denis)
Re: Crypto API for C (Tom St Denis)
Re: Hash function based on permutation polynomials (Tom St Denis)
Re: Schoof's Algorithm (Nigel Smart)
Checksum for digits ([EMAIL PROTECTED])
Re: Cost-effective computing? (Jeffrey Williams)
Can't install SmartCard ("Rolanas Ycas")
Re: Checksum for digits ("Metty")
Re: Can't install SmartCard ([EMAIL PROTECTED])
Re: Is AES necessary? (wtshaw)
Re: Skipjack algorithm. ("Douglas A. Gwyn")
Re: Simple, yet strong algorithm (wtshaw)
Re: Checksum for digits (wtshaw)
Re: Skipjack algorithm. (John Savard)
Re: enigma returned (John Savard)
Selecting an encryption algorithm for an embeded design (Stelios Koroneos)
Re: Cryptanalysis Challenge - Will anyone accept? (Frank Gifford)
Re: Skipjack algorithm. (Frank Gifford)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Q: Inverse of large, sparse boolean matrix, anyone? (Gadi Guy)
Re: Schoof's Algorithm (Mike Rosing)
Re: (no subject) (Mike Rosing)
Re: Is AES necessary? (Paul Koning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Subject: Re: Q: Entropy
Date: 10 Apr 2000 08:57:35 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>[Thus] the value 0.391+0.115 computed by Bryan Olson is the entropy
>of the channel from Bob to Alice and has sense as such.
I think you may have misread: 0.391 is the entropy.
This is (4/52)*3.70 + (48/52)*0.115.
>It is however not appropriate to say that any message from Bob saying
>a card is an ace has 0.391 bit of entropy. Am I right? If yes,
>then I suppose his 'paradox' given in a previous post is incorrect.
I don't think it was intended to sound paradoxical. The entropy
of 0.391 is the mean amount of uncertainty, loosely information,
given by a message from Alice. Bob provided an example in
which Alice announces a card being an Ace, a message with a
"shock value" of 3.70. With this particular, rare, message,
The information in the playing card is reduced from 5.70 bits
(log 52, for 52 equiprobable outcomes) to 5.70-3.70=2 bits
(log 4, for 4 equiprobable outcomes (aces.))
On average, Alice does not give out that much information.
>M. K. Shen
-Scott
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Please help
Date: Mon, 10 Apr 2000 11:06:08 GMT
martin aristidou wrote:
>
> Hi everybody.I'm new to cryptography so i have a lot of questions. I would
> appreciate it if you could help me out or point me to a url where i can get
> some answers.
I have a bunch of papers at http://24.42.86.123/crypto/
Look up paper #130. Also Counterpane has a ton of papers as well.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Crypto API for C
Date: Mon, 10 Apr 2000 11:08:46 GMT
Runu Knips wrote:
>
> Joseph Ashwood wrote:
> > > P.s.: Hmm no ElGamal yet ... RSA is still patented, isn't
> > it ?
> > Actually RSA is only the beginning of the problems, IIRC
> > IDEA is also patented, and RC5 and RC6 are still under
> > various reservations.
>
> Yep but I can use Twofish instead which is also included.
Or blowfish, or cast-128, or ...
BTW I am in the midst of working on litte vs. big endianess issues. If
people could help spot 'trouble' areas that I have to fix that would be
nice. Of course the first issue to fix is the block ciphers...
BTWx2 If anyone is actively playing with CB you can email me at
[EMAIL PROTECTED] to get the latest working copy. I have just recently
fixed a bug dealing with large rsa keys...
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Hash function based on permutation polynomials
Date: Mon, 10 Apr 2000 11:12:18 GMT
Runu Knips wrote:
>
> Tom St Denis wrote:
> > http://24.42.86.123/hash.c
>
> Interesting code. Hmm at first glance I would write the
> first loop as:
>
> t = 0x9E37B91Ful;
> for (r = 0; r < 15; ++r) /* form initial sum of temp[0..14] */
> t ^= temp[r];
> for (r = 16; r < SIZE; ++r) {
> t ^= temp[r-1]; /* add new temp[n] to sum */
> temp[r] = ROL(t ^ r, 11);
> t ^= temp[r-16]; /* remove first temp[n] from sum */
> }
>
> which works because (a ^ b ^ b = a), or (a ^ a) = 0. If
> you would use + instead, one could simply use - in the
> last statement.
I don't like this because the initial input should be unmodified first,
then as I stretch it I mix it with the other words. Primarly because
there is no advantaged to doing an invertable permutation of the input.
> I think you would agree that this loop isn't very good
> because the difference between temp[r] and temp[r+1]
> depends only on r and temp[r-1], plus some offset build
> buy temp[0..14] and your magic constant 0x9e37b91f.
My magic constants are just random typing. Also the input is 512 bits,
which goes from temp[0..15].
Thanks for looking at it :), what do you think of the compression
rounds?
Tom
------------------------------
From: Nigel Smart <[EMAIL PROTECTED]>
Subject: Re: Schoof's Algorithm
Date: Mon, 10 Apr 2000 11:45:08 GMT
lordcow77 wrote:
>
> In article <[EMAIL PROTECTED]>, Robert Harley
> <[EMAIL PROTECTED]> wrote:
> >Point counting, in characteristic 2, is a solved problem: it's
> just
> >that nobody knows it yet. =:-)
>
> Are there any possibilities for the algorithm to be extended to
> eliptic curves defined modulo arbitrary prime numbers?
>
Yes. All that is different between mod 2 and mod p is
i) How the modular polynomials are computed.
ii) How to compute the factor of the division polynomial.
All the other code should be identical, especially if written using a
language which supports generic programming.
Even (i) is debatable, since it is not always necessary in mod p to use
the "reduced" polynomials (called Muller's polynomials in my book with
Blake and Seroussi). As I pointed out in an earlier debate on this topic,
an almost complete description is given in the book I co-authored (please
follow the link at the bottom of this page in my sig if you dont know about
it).
As for Robs comment...
>Point counting, in characteristic 2, is a solved problem: it's just
>that nobody knows it yet. =:-)
Rob is, hopefully, just taking the micky out of how badly informed the
general crypto community is. For fields of bit size upto 300 it is
quite easy to implement Schoof's algorithm using existing libraries
such as NTL, LiDIA, ZEN etc to do all the grunt work. In fact I
would expect a large number of such implementations to now exist in
various companies/universities around the world.
Computing group orders up to 300 bits is quite fast, certainly fast
enough for cryptographic use.
For those who still dont believe that Schoof's algorithm is quite
standard/well understood/fast/easily available. You can view an
implementation in Magma in the directory...
magma2.6/package/EC/SEA
of the current Magma distribution. This implementation is very
good in my opinion given it is written in Magma and not in a
language closer to the system (eg C/C++ etc). It is certainly
a good enough implementation for most purposes. As far as I
am aware it currently does not support the early abort strategy
or using SHA-1 to produce verifiably random curves, but that should
only take a couple of hours programming to add.
For those who are interested (and just to ram home how easy Schoof is)
running wc on the SEA directory in Magma says there are only 5898
lines in all files (OK this is probably not fare since some files
are data files held in a compact format). But even so the line count
for the *.m files (those which contain program) is only 5258 with an
average of 34 characters per line.
Nigel
--
Dr Nigel P. Smart | Phone: +44 (0)117 954 5163
Computer Science Department, | Fax: +44 (0)117 954 5208
Woodland Road, | Email: [EMAIL PROTECTED]
University of Bristol, BS8 1UB, UK | URL: http://www.cs.bris.ac.uk/~nigel/
------------------------------
From: [EMAIL PROTECTED]
Subject: Checksum for digits
Date: Mon, 10 Apr 2000 12:03:32 GMT
I'm writing an application where the user needs to enter a number of
digits (>30) in a field and I need a good algorithm that can verify
that the data the user has entered is correct. It should support
variable checksum length and should detect as many faulty digits as
possible. It's not necessary to detect which digits are incorrect.
Thanks in advance!
P.S. Please reply with e-mail as well.
/Jesper Nordenberg
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jeffrey Williams <[EMAIL PROTECTED]>
Subject: Re: Cost-effective computing?
Date: Mon, 10 Apr 2000 07:30:42 -0500
If you check out some of the websites pertaining to Beowulf, you will find links
relating to PVM.
Much of your decision will be based on whether the things that interest you are
amenable to parallelization. If your problems support massively parallel
processing, you would do better with lots of slower (and much cheaper) processors.
If you cannot make good use of lots of processors, you'll need to find a few
realllllllllly fast processors. That's a call you need to make. I've been toying
with the idea of building myself a nice Beowulf system. It is not simple trying to
determine how to get the most bang for my buck. Processor price/performance curves
are not linear, but they do change frequently. As with all systems, if you have it
working, it's obsolete.
$100K is not cheap, at least for most folks paying out of their own pocketses.
Please let us know what your ultimate decision is and how well it works.
LL&P
Jeff
Jim Gillogly wrote:
> "Trevor L. Jackson, III" wrote:
> >
> > Jim Gillogly wrote:
> > > What's the best approach to a cheap supercomputer?
>
> > If you are spending 5-200K the PVM solution is a good
> > bet. If you are spending large chunks of money, say 10M+, custom solutions
> > become advantageous due to amortization of design costs. So, what's your
> > budget?
>
> "Cheap" for me doesn't extend to $10M+. Let's say $5K-100K. I'll do a Web
> search on PVM, unless you have a good starting URL handy.
>
> > So, what's your locality?
>
> I'd been thinking loosely coupled, but for something like a massive matrix
> reduction at the end of a factoring exercise perhaps I'll need the tighter
> version. I understand one of the top factorers is working on a variant that
> can be done on workstations, though, so perhaps that's no longer going to be
> a major constraint.
>
> > It appears to me that once
> > you need a NUMA architecture the inter-CPU bandwidth is wasted because it is
> > hard to optimize an application for three kinds of access (local, intra-node,
> > inter-node).
>
> Thanks for the help (and thanks to all the others offering advice).
> --
> Jim Gillogly
> Hevensday, 19 Astron S.R. 2000, 16:41
> 12.19.7.1.19, 4 Cauac 2 Pop, Third Lord of Night
--
Jeff Williams
Software Design Engineer
DNA Enterprise, Inc
1240 E Campbell Rd, Richardson, TX, 75081
972 671 1972 x265
[EMAIL PROTECTED]
Did you know that there is enough sand in
north Africa to cover the entire Sahara?
------------------------------
From: "Rolanas Ycas" <[EMAIL PROTECTED]>
Subject: Can't install SmartCard
Date: Mon, 10 Apr 2000 14:43:49 +0200
Reply-To: "Rolanas Ycas" <[EMAIL PROTECTED]>
Hi all
Platform: NT with SP6.
Problem:
I installed scbase.exe wich is Microsoft Resource manager for SmartCards.
Installation was O.K.
I rebooted machine.
Then i can't start Smart Card Resource Manager in Services applet.
It shows error:
"Could not start the Smart Card Resource Manager service on \\ZIGMANTAS"
"Error 1068: The dependency service or group failed to start"
What additional services i must install or what i'm missing?
Rolanas Ycas
Infostruktura
Pilies 23/15
2001-LT Vilnius
Lithuania
Tel. +370-2-791321
Fax. +370-2-791331
E-mail: [EMAIL PROTECTED]
------------------------------
From: "Metty" <[EMAIL PROTECTED]>
Subject: Re: Checksum for digits
Date: Mon, 10 Apr 2000 14:36:28 +0100
ummm.... don't you need something to check against?
<[EMAIL PROTECTED]> wrote in message news:8csfud$ml2$[EMAIL PROTECTED]...
> I'm writing an application where the user needs to enter a number of
> digits (>30) in a field and I need a good algorithm that can verify
> that the data the user has entered is correct. It should support
> variable checksum length and should detect as many faulty digits as
> possible. It's not necessary to detect which digits are incorrect.
>
> Thanks in advance!
>
> P.S. Please reply with e-mail as well.
>
> /Jesper Nordenberg
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Can't install SmartCard
Date: Mon, 10 Apr 2000 13:50:58 GMT
In article <8csiao$scs$[EMAIL PROTECTED]>,
"Rolanas Ycas" <[EMAIL PROTECTED]> wrote:
> Hi all
>
> Platform: NT with SP6.
> Problem:
> I installed scbase.exe wich is Microsoft Resource manager for
SmartCards.
> Installation was O.K.
> I rebooted machine.
> Then i can't start Smart Card Resource Manager in Services applet.
I'm afraid this may be the wrong newsgroup for this kind of question.
Try a group such as microsoft.public.windowsnt.<something...> instead.
Good luck!
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Is AES necessary?
Date: Mon, 10 Apr 2000 08:18:18 -0600
In article <[EMAIL PROTECTED]>, "David C.
Oshel" <[EMAIL PROTECTED]> wrote:
>
> My guess is "swamping Echelon" with cryptic byte-wiggling is not going to be
> as successful in the long run as all the bogus disinformation the system is
> collecting from all those parties who are really, really, really, terribly
> interested in the phenomenon.
>
You might be called a terrorist if you define the government as the sole
enemy, but such is little different than information warfare, which the
government practices at a number of levels. They should realixe as normal
they create their own problems through blind/short-sighted policies.
Appealing that they are the really guys can be misleading as people in
government are not different than the rest of us. What should set
government apart is the duty that they have to prove their good intentions
and wise practices, not tying to bury things behind classifications. If
you violate the Constitution in the process of doing assigned or chosen
duties, and work for governement, you surely are a traitor of your oath
and our trust.
It is not a sign of weakness or a reason to be suspect to be interested in
what government is doing, rather it is a sign of stupidity not to ask
penetrating questions, investigate possible sins, and complain loud and
long when government seeks to evade their responsibility to be publically
responsible.
--
Doubt until you have poof, then doubt frequently. Descartes
%/^): [|]"! ?=)@~ ;)[]* :@\@} *#~}> ,=+)! .($`\
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Skipjack algorithm.
Date: Mon, 10 Apr 2000 14:34:38 GMT
CLSV wrote:
> One of the official remarks on the algorithm is
> that the length of its keys can not be extended.
> I don't know where I read it but if you look for
> it you probably can find it. This is possibly the
> optimal length for this cipher. It might as well
> be one of the (secret) design criteria.
Actually, Skipjack is one member of a parametric family of similar
encryption algorithms. Another realization of this family could
be produced, but more is involved than just the number of bits in
the key.
The really important thing about Skipjack is the counter.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple, yet strong algorithm
Date: Mon, 10 Apr 2000 08:24:31 -0600
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> "Brent W.J. Mackie" wrote:
> > I would greatly appreciate it if someone could help me out here and even
> > more if you could help with some VB code as well.
>
> Again, I would suggest you better use a .dll written in
> C/C++/Pascal/Whatever.
> VB is NOT good for crypto. It has no unsigned integers, it has overflow
> checks,
> it has no direct string addressing (you can't write a[i] = b[i] and
> such), and
> so on. Doing more than a simple XOR is really tricky under such
> circumstances.
VB, as does windoze, has security problems. If you want a zebra, why be
happy with painted stripes on a jackass?
--
Doubt until you have poof, then doubt frequently. Descartes
%/^): [|]"! ?=)@~ ;)[]* :@\@} *#~}> ,=+)! .($`\
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Checksum for digits
Date: Mon, 10 Apr 2000 08:38:13 -0600
In article <8csfud$ml2$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I'm writing an application where the user needs to enter a number of
> digits (>30) in a field and I need a good algorithm that can verify
> that the data the user has entered is correct. It should support
> variable checksum length and should detect as many faulty digits as
> possible. It's not necessary to detect which digits are incorrect.
>
If you remember that casting out nines results in a single digit result,
really only 1-9, know that it can be done to cast out any N's. You might
try casting out 99's, 999's, etc. You run the risk of having errors null
each other with any true hash.
I suggest, as I use the method itself, to use plural hashes, since a
weakness in the result of one is unlikely to also occur in one of a
different structure.
--
Doubt until you have poof, then doubt frequently. Descartes
%/^): [|]"! ?=)@~ ;)[]* :@\@} *#~}> ,=+)! .($`\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Skipjack algorithm.
Date: Mon, 10 Apr 2000 15:42:44 GMT
<[EMAIL PROTECTED]> wrote, in part:
> Another Question, would a longer key varient of Skipjack (considering the ease
>with which this is accomplished
>and the fact that the algorithm is not changed) be a possible AES candidate? I'd much
>rather use a strengthened version
>of what the government uses then any AES candidate to date. Thanks.
Since the blocksize is 64 bits, not 128 bits, it doesn't fit the
format of an AES candidate.
Since it has a plain key schedule, Skipjack wouldn't necessarily be
secure with all possible key lengths. It appears to me that the next
higher key length for Skipjack that would preserve its structure would
be a 112-bit key (14 bytes instead of 10 bytes), but this could be
mistaken.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: enigma returned
Date: Mon, 10 Apr 2000 15:43:50 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>the Heer (the Navy)
As noted, "Heer" is the German word for army, as I was informed by
E-mail.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Stelios Koroneos <[EMAIL PROTECTED]>
Subject: Selecting an encryption algorithm for an embeded design
Date: Mon, 10 Apr 2000 18:58:08 +0300
Greeting to all.
I am faced with the problem of selecting a "appropriate" encryption algorithm and i
would appreciate any help.
Here is the situation.
I am designing embedded devices using flash/reprogrammable microcontrolers.
These devices are rather limited in resources (1k -8k program space, 64-512 bytes of
ram) but are great for a number of designs.
One of the advantages of recent microcontrolers is that they use flash memory to store
the program and thus its easy to re-program them, and in some cases you don't even
have to remove them from the design.
In theory if you want to do a program update it can be done very easily, even by the
mcu itself as it has a command that allows it to program a byte in the flash memory.
So you don't have to send a new chip every time you do a program update.
The problem is that most of the designs that use the mcu's are so simple (from a
hardware standpoint) that if you send the code to the customer for an upgrade it will
be trivial to clone the device.
The solution would be that the code you send to the customer is encrypted and the
customer uses a special programming program running on a pc, to send the new
encrypted program to the mcu that reprograms itself.
My question is what is the best suited algorithm for such an application ?
The algorithm must use as litle resources as possible (ram is very limited and the
free programming space is also limited) and be in the public domain (if possible).
Any ideas would be appreciated.
regards
Stelios Koroneos
--
For more info on AVR's, GPS, and GSM visit my web page
Http://Come.to/Stelios_Cellar
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Cryptanalysis Challenge - Will anyone accept?
Date: 10 Apr 2000 12:15:18 -0400
In article <8cm90d$lb7$[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
>In article <JVwH4.622$[EMAIL PROTECTED]>,
>Jeff Hamilton <[EMAIL PROTECTED]> wrote:
>>I was thinking of placing a stream cipher out here that I developed about 3
>>years ago. ...
>
>Sure, go ahead and post it. Make sure to describe the exact conditions
>of the challenge, i.e. what does somebody have to do to collect the $100, etc.
>
>>Would anyone be up to the offer? ...
>
>I'd say just go ahead and post the challenge: specification/description
>of the cipher, and the sample message.
It would be good to keep in mind that a cipher may be "broken" in different
ways. For example, the contents of a ciphertext message might be determined
based on a poorly implemented cipher, even though the particular starting
key cannot be determined.
So if you offer this contest, it should be a few plaintext/ciphertext/key sets
and then a challenge ciphertext. The goal is to recover the plaintext (or
a significant portion of it) of that ciphertext.
-Giff
--
Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Skipjack algorithm.
Date: 10 Apr 2000 12:21:24 -0400
In article <8cra36$6s2$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Bill Unruh <[EMAIL PROTECTED]> wrote:
>> This is on the basis of what theory? You admit in the rest of your post
>> tht you do not have the competence to evaluate the security of a crypto
>> system, and then come up with this comment?
>
> That's a harsh statement, I can evaluate the security of a cryposystem, but I
>don't know every cryptanalytic method,
>do you? I'd be impressed, considering most haven't been invented yet. My base of
>cryptographic knowledge tells me
>skipjack with a longer key is more secure, I was looking for evidence to the
>contrary. I haven't had years to study any
>of the AES algorithms nor skipjack, but since the USG uses it to encrypt some
>military type traffic, I'd like to have a
>stronger version of it for consumer use if possible, not asking too much I hope.
It may seem on the surface that a longer key is stronger, it really depends
on how that longer key is used in place of the existing key schedule. If the
key bits are used infrequently (especially at the end of the cipher), then
you will have very little of the avalance effect. As an extreme example,
consider a particular key bit that is only used in the final round.
Detailed analysis with a proposed key schedule can tell you if that schedule
is better or worse than the existing one. Simply adding key bits and changing
the key schedule won't necessarily strengthen your cipher. In addition, it
would be up to you to prove that the change makes it stronger before people
will accept it. Otherwise, how could you prove that you hadn't weakened
it significantly?
-Giff
--
Too busy for a .sig
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Mon, 10 Apr 2000 11:36:26 -0500
It was a 5 minute bang out, not a production piece, but there is little in this
that invalidates the logic present.
Taneli Huuskonen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> James Felling
> <[EMAIL PROTECTED]> writes:
>
> [...]
> >Then given an output value B=100*B1+10*B2+B3 we can conclude the following.
>
> >then the actual output of the 3 streams call it S=100*S1 +10*S2+ S3
> >was either B, B+256, or B+512. this allows us to conclude the following
> >S3= either B3, (B3 -6) Mod 10, or (B3-2) mod 10
> >S2= either B2, (B2-5) mod 10, or (B2-1) mod 10
> >and S1 = either B1, (B1-2) mod 10, or (B1-5) mod 10. in addition
> >0<=S1<=7 so we can always eliminate at least 1 possible form the
> >valuse of S1, in addition since S1 determines which values get droped
> >any ability we get to guess at S1 also means that we
> >get closer to guessing where the droped values fall.
>
> A minor correction: S is either 3*B, 3*B+1, or 3*B+2. Besides, you
> forgot about the carry. However, these conclusions are basically sound.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOO+NaV+t0CYLfLaVEQLpnACfW4j2qwd4T/AC9ZKCwn/4FJ1PmgwAn2NI
> n5Fng3Te14sOOuwN8ZxqVACv
> =b8kB
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
------------------------------
From: Gadi Guy <[EMAIL PROTECTED]>
Subject: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Mon, 10 Apr 2000 18:33:30 +0300
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 which
has a small number (n = O(3)) of ones in each row, and its
inverse.
Real methods (such as Gauss elimination) don't work.
Can anybody supply a good algorithm for this?
Thnx.
Gadi Guy
--
**********************************************************************
>From the alt.folklore.urban FAQ:
True: Prof. Donald Knuth's 1st publication was in MAD mag.
(MAD #33 "The Potrzebie system of weights and measures")
**********************************************************************
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Schoof's Algorithm
Date: Mon, 10 Apr 2000 10:46:47 -0500
Nigel Smart wrote:
> Rob is, hopefully, just taking the micky out of how badly informed the
> general crypto community is. For fields of bit size upto 300 it is
> quite easy to implement Schoof's algorithm using existing libraries
> such as NTL, LiDIA, ZEN etc to do all the grunt work. In fact I
> would expect a large number of such implementations to now exist in
> various companies/universities around the world.
>
> Computing group orders up to 300 bits is quite fast, certainly fast
> enough for cryptographic use.
It's not the access to code, it's the comprehension of the math. For
those of us without a Phd in math, it's pretty thick going. As an
example,
figuring out the coefficients of the j-invariant q expansion is
non-trivial
and even having a clue as to how far the expansion needs to be carried
is
not really described anywhere. For 256 and 512 bit calculations, what's
a reasonable degree of q for j(tau)?
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: (no subject)
Date: Mon, 10 Apr 2000 10:57:42 -0500
john wrote:
>
> where is a good place to find the laws on crypto?
check out this web page:
http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm
It's called the crypto law survey, covers most of the world.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Mon, 10 Apr 2000 12:10:12 -0400
Mok-Kong Shen wrote:
>... Isn't
> the fast (though 'broken') DES sufficient for protecting most
> of the security sensitive stuffs.
I don't think so. For a small investment you can break it in
a day or so. If something is worth protecting at all, it
is worth protecting better than that. Especiallly since it's
easy to protect it better tha that.
> For the rest, it is my point
> that one could use 3DES
Yes, but 3DES is VERY slow in software.
> and also adapt DES (using minor variations)
> to achieve higher strength,
"Adapting" DES? In what way? It's well known that modifying
DES is a dangerous enterprise; most changes weaken it.
AES has lots of goals. One of them is to give security
as good or better than 3DES at substantially higher
performance. Another is to increase the block size to
eliminate the risk of dictionary attacks. A third is to
do these things with a "standard" cipher.
There are a number of ciphers believed to do the first
(IDEA, Blowfish, Cast, etc.). I don't think any did the
second until AES, and considering the rate at which
storage and processing speeds are going up, going above
a 64 bit block size is a good idea. As for the third
point, the only international standard cipher is DES
(and, as of recently, 3DES). While several others are
popular, none have achieved the prominence of DES. The
AES process should be different and intends to be
different, finally replacing DES several decades after
its proper time.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
** 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
******************************
