Cryptography-Digest Digest #23, Volume #13 Sat, 28 Oct 00 05:13:00 EDT
Contents:
Re: ISO an SHA-1 Implemention in Javascript (Janne Tuukkanen)
Re: CHAP security hole question (Vernon Schryver)
Re: Applied Cryptography software. (JPeschel)
Re: End to end encryption in GSM ("JASON BROWN")
Encryption scheme ideas? ("Ethics")
Re: Is OPT the only encryption system that can be proved secure? (Richard Heathfield)
Re: frequency analysis (Richard Heathfield)
Re: Rijndael and PGP (Richard Heathfield)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: very large mult. div. (Mok-Kong Shen)
Re: Q: Computations in a Galois Field (Mok-Kong Shen)
Re: very large mult. div. (Richard Heathfield)
Re: Is OPT the only encryption system that can be proved secure? (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Janne Tuukkanen <[EMAIL PROTECTED]>
Subject: Re: ISO an SHA-1 Implemention in Javascript
Date: Sat, 28 Oct 2000 09:06:45 +0300
Arnold Shore wrote:
> Will appreciate any information on subject matter availability. I'm aware
> of a couple of MD5 implementations around, but haven't found an SHA source.
> Thanks, folks.
I've made one but it's not very good. Hmm... I really should make it
ready. It has no padding, but thats only matter of bothering. More
serious are problems in implementations of integers in different
browsers.
Altough Ecma-262 says they should be 64 bit, they are in fact less
than 32 bit, signed and implementation independent. For serious usage
the code should be tested in all JavaScript capable browsers, 16 bit
versions also, so I think it should be made in one byte arithmetics
and that wouldn't be beautiful at all. On the other hand I would like
to see it in WMLScript also, and God knows what cell phone
manufacturers have invented in their own versions of ecma-262...
I'll look around if I still could find the piece of source somewhere.
JanneT
p.s. If someone knows implementation of Rijndael in JS, I would be
interested. I'm so newbie in this area, that I really haven't
more than partially understood how it should be done -- or
even started. Reasons mentioned, I think the 8 bit aproach
would prevent incompatiblies between language implementations.
> Arnold Shore
> Annapolis, MD USA
--
Fools ignore complexity
Janne Tuukkanen Pragmatists suffer it
[EMAIL PROTECTED] Some can avoid it
Geniuses remove it - A.J.Perlis
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 28 Oct 2000 00:10:29 -0600
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> ...
>> In other words, beware of technical information from sales people.
>
>I'm curious as to what claims you don't agree with. I think it's pretty
>clear these days that weak password systems are rapidly becoming a
>weak link in the crypto chain, and that strong password systems should
>be phased in to replace them in systems with any serious security
>requirements.
What I don't like is the salesmanship on those web pages, the gross and
misleading eaggeration and the overly broad and false generalizations.
E.g. on http://www.IntegritySciences.com/password.html the obviously false
With obsolete network password protocols, whoever goes first
gives away the password.
Passwords are a problem, but "rapidly becoming a weak link in the crypto
chain" is overstated. Passwords can't be the weak link until there real
encryption is common. It's decades late to be warning about the evils of
weak paswords. Yes, what was once a good, strong password is now almost
as weak as your mother's maiden name, and what is now a good strong
password is hard for humans to remember. However, the best I can see
through the smoke at those web pages is that Integrity Sciences' solution
is one among several--never mind the worst that the pages suggest to me.
It is not always possible or even desirable to verify passwords on line
for any of the many meanings "on line," unless you happen to be selling
an on line key verifying service (e.g. Verisign) or a a new protocol that
makes all previous protocols obsolete.
http://www.IntegritySciences.com/obsolete.html says meakly:
All of these password methods are now obsolete because of the
development of practical zero-knowledge password proofs.
Besides, authentication is only one part of security, and good passwords
(for any measure of goodness) are only a part of authentication.
For example, as I understand it, Friday's big deal about people outside
Redmond interested in Microsoft source was based on a trojan horse, perhaps
facilitated by a particular infamously insecure mail user agent.
(http://interactive.wsj.com/articles/SB972663334793858544.htm
may require a subscription.)
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Applied Cryptography software.
Date: 28 Oct 2000 06:50:26 GMT
[EMAIL PROTECTED] writes, in part:
>Hi, I was wondering if it's legal (I don't want to rip anyone's honest work
>off) to download the sources from "Applied Crytography" by Bruce Schneier.
Yes, if you mean the source code from the AC disk. You can find
it on many ftp sites. Is it ethical? I dunno if Bruce wanted his
disk made available for free. The files I've seen are pretty old, though.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "JASON BROWN" <[EMAIL PROTECTED]>
Crossposted-To: nl.comp.crypt,alt.comp.opensource,alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Sat, 28 Oct 2000 01:57:43 -0500
"Jouni Hiltunen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Greetings, first apologies in cross posting this to
> hell and back, but I'm really interested in
> extending privacy to cellular communications.
Something tells me I know what's coming here ....
> Here is the problem, present GSM system offers you
> an illusion of privacy, communications are
> supposedly secured by encryption.
No, they are actually secured by encryption.
>However, depending
> on the operator and country you might have weak or
> no encryption and no way to verify how your
> communications are secured.
Not true. GSM Phase 2+ handsets indicate the no encryption case. But lets
get real here - do you really think indicating the algorithm in use would
mean anything to the average user? How many calls to customer care would it
generate for no obvious benefit?
>To make matters worse, standards require
> manufacturers to design legal interception gateways
> into the switches.
No, standards do not. Government agencies do. Also, note your own use of the
adjective "legal" here and everything will become clear to you.
> What I have in mind is program which you could
> download into your phone which allows Diffie/Hellman
> key exchange and encryption of the following call to
> make sure your private conversations remain private.
Ha!
> Anyone interested in e-mailing me, please use the
> public key below. Post the follow-ups to sci.crypt
Really, you should do some research before being so opinionated on a subject
which you clearly know nothing about.
------------------------------
From: "Ethics" <[EMAIL PROTECTED]>
Subject: Encryption scheme ideas?
Date: Sat, 28 Oct 2000 00:03:06 -0700
Hey all,
Just though you might be able to help me identify the encryption scheme
used to encrypt this...
The word is : juris
The encrypted word is: [x\p_Cr|guh@XP
ANY ideas would be helpful....
Ethics
[EMAIL PROTECTED]
------------------------------
Date: Sat, 28 Oct 2000 09:17:22 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
>
> >Richard Heathfield wrote:
> >
> >(Sorry to reply to my own post: I forgot to post my source code. Can't
> >have Mr Scott thinking the worst, can we?)
>
> I guess your not perfect then.
Of course not, and I never claimed I was.
<snip>
> You proved you have a few functions that MIGHT work.
<shrug> If they're broken, let me know and I'll fix them. It's not as if
I subjected them to a rigorous test regime. But the idea is sound
enough, even if the code isn't. But I have no reason to believe the code
is broken, and the brief workout I gave it provides promising results.
> But I agree what you have seems to compile without warnings
> which you seem to value highly.
Yes, I do. Diagnostics are the only way a compiler has to tell you
what's wrong with your code. Since I like my code to actually work, I
turn up the diagnostics level to the max, and pay attention to every
diagnostic.
(On /very/ rare occasions, I find that I disagree with the diagnostic.
On such occasions, the correct course of action IMHO is to add a comment
to the code explaining to future maintainers exactly what the diagnostic
means, why it occurs, and why the code has not been changed as a
result.)
If you liked your code to work, you too would pay attention to
diagnostics. Since you clearly don't care about diagnostics, I must
conclude that you aren't fussed whether your code works or not.
> Wether they work in my porgram or not is another question.
I agree. Actually inserting well-defined code into a program like yours
could turn out to be too much of a culture shock.
> And wether they are faster is still yet another question.
1) <shrug> I bet Get_nBit_Int() works a damn sight faster under Linux
than get19() does.
2) Performance isn't (or, at least, wasn't) the issue here. You said it
was simply not possible to do this in portable C. But I have shown that
it is not only possible but trivial.
3) If speed is so crucial to you, why is your program so bloody slow?
>
> >diagnostics at all on any of the platforms. But I challenge you to find
> >anything non-portable at all in it.]
> >
>
> I can't say it completely works more tests would have to be done.
Fine. Do them.
> However if it does work and takes not to much more time wise I may
> include something like this as an option to my specail include file.
No, don't do that. These functions belong in C files, not H files. They
are source code, not type definitions.
> I saved the file and will look at it when I get to it.
So your comments about the code have been based entirely on a quick
glance? That doesn't sound too bright. But maybe there's something about
the code you don't understand. If so, please point out the lines of code
you're having trouble with, and I'll do my best to explain.
> But I have to
> warn you people made numberous comments on scott16u most where wrong
> about how it worked.
a) I have never commented on scott16u.
b) If it's anything like scott19u, I am not surprised people found it
hard to follow.
> And what people said would work faster did not.
The way to optimise scott19u is to ditch it altogether. I don't know how
you manage to make it so slow, but it can't be the fault of anything but
the algorithm. I'm not claiming I understand the algorithm - I don't.
But I do know that it's significantly slower than other algorithms, and
also can only be built by one compiler. Throw it out and start again,
this time choosing a faster algorithm - if it's O(n^3), try to make it
O(n^2) and that would probably be a good enough improvement.
> But I can see that for most C's there will be an implementation
> problem in general so this might great help to someone interesting
> in converting it to another compiler. Thanks!
You're welcome. So is anyone else who wants to use that code. Credits in
the source code comments would be appreciated where appropriate.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Date: Sat, 28 Oct 2000 09:28:48 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: frequency analysis
JPeschel wrote:
>
> [EMAIL PROTECTED] writes:
>
> >If the cypher is half decent [anything more than a monoalphabet] that
> >approach will not work. I know of no such program, however one could write
> >such program over lunch.
>
> The results of doing single-character
> frequency analysis, in addition to
> solving monoalphabetical ciphers, help
> you eliminate other cipher types.
Hurrah! I was planning to write one anyway, so it's good to know it will
be useful.
> There are a lot of single-character
> frequency analysis programs around.
> Seems to me Gwyn wrote a short one
> here a while back, and I'll bet he
> typed it nearly as fast he would type
> any other short message.
09:30:00 BST
#include <stdio.h>
#include <limits.h>
int main(void)
{
size_t freq[UCHAR_MAX + 1] = {0};
int ch;
while((ch = getchar()) != EOF)
{
++freq[(unsigned char)ch];
}
for(ch = 0; ch <= UCHAR_MAX; ch++)
{
printf("Character: %02X Frequency: %lu\n", ch, (unsigned
long)freq[ch]);
}
return 0;
}
09:31:49 BST
:-)
Unfortunately, this doesn't sort the frequency table (pipe it through
sort instead) and it doesn't do anything clever like deciphering. But
I've decided my time would be better spent on this kind of program than
on trying to make sense out of someone else's nonsense, so watch this
space.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
Date: Sat, 28 Oct 2000 09:41:05 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Rijndael and PGP
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] wrote in <8tciik$31q$[EMAIL PROTECTED]>:
>
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >> I disagree strongly.
> >Right there you've given enough information for a reasonable person to
> >strongly agree. Of course it doesn't hurt that you have contradicted
> >the statements of every major cryptanalyst, made a mockery of yourself,
> >and been a pretender to the thrown for as long as I've been around.
> >
>
> I'm retired so I don't have to kiss ass. I am still allowed
> to tell the truth. I have never been a pretender to the throne
That's not what he said. He said "thrown", not "throne". It was a pun,
which is a kind of joke based on homophones which have distinctly
different spellings and meanings.
As for telling the truth, you claim to be a former Government Real Time
Computer Expert, yet you can't spell "Government" consistently (in fact,
you can't spell /anything/ consistently, but we'll skip over that), your
code is so slow that it can't even run in Pretend Time, let alone real
time, and as for being a computer expert, you don't even properly know
the definition of the language in which you program, and are incapable
of understanding the importance either of portability or of compiler
diagnostics. If you are indeed telling the truth about all this, you
make a mockery of your Government's staff selection procedures.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On introducing non-interoperability
Date: Sat, 28 Oct 2000 11:01:29 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> >I suppose I don't yet understand you. If the opponent
> >want to determine the key, the xor-ed unknown quantities
> >cause him difficulty. Or can you tell your trivial way to
> >get around this? Thanks.
>
> Ah, I should have read your post more carefully. That's whitening, not
> eliminating interoperability. That is a legitimate technique (i.e.,
> DESX), although it doesn't interfere with differential cryptanalysis
> if one is just XORing a fixed quantity.
If you consider any xor-ing is whitening then it is whitening.
Note that the term whitening applies, as far as I know, only
to plaintext. Here it is keyscheduling that get's modified.
(BTW, the round keys can also be permuted.) You could also
regard that to be a way of extending the key. I said that
the quantities can be updated as desired. So you could change
them each time the key is changed.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: very large mult. div.
Date: Sat, 28 Oct 2000 11:01:35 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tom St Denis wrote:
> > >
> >
> > > Now we expect them to immediately purchase a 65 dollar book because
> you
> > > said so? hmm fishy.
> >
> > Are the public libraries in your region fairly poor?
> > Just interested.
>
> Visit Kanata and see for yourself.
I assume that in Canada the public libraries are inter-
connected like here in Germany. I can e.g. get books
in a library somewhere in northern Germany, if these are
not present locally. It takes some time. But I'll get
them nonetheless.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 28 Oct 2000 11:00:28 +0200
Tom St Denis wrote:
>
> Well it's either a "little help that may be wrong" or "none at all". I
> remember when I was trying to learn (and still am) rudimentary
> cryptanalysis that often I would get a "never-reply". Only once in a
> while (like from Mark Wooding...) a good post would come up...
>
> I doubt that virtually all of my posts are wrong, so I hope what little
> I have right may help.
Nobody is perfect. Even a Prof. may occasionally commit
errors. But important is that one should take as much
care as possible to avoid eventual errors. One makes a
(subjective) estimate of the probability of error based
on one's own estimate of one's knowledge in the specific
issue under discussion. If that's too high, then it is
better to say nothing. More important I think is always
to try to keep the discussion in an atmosphere that is
agreeable as possible. Exchagce of non-scientific
querulousness doesn't contribute to the advandcement
of science.
If one's posts don't get follow-ups, there could be many
reasons. (1) The material is o.k., there is nothing to
comment on. (2) The presentation is so miserable that
people hate first to ask for clarification and then see
if they could comment. (3) The topic is entirely irrelevant
to the group. (4) The material is too difficult or would
cause people too much time to give comments. Note that
people are not paid to comment. (5) One has in the past
obtained the reputation of being a very bad discussion
partner so that people fear to get to be involved. There
could conceivably be other essential reasons.
M. K. Shen
------------------------------
Date: Sat, 28 Oct 2000 10:01:04 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: very large mult. div.
Tom St Denis wrote:
>
> The series are good (well the third volume is a bore) but the first two
> (espescially the second) are a quite cool.
<cough>
The third volume is on sorting and searching, and is absolutely
fascinating. (I find the first two fascinating too.) How you can find
sorting and searching to be boring is beyond me.
Perhaps you'd have found it more interesting if it had included more on
combinatorial algorithms (there is a little, but not much). Watch that
space - I believe (on no firm evidence whatsoever) that Vol 4 will cover
this fascinating and (for sci.crypt) topical subject.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Date: Sat, 28 Oct 2000 11:19:01 +0200
Terry Ritter wrote:
>
> Mathematical proofs concern models which may not, and probably do not,
> exist in practice. It is important to keep the distinction in mind.
Even practically possible models may not always apply in
one's specific applications. So, if a cipher, say, is easily
crackable under chosen ciphertext attack but practically
secure with respect to the other possible attacks, then it
is o.k. if one knows that the vulnerable attack is impossible
in one's specific environment. If a certain attack needs
huge amounts of materials processed by a single key and
one takes care to change key very often or even employ
variable keys (for blocks) then that attack is irrelevant
in one's application. Such academic attacks are certainly
important though for the science in long terms and also
for the scientists in short terms (because of 'publish
or peril').
M. K. Shen
------------------------------
** 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
******************************
