Cryptography-Digest Digest #938, Volume #12 Mon, 16 Oct 00 19:13:00 EDT
Contents:
Re: CRC vs. HASH functions (Bryan Olson)
Re: SHA-256 implementation in pure C (free) (David Crick)
Re: Is there a telnet client/server that will allow secure logins over telnet?
(Thomas Wu)
Re: More on the SDMI challenge ("David C. Barber")
Re: SHA-256 implementation in pure C (free) (Daniel Leonard)
Re: SHA-256 implementation in pure C (free) (Tom St Denis)
Re: Basic skills and equipment... (Bob Silverman)
Re: SHA-256 implementation in pure C (free) (David Crick)
Re: SHA-256 implementation in pure C (free) (David Crick)
Re: SHA-256 implementation in pure C (free) (David Crick)
Re: On block encryption processing with intermediate permutations (David Hopwood)
Re: Why trust root CAs ? ("Lyalc")
Re: Basic skills and equipment... (Scott Craver)
Re: Basic skills and equipment... (Tom St Denis)
Re: pass phrases and key generation (and Kerberos) ("Joseph Ashwood")
Re: Looking for paper ("Joseph Ashwood")
Re: Public Key Algorithms and Analysis ("Joseph Ashwood")
Re: Try This One ("Joseph Ashwood")
Book, "Battle of Wits" ? (Jim Haynes)
Re: Basic skills and equipment... ("Brian Wong")
Re: Basic skills and equipment... ("Brian Wong")
Re: Basic skills and equipment... (John Myre)
Re: Dense feedback polynomials for LFSR (Tim Tyler)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Mon, 16 Oct 2000 20:04:23 GMT
Mack wrote:
[Mack]
> >> Most MD style Hash functions use some sort of CRC type
> >> polynomial on the front end so this is an issue there as well.
> >
[Bryan]
> >Not true. SHA-1 has the W buffer up front, but the effect
> >is nothing like a CRC. In particular, the W-buffer
> >operations are reversible, so it alone never induces
> >collisions. MD-2 actually tacks on a checksum (good thing
> >too), but it's not on the front end; it's appended in the
> >back.
> >
>
> The W buffer in SHA-1 acts very much like a CRC.
Whether you choose to look at it as being like a CRC is not
the issue. It does not introduce collisions and does not
produce the same problem.
> The use of the W buffer however hides that fact. The
> addition of the S (rotate) only changes the actual polynomial
> not the fact that it behaves like a CRC.
The W buffer is inseparable from the use of the W buffer.
Try it; add multiples of whatever you think is the polynomial,
and see what happens to the digest.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 21:11:28 +0100
bubba wrote:
>
> http://sduplichan.home.att.net/SHA/sha512.c
>
> > "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> >
> > http://www.geocities.com/tomstdenis/files/sha256.c
Who's going to place a bet on the first to code sha-384? :)
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Is there a telnet client/server that will allow secure logins over telnet?
Date: 16 Oct 2000 13:18:35 -0700
Alex <[EMAIL PROTECTED]> writes:
> Hi. I'm sure this is not the appropriate newssgroup for this question,
> but I was hoping someone could point me in the right direction.
>
> If you're on a machine A behind a firewall that allows telnet but not
> ssh (and I know nothing about the low-level network protocols, so I
> don't know how the firewall is blocking ssh,) is there a telnet server
> that you can set up on a machine B beyond the firewall, and a
> corresponding client that you can use behind the firewall on A, that
> will securely negotiate a connection to an arbitrary machine C through
> the telnet to the server on B?
Just use SRP Telnet to B, and then use whatever software you want to
connect to C. Your connection to server B will be secure, and the
connection to C will be as secure as the software you use to access it.
> Alex.
>
> --
> Speak softly but carry a big carrot.
>
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: More on the SDMI challenge
Date: Mon, 16 Oct 2000 13:21:16 -0700
Nice thought, but........................if the industry was really
listening to us, they'd already have known that this entire approach (having
people decode information on a system over which they have complete control)
is fatally flawed in the first place. It's never a question of if [the
system will be broken], but when.
Said industry would be better off looking for a model that makes piracy
unattractive, like for $5/mo I have access to all their music anytime I want
it, and as a result don't need to bother filling up my hard drive with songs
I might want to listen to just so they'll be there for me.
*David Barber*
"Scott Craver" <[EMAIL PROTECTED]> wrote in message
news:8s95m6$7f2$[EMAIL PROTECTED]...
> Nobody needs to learn the hard way. If we're scientists
> (and this is, after all, sci.crypt,) then we will not engage
> in tactics such as tricking the industry into choosing a scheme
> before performing analysis. Our goal is to analyze security
> systems and share our results with the scientific community,
> and therefore everyone else with a library card.
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 20:37:16 GMT
On Mon, 16 Oct 2000, David Crick wrote:
> bubba wrote:
> >=20
> > http://sduplichan.home.att.net/SHA/sha512.c
> >=20
> > > "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> > >=20
> > > http://www.geocities.com/tomstdenis/files/sha256.c
>=20
> Who's going to place a bet on the first to code sha-384? :)
>=20
> --=20
> +-------------------------------------------------------------------+
> | David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
> | Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
> | M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
> +-------------------------------------------------------------------+
>=20
Been there, done that, in the process of getting the T-Shirt :0
http://megasun.bch.umontreal.ca/~leonard/SHA/
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW : http://megasun.bch.umontreal.ca/~leonard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 20:38:25 GMT
In article <[EMAIL PROTECTED]>,
David Crick <[EMAIL PROTECTED]> wrote:
> bubba wrote:
> >
> > http://sduplichan.home.att.net/SHA/sha512.c
> >
> > > "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> > >
> > > http://www.geocities.com/tomstdenis/files/sha256.c
>
> Who's going to place a bet on the first to code sha-384? :)
I dunno, it's a thoughy.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Mon, 16 Oct 2000 20:46:06 GMT
In article <8sflov$8o$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8sfiv0$tl6$[EMAIL PROTECTED]>,
> Sure bob, we will have math savants that have no clue on how to talk
> about cryptography. Smooth move.
You are STILL EVADING the question that was ASKED. The poster asked a
very specific question. He didn't ask "how can I get an elementary
intro to crypto?" He did ask "what math background is required?"
Further, learning the crypto is EASY with the right math background.
Learning it without the background is very HARD.
For someone with so little background and experience, "tom", you sure
can act like an ignorant and arrogant ass sometimes. I made it clear
that I was not flaming, yet you found it necessary to be insulting in
return.
--
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 Crick <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 22:08:11 +0100
David Crick wrote:
>
> bubba wrote:
> >
> > http://sduplichan.home.att.net/SHA/sha512.c
> >
> > > "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> > >
> > > http://www.geocities.com/tomstdenis/files/sha256.c
>
> Who's going to place a bet on the first to code sha-384? :)
Here's my c version anyway :)
http://vidcad.tripod.com/sha384.c
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 22:08:37 +0100
Daniel Leonard wrote:
>
> Been there, done that, in the process of getting the T-Shirt :0
>
> http://megasun.bch.umontreal.ca/~leonard/SHA/
Well my C version of sha-384 is at http://vidcad.tripod.com/sha384.c
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: SHA-256 implementation in pure C (free)
Date: Mon, 16 Oct 2000 22:09:12 +0100
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> David Crick <[EMAIL PROTECTED]> wrote:
> > bubba wrote:
> > >
> > > http://sduplichan.home.att.net/SHA/sha512.c
> > >
> > > > "Tom St Denis" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > http://www.geocities.com/tomstdenis/files/sha256.c
> >
> > Who's going to place a bet on the first to code sha-384? :)
>
> I dunno, it's a thoughy.
hehe, well *struggle*, here you go http://vidcad.tripod.com/sha384.c
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
Date: Mon, 16 Oct 2000 19:39:15 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: On block encryption processing with intermediate permutations
=====BEGIN PGP SIGNED MESSAGE=====
Mok-Kong Shen wrote:
> David Hopwood wrote:
> > Mok-Kong Shen wrote:
> > > Now Bryan Olson claimed to have found an attack and
> > > subsequently he said that under a certain condition
> > > his attack doesn't work. So I modified my scheme to
> > > make it immune to his attack.
> >
> > No you didn't. It's clear that the attack still applies, although
> > it is more difficult because the attacker would have to break twice
> > as many rounds of the cipher as in the original case. Under
> > reasonable assumptions, it would still be easier than breaking the
> > cipher in a standard mode such as CBC, though.
> >
> > The point is that you should be trying to extend the attack
> > yourself, not making a minor change and relying on others to
> > cryptanalyse it. You won't learn anything that way.
>
> Can I assume that you have the intention to discuss with
> me on an attack very similar to that of Bryan Olson?
Bryan (apologies to him for misspelling his name earlier) has
already covered this in great detail, in the post with message ID
<8s95ea$7eu$[EMAIL PROTECTED]>. The only thing I have to add is
that if the permutation to be omitted was the last permutation,
rather than in the middle, then the equations to be solved would
involve four Feistel rounds rather than two, given the assumptions
stated in Bryan's post. That's what I meant by breaking twice as many
rounds of the cipher.
It should also be obvious that omitting more than one of the
permutations would not help either; the problem is that the security
of the block cipher depends on not leaking information between rounds,
and adding intermediate permutations breaks that requirement.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOep/MTkCAxeYt5gVAQHgBwgAy+jMtLdXJhnFXzoVhWnikSUWR1xV7Ymb
wM6ybe9qhw12g3YA56z0xRW+YhnWT0CRGPlu1tnKGmy6tz/KGYdZEcNMeXvsOO8K
8zVybGfWe+JdLdvP4ZF8o63UhWAk/hlWZG1bj9UedFL1IVAYiNKV+cVV1R5W+Kmz
wOCZzrvUP4VJwvkJtNWWRlEkJx0uN6FUXwWlUipaB7K+OIe5Sb0LW8YkEd2RoL1q
oSlp4fuQVJkWS09oh+L104Q+JuLaXBAhWCXmBa2k1m490WIwqH0m9Wu0I1WLs8ie
Xst40xYw4fqJpF983E2KjGlOETY2+BEPACpA7pCJcQvXliJkWLh/ow==
=tDSy
=====END PGP SIGNATURE=====
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Mon, 16 Oct 2000 18:28:16 +1000
David Thompson wrote in message ...
>Lyalc <[EMAIL PROTECTED]> wrote :
>> Why does every sniffer and every server along the line need to see your
name
>> and address that is embodied in the certificate?
>>
>> Only you and the delivery agent need that information, yet certificates
give
>> it all away, every time the certificate is used. No ifs, no buts,
>> privacy=zero.
>>
>Not necessarily. SET solves this -- for the cardholder --
>by using as the cardholder identifier a keyed hash (HMAC)
>of the account number by a secret opaquely agreed
>between the cardholder (system) and the cardholder CA,
This merely generates a 'fixed' alias, which the merchant is immediately
able to link Buyer_ID to Cert_Alias.
Now, how long before lists start cicrulating the Alias=Buyer_ID mapping?
If merchant DB can't keep CC numbers safe, can they keep an Alias=Buyer_ID
mapping safe for longer than a card expiry period?
>which is in effect the Issuing bank. And assuming
>SHA-1 is noninvertible, unrecoverable by anyone else.
>In effect the cardholder cert guarantees that the signing key
>is for _some_ valid account at the specified Issuer.
>(Or was; SET doesn't revoke cardholder, or merchant, certs,
>using instead existing blocks on underlying accounts.
>SET doesn't use enveloping keys for cardholder,
>so the issue of authenticating them doesn't arise.)
So the merchant is still no better off - they still have to wait for
authorisation and clearing before they know is the transaction is valid (or
not).
Any picking, and packing is still at risk of either expired cert, revoked
cert, insufficient funds, or misused private key.
What does the cert add to this?
Lyal
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: Basic skills and equipment...
Date: 16 Oct 2000 21:31:59 GMT
Hi Bob.
Back on topic, I'd also suggest that one become at least
basically familiar with information theory. The amount covered in
Stinson's book is a good start. More requires more background
in probability and random processes, but that's good to have too.
Not only is it useful, it provides some intuition about
encryption concepts without which people are at a serious
disadvantage. Someone should at least be familiar with
the proof that "perfect secrecy" requires a key at least
as long as the plaintext. A lot of crackpot inventions
would be prevented if people just knew this.
Come to think of it, lack of info theory background, more than
any other branch of mathematics, is possibly the driving
force behind just about all snake-oil. The second most common
snake-oil product is the long-key symmetric cipher, a cipher
with (say) a 1,000-bit key to achieve security comparable to that
of 128-bit ciphers. The creator doesn't have the intuition
necessary to see what is wrong with this, other than just
inefficiency.
-S
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Mon, 16 Oct 2000 21:58:19 GMT
In article <8sfpec$3kv$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <8sflov$8o$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <8sfiv0$tl6$[EMAIL PROTECTED]>,
> > Sure bob, we will have math savants that have no clue on how to talk
> > about cryptography. Smooth move.
>
> You are STILL EVADING the question that was ASKED. The poster asked a
> very specific question. He didn't ask "how can I get an elementary
> intro to crypto?" He did ask "what math background is required?"
Then you should have told the poster to use sci.math or alt.math
instead. His post is irrevelant and off topic.
> Further, learning the crypto is EASY with the right math background.
> Learning it without the background is very HARD.
No, it isn't. I know some people with strong math+computer science
background that don't have a clue about cryptography (despite recently
forming a company to market crypto solutions).
> For someone with so little background and experience, "tom", you sure
> can act like an ignorant and arrogant ass sometimes. I made it clear
> that I was not flaming, yet you found it necessary to be insulting in
> return.
Yadadada.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: pass phrases and key generation (and Kerberos)
Date: Fri, 13 Oct 2000 14:18:08 -0700
I second that opinion. Begining here everything is purely opinion. The
network model that Kerberos uses is overly complex for some situations and
overly simplified for all others conventient ones. While updating Kerberos
to use Rijndael or another new cipher will certainly improve matters
security wise, the requirements are still rather excessive. The arguments
regarding requiring good random numbers in only one place is almost
completely outdated, with the advent of Yarrow, Octillo, and /dev/random
making very good random numbers available cheaply on all hardware. The
abilities of Kerberos to make use of public key architecture are fairly
braindead, requiring resources that are less than optimal or healthful. The
fact that Kerberos continues to make use of ASN.1 encoding makes the entire
system even more frustrating. The key management that Kerberos generally
makes use of makes it quite easy to compromise the entire system. In short,
the entire Kerberos model is outdated, slow, kludgy, ugly, wasteful, and
insecure. It would be far more useful to design a new architecture,
implement it in Linux first, followed by BSD, Windows, Solaris, HPUX, Tru64,
etc in that order. Get the new standard supported by hardware manufacturers
(for things like network printers). I tried to begin a process towards this
at one point, but with input from only one person besides myself it fairly
quickly died (although I may resurrect it at some point). The problem is
examining all the new technologies, from ECC, to SRP, to NTRU, to AES, to
things like Freedom, to whatever I missed, and deciding which ones will be
the most effective/efficient to use, and to decide what
limits/requirements/responsibilities to put in place.
Joe
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ken Raeburn <[EMAIL PROTECTED]> writes:
> > What schemes are preferred for (deterministically) generating keys
> > from pass phrases?...
> >
> > Does a CBC-MAC, using a key and initial vector either predefined and
> > public or derived from the input string, do good mixing and entropy
> > preservation?
>
> CBC-MAC with a fixed IV has the disadvantage that with a one-block
> passphrase (anything <= 16 bytes because AES has 128-bit blocks), the
> passphrase can be decrypted.
>
> I'd try something like:
>
> 1) Compute 128-bit AES CBC MAC of passphrase, with a fixed key and IV,
> preferably secret. Call the result K1.
> 2) Initialize K1 as a 128-bit AES key and use it to encrypt itself,
> i.e. find E(K1, K1).
> 3) Use the ciphertext from 2) as the final key.
>
> > Should I give up on encryption-based schemes and just go with SHA1 (or
> > SHA2 eventually)?
>
> I don't think it matters much. Passphrases aren't a good way
> represent keys in the first place. They should only be used for low
> security applications. Nobody will break even a reasonably good
> password-to-key crunching scheme, if they can instead guess the
> passphrase by brute force, or sneak software onto the user's computer
> to capture the keystrokes and get the passphrase that way, etc.
>
> >[moved from top of message]:
> > I'm looking at putting together a spec for using Rijndael and/or
> > Twofish in Kerberos. ...
>
> It gets slightly off-topic, but can you say if there's any point in
> using Kerberos these days, other than to interoperate with existing
> Kerberized networks? It was a neat piece of software but needed a lot
> of complexity and careful design to do its work using only secret-key
> algorithms. Now that the important public-key patents have expired,
> isn't it simpler to use SSH, SSL, IPSEC, and so forth?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Looking for paper
Date: Mon, 16 Oct 2000 11:52:02 -0700
[snip]
> Assuming that at each step, the order of the A-Zs used
> for the branches is randomly shuffled.
Right there you've done 2 things, you've changed the problem (from static
tree to non-static tree), and by the way you've stated it you've made it
equiavalent to a OTP (each permutation is equally likely, therefore it is a
OTP). Now there will be flaws in the way you implement your "random"
shuffle, and that will be the basis of the attack. My statement was on the
static tree idea, and that is a mono-substitution.
> So instead of a mono-alphabetic
> substitution, we have a mono-dictionary substitution.
You've already changed your stand. First it was a random shuffle, now it's a
choice of relatively optimal compression substitutions. The difference is
substantial, one qualifies as a OTP, the other is a poly-alphabetic
substitution, most likely still weak because you have to communicate somehow
the new tree to use.
> By your reconing,
> this should be easy to solve.
Now you've change the proposal to a poly-alphabet which is still weak.
> Hmm! This would be an interesting
> cryptosystem, anyone want to implement it?
It lacks any interesting amount of strength.
>
> The point is, the unknown symbol length vastly complicates things,
> making it quite different from mono-alphabetic substitution.
It doesn't complicate things much at all
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Public Key Algorithms and Analysis
Date: Mon, 16 Oct 2000 12:00:21 -0700
> There was a thread here in sci.crypt not that long ago about XTR, IIRC,
> which saw some substantial discussion. or maybe coderpunks.
Thanx, I'll dig for it.
> For NTRU, look at Helger Lipmaa's list of lattice links.
Thank you.
> Not sure about RPK, unfortunately.
They actually have a site(http://www.rpkusa.com/), but it's not much help on
the algorithms.
> While you're looking at weird public key cryptosystems, you might as
> well look into the Arithmetica system based on the word problem in
> groups. There was a minor announcement about it here, but see also
> http://www.arithmetica.com/
> I'm not competent to analyse it, but may be worth looking at.
I looked they seem to be more focused on convincing people that it's
completely and totally unbreakable than actually saying anything.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Try This One
Date: Mon, 16 Oct 2000 12:15:11 -0700
> Anyone want to try this one?
No. What we want is for you to read the FAQ, which was posted on the same
day you posted this. Especially the part that says you are not likely to
receive anyone with intelligence telling you anything about your algorithm
for posting ciphertext. Perhaps you'd like to discard your name because it's
of no use here, you've probably already found a great many killfiles.
Joe
------------------------------
Subject: Book, "Battle of Wits" ?
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Jim Haynes)
Date: Mon, 16 Oct 2000 22:23:39 GMT
Battle of Wits by Stephen Budiansky - anybody read this and can give us
a review?
------------------------------
From: "Brian Wong" <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Mon, 16 Oct 2000 18:23:41 -0400
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8sftln$7fh$[EMAIL PROTECTED]...
> In article <8sfpec$3kv$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > Further, learning the crypto is EASY with the right math background.
> > Learning it without the background is very HARD.
>
> No, it isn't. I know some people with strong math+computer science
> background that don't have a clue about cryptography (despite recently
> forming a company to market crypto solutions).
>
Note that Bob Silverman did not say that "everyone with strong math and
computer science background has a clue about cryptography." He stated
that for a person with the correct background in mathematics, it would
be comparatively far easier for this person to learn cryptography than for a
person with no such background.
Brian
------------------------------
From: "Brian Wong" <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Mon, 16 Oct 2000 18:26:13 -0400
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8sflov$8o$[EMAIL PROTECTED]...
> Sure bob, we will have math savants that have no clue on how to talk
> about cryptography. Smooth move.
Arguably, this is better than people who know neither math nor
cryptography. Knowing certain areas of mathematics is a prerequiste
to doing meaningful research work in cryptography; this is not to
say that everyone who knows math is involved in cryptography, nor
should they be.
Brian
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Basic skills and equipment...
Date: Mon, 16 Oct 2000 16:37:34 -0600
Tom St Denis wrote:
<snip>
> > You are STILL EVADING the question that was ASKED. The poster asked a
> > very specific question. He didn't ask "how can I get an elementary
> > intro to crypto?" He did ask "what math background is required?"
>
> Then you should have told the poster to use sci.math or alt.math
> instead. His post is irrevelant and off topic.
<snip>
Tom, are you trolling or are you really as stupid as
that sounds?
JM
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Date: Mon, 16 Oct 2000 22:47:05 GMT
Joaquim Southby <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
[there is nothing that says you have to use a primitive polynomial]
> >It helps - if you want to be able to claim you're not using a short
> >period.
> >
> If one of the state spaces of a non-maximal LFSR contains 99% of the
> possible states for an LFSR of a given length, how could you call
> that a "short" period?
I would not (assuming the LFSR is of a reasonable size in the first
place).
The question then becomes: how do you have the faintest idea what the
period of the LFSR is without looking at the corresponding polynomial's
properties, and checking to see whether it is primitive.
Without performing such a procedure, I don't see how you can claim that
99% of the state spece is covered from a given position - unless you
perform an exhaustive search - something which becomes impractical as
the size of the register grows.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Left blank.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
