Cryptography-Digest Digest #409, Volume #11 Fri, 24 Mar 00 06:13:00 EST
Contents:
Re: Blowfish Code Question - Applied Cryptography 2nd Ed. ("T.Williams")
Re: implementing rot13 (Paul Schlyter)
Re: implementing rot13 (Paul Schlyter)
Re: Blowfish Code Question - Applied Cryptography 2nd Ed. ("Douglas A. Gwyn")
Re: OAP-L3: Answer me these? (Volker Hetzer)
Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean ("Douglas A.
Gwyn")
Re: implementing rot13 ("Douglas A. Gwyn")
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
Re: Prime numbers? (newbie alert -- again) (proton)
Re: Prime numbers? (newbie alert) (proton)
Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean (Jack
Diamond)
Re-seeding PRNG's in central key distribution systems (Mark Currie)
Pegwit for windows ([EMAIL PROTECTED])
Re: implementing rot13 (Terje Mathisen)
----------------------------------------------------------------------------
From: "T.Williams" <[EMAIL PROTECTED]>
Subject: Re: Blowfish Code Question - Applied Cryptography 2nd Ed.
Date: Fri, 24 Mar 2000 10:11:18 +0100
[EMAIL PROTECTED] wrote:
> Sir,
>
> The modulo is implied becuase the word size is 32 bits. Most modern C
> implementations define unsigned int and unsgined long as 32 bit. C
> will let a variable overflow with no comment.
>
> --Matthew
>
> In article
> <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Night Heir) wrote:
> > On page 647-648, within the Blowfish source code, I have a question
> about the
> > function F. I have not taken time to transpose all of the code here.
> The
> > excerpt is basically as follows:
> >
> > ...
> > y = bc->S[0][a] + bc->S[1][b];
> > y = y ^ bc->S[2][c];
> > y = y + bc->S[3][d];
> > ...
> >
> > What happened to the mod operations (there should be two). On page
> 338 he
> > defines the function F as containing S1,a+S2,b mod 2^32 etc. Thanks
> in advance
> > to the group for your input.
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
A minor point but with the advent of 64-bit computing, the "long" and
"unsigned long" C types may be promoted to 64-bit variables by the
compiler (e.g., Sun's Workshop for Solaris). The way around this is to
replace those data types with ones defined as explicitly sized derived
types For example, change "unsigned long" to "uint32_t" (defined through
<inttypes.h> which is tracking the ISO/JTC1/SC22/WG14 C committee's
working draft for the revision of the current ISO C standard, ISO/IEC
9899:1990 Programming language - C, and which m$ ignores). It would
probably be a good idea for those writing reference implementations to
consider doing this to avoid the confusion that comes from implicit
assumptions. Dr. B. R. Gladman, who has implemented all of the AES
candidates, takes a similar approach. The "correct" alternative would be
to include the mod operation in the code if you want to leave the
variable type as an "unsigned long" and you want the value to be "mod
2^32"...
-tom
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: implementing rot13
Date: 24 Mar 2000 08:23:23 +0100
In article <8beap3$[EMAIL PROTECTED]>, Gregory G Rose <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> <>for ( char *s=string; *s; s++)
> <> *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
> <
> <Cute.
> <
> <Okay, the gauntlet has been thrown -- who can do it in even
> <fewer (non-whitespace) characters?
>
> You should have specified the programming
> language, methinks...
>
> tr A-Za-z N-ZA-Mn-za-m
>
> is a shell command that works on linux, GNU and
> BSD-derived Unix systems. (The syntax is
> slightly different on System-V derived versions.)
>
> Since there is an equivalent in Perl, which runs
> on just about anything:
>
> perl -pe 'tr/A-Za-z/N-ZA-Mn-za-m/'
>
> is a very portable alternative (note that I've
> given *complete* programs, with input and
> output!).
Well, if we're free to choose programming language,
the language r13 will yield the shortest program:
r13 a
Now, we only have to specify and implement r13... :-)
> I can't understand why anyone would prefer to use
> C for this job.
Perhaps because C is available everywhere, and many people
(sortof) know C ????
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: implementing rot13
Date: 24 Mar 2000 08:24:05 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Gregory G Rose wrote:
>> tr A-Za-z N-ZA-Mn-za-m
>> ... I can't understand why anyone would prefer to use C for this job.
>
> main(){return system("tr A-Za-z N-ZA-Mn-za-m");}
>
> Getting shorter all the time.
Yep!
main(){system("tr A-Za-z N-ZA-Mn-za-m");}
:-)
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Blowfish Code Question - Applied Cryptography 2nd Ed.
Date: Fri, 24 Mar 2000 09:29:54 GMT
"T.Williams" wrote:
> [EMAIL PROTECTED] wrote:
> > The modulo is implied becuase the word size is 32 bits. Most modern C
> > implementations define unsigned int and unsgined long as 32 bit. C
> > will let a variable overflow with no comment.
Only for unsigned integer types. Otherwise it is platform-specific
what occurs on overflow, which may even be program termination.
> A minor point but with the advent of 64-bit computing, the "long" and
> "unsigned long" C types may be promoted to 64-bit variables by the
> compiler (e.g., Sun's Workshop for Solaris).
I was using C on "64-bit" platforms many years ago, so this is not
a new possibility, it's just more likely to be encountered now.
> The way around this is to replace those data types with ones defined
> as explicitly sized derived types For example, change "unsigned
> long" to "uint32_t" (defined through <inttypes.h> which is tracking
> the ISO/JTC1/SC22/WG14 C committee's working draft for the revision
> of the current ISO C standard, ISO/IEC 9899:1990 Programming language
> - C, and which m$ ignores).
It's not a working draft, it is now an official standard, ISO
9899:1999. If your C implementation doesn't yet provide
<inttypes.h> and <stdint.h>, you can find my parameterized portable
version at URL http://www.lysator.liu.se/c/q8/index.html , along with
other pieces of the C99 library that might be missing.
Note that there is no requirement that *any* of the integer types
be exactly 32 bits wide, although most C implementations do have
at least one such type.
> It would probably be a good idea for those writing reference
> implementations to consider doing this to avoid the confusion that
> comes from implicit assumptions.
True; better yet, when feasible code in a platform-independent way.
> The "correct" alternative would be to include the mod operation in
> the code if you want to leave the variable type as an "unsigned long"
> and you want the value to be "mod 2^32"...
Well, that's a problem since 2^32 cannot be represented in 32 bits.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Fri, 24 Mar 2000 09:37:16 +0000
Anthony Stephen Szopa wrote:
> You are sure a great talker. I wonder how many of you are busily
> studying OAP-L3 theory,
Everybody who has *access* to that theory. Which is -- nobody.
> It appears that you (and most others) have willfully chosen not to
> address the theory, and specification of the procedures and
> processes. This should be noted by all readers to this news group.
Tell us the theory, then we'll address it.
> It appears that the attack has admittedly been chosen to be an
> attack on the implementation. No other options?
Nobody has bothered to "choose" an attack. The goal is to point
out weaknesses. If you want it for free, provide the source code.
> I thank many of you for unintentionally giving me such credibility
> (short-lived or not.)
This is not a chatroom, y'know? People take their time to follow
threads and look up references (and funny patents). So, forget it.
> By the way, OAP-L3 Version 4.3 will be available in about a week
> or so. Six new processes are being added to mix things up even
> more.
Wow! The more "processes", the more secure. I'm impressed.
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Date: Fri, 24 Mar 2000 09:41:43 GMT
"John A. Malley" wrote:
> Has anyone ever read "THE DES, An Extensive Documentation and
> Evaluation, Mikael J. Simovits" from Aegean Press?
Yes, it's in my personal library.
> If you bought it and read it, would you recommend it to someone
> interested in learning more about differential and linear
> cryptanalysis?
That depends: "more" than what? It has nice explanations as
far as their application to DES. I think it's a pretty good
book, overall.
> Does it provide examples?
Yes.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: Fri, 24 Mar 2000 09:53:40 GMT
Paul Schlyter wrote:
> > main(){return system("tr A-Za-z N-ZA-Mn-za-m");}
> main(){system("tr A-Za-z N-ZA-Mn-za-m");}
Hm, I guess that's fair, since it already assumes a certain
environment (i.e. is not strictly conforming).
#include "a"
is probably unfair, however..
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 24 Mar 2000 09:51:36 GMT
In a previous article, Jerry Coffin <[EMAIL PROTECTED]> writes:
>ECB encodes each block completely separately from all the others, so
>if an attacker knows the contents of a particular block, they know
>what they block will encrypt to with any particular key. With the
>other modes, the blocks are chained together (with an Initialization
>Vector as the first block) so they won't know this ahead of time. In
>descending order of preference, I'd use CBC, CFB, OFB and finally, if
>I had NO other choice, ECB.
You may make CFB and CBC modes sound better than they are. In fact, if you
know then key and cipher (= E_k) and only two adjactent plain text blocks
p(n-1) and pn, then you know ahead of time what the cipher block cn will be.
Hence, the complexity is increased compared to ECB mode, but not that much.
Using a stronger cipher would probably often be a better way to increase
security than to go from ECB mode to either CBC or CFB mode.
It should also be noted that any cipher in OFB mode is vulnerable to any
attack that works against OTPs (= one time pads), and some of these attacks
does not work against a cipher in ECB mode. Hence, for e.g. financial
transactions one might argue that the order of preference should be CBC, CFB,
ECB and lastly OFB.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 24 Mar 2000 10:00:30 GMT
Pardon. The correct line should read:
In fact, if you
know then key and cipher (= E_k) and only one cipher block
c(n-1) and the adjactent plain text block pn, then you know ahead of
time what the cipher block cn will be.
In a previous article, < [EMAIL PROTECTED]> writes:
[--cut--]
>... In fact, if you
>know then key and cipher (= E_k) and only two adjactent plain text blocks
>p(n-1) and pn, then you know ahead of time what the cipher block cn will be.
[--cut--]
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: Re: Prime numbers? (newbie alert -- again)
Date: Fri, 24 Mar 2000 11:09:25 +0100
Bob Silverman wrote:
>
> >
> > Would a prime number instead of an ordinary number
> > be better for creating randomness?
> >
>
> What do you mean by this????
> What scheme are you thinking of when you say "ordinary number"?
>
> If one is using (say) a PRNG based on (say) a Fibonacci generator
> or linear congruential [then combined with something else], prime
> numbers are indeed better because they create longer periods.
> They are also essential for (say) the Blub-Blum-Shub generator.
>
> Other than this, I am not sure what you mean. Your question is so
> vague, that I am not even sure that you know what you mean.
Mainly what I was interested in was wether prime numbers vs. non-
prime numbers provided any benefit in `PRNG's as you call it
(didnt actually see that acronym until yesterday).
> > I've also understood how the RSA algorithm works
> > as its explained in the crypto faq. But I still dont
> > understand *why* it works
>
> It works because if N=pq and e are public, then
> M^e Mod N is invertible because e has a multiplicative inverse mod
> phi(N). The rest follows from Lagrange's theorem.
>
> What further "why" are you looking for?
>
I was wondering why `(de-1) mod (p-1)(q-1) = 0' created this
numeric magic. The numbers involved were too big for me to
see any relation right away (but it feels like Im starting to
get a clue).
Your terminology is unfortunatly pure greek to me.
> >
> > Heh, one final warning too. My math skills arent all
> > that good. I barely understood the short RSA description
> > in the crypto faq and managed to verify it on my own
> > (with alittle bit of help from `bc' =))
>
> Therefore the first thing you need to do is improve your math
> skills. Start with any good book on elementary number theory.
The last few years ive learned most by `consuming' a bit at a
time. And its alot more fun than learning just theory and not
having anything to apply it to. It also gives me a better
understanding of the whole thing when I can directly point to
a problem, say `I need to learn the maths to solve this' and
then actually go out and find the answers.
Most of yous probably disagree with this method since you have
to put up with my silly questions when Im trying to learn about
crypto. But atleast Im not forcing you to answer my questions.
> How did you 'verify' that RSA is correct using bc?
> The best one could do is verify some examples. But this is not
> the same as verifying the math.
I verified an example. I dont know enought number theory to start
whacking away at verifying the theory itself. `bc' because my
calculator only handles ~11 figures, which is probably only enough
to verify p=5,q=7 or something to that effect.
Im no good at theory, Im just trying to learn a bit of it so that
I can use when Im programming. In some of my projects (both in-head
and in-bits) there would be need for crypto or crypto would provide
nice benefits. So I figured that I could assimilate bits and peices
of information about small helpfull items here.
Was I wrong?
/proton
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: Re: Prime numbers? (newbie alert)
Date: Fri, 24 Mar 2000 11:20:20 +0100
Tom St Denis wrote:
>
> Jerry Coffin <[EMAIL PROTECTED]> wrote
> > > I've also understood how the RSA algorithm works
> > > as its explained in the crypto faq. But I still dont
> > > understand *why* it works, and if prime numbers are
> > > required for it to work...
> >
> > It's _possible_ to encrypt and decrypt correctly using a pair of
> > composite numbers, but composites that will work this way are quite
> > rare; primes are much more common.
>
> Actually if you know the factorization of the composite (p, q) [either one]
> then you can still calc phi(pq) and get rsa to work. For example if q were
> prime, and p = 2r, where r is prime, then the order of the group is just
> (q - 1)(2 - 1)(r - 1)...
One question that comes to mind: Can there be more than one public key
(e) ?
> > > And to those who immediately thinks I should go buy
> > > a book: I cant afford books at the the moment..
> >
> > You might want to look at the "Handbook of Applied Cryptography",
> > which is available freely online. I'm sorry, but I don't have the
> > URL handy right now; you should be able to find it fairly easily.
> The URL is http://cacr.math.uwaterloo.ca/hac/
Downloading it right now =)
/proton
------------------------------
From: Jack Diamond <[EMAIL PROTECTED]>
Subject: Re: "THE DES, An Extensive Documentation and Evaluation" - from Aegean
Date: Fri, 24 Mar 2000 10:34:45 GMT
DES is filled with trap doors, so you might learn as much by doing
simple distribution analysis and finding them.
Jack
"John A. Malley" wrote:
>
> Hello all,
>
> Has anyone ever read "THE DES, An Extensive Documentation and
> Evaluation, Mikael J. Simovits" from Aegean Press? Aegean Press' web
> site outlines the content as follows:
>
> Chapters include: History of the DES and Fundamental Theory;
> Differential Cryptanalysis;
> Linear Cryptanalysis;
> plus various appendices.
>
> If you bought it and read it, would you recommend it to someone
> interested in learning more about differential and linear cryptanalysis?
> Does it provide examples?
>
> Thanks,
>
> John A. Malley
> [EMAIL PROTECTED]
------------------------------
Subject: Re-seeding PRNG's in central key distribution systems
From: [EMAIL PROTECTED] (Mark Currie)
Date: 24 Mar 2000 10:52:08 GMT
Hi,
Consider a system where public and private keys are generated by a central
source and distributed to users (often the case in smart card systems). For
this example we will assume that RSA(CRT) public and private keys are issued to
users (possibly on smart cards). If the private RSA prime factors p & q are
found using the output of a prng, it may be possible for a user (knowing his
private keys p & q) to predict what other user's private keys are. Since his p
or q (depending on which one was generated last) can reflect the last state of
the prng, he can predict what the next state will be. He can use the same
algorithm as the central authority to find the next primes for p & q. He can
continue with this for all subsequent user keys until the prng is re-seeded.
This kind of attack may be applicable to other non-RSA(CRT) implementations as
well.
In general when using a central key distribution system, it should be a rule
that if a prng is used then it MUST be re-seeded from a quality random source
before each new key set is generated. This might seem obvious, but depending on
what type of seeding process is used, it could be a fairly slow operation and
therefore tempting to only do every-now-and-again.
Mark
------------------------------
Crossposted-To: alt.security.pgp
From: [EMAIL PROTECTED]
Subject: Pegwit for windows
Date: Fri, 24 Mar 2000 10:55:10 GMT
###
I made pegwit gui for windows
it is a program for performing public key encryption
and authentication using elliptic curve
based on Pegwit v8.71 by George Barwood
if you can get and try it from:
http://disastry.dhs.org/pegwit/
--
Disastry
http://i.am/disastry/
### end pegwit v8 signed text
ee231415f602c001d25fd0cb1e3f3ee2c078ad5b2b182a1e9e06867e6b0d
db3294b334e8519204dbc9bb45d301a5c1610477bb02b871b18384dba698
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: implementing rot13
Date: Fri, 24 Mar 2000 11:52:38 +0100
[EMAIL PROTECTED] wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Day wrote:
> > >Why not instead:
> > >for ( char *s=string; *s; s++)
> > > *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
> >
> > Cute.
> > Okay, the gauntlet has been thrown -- who can do it in even
> > fewer (non-whitespace) characters?
>
> replace 'A'+13 with 'N'
replace 'N' with 78
?
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
** 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
******************************
