Cryptography-Digest Digest #916, Volume #9 Tue, 20 Jul 99 15:13:03 EDT
Contents:
Re: SSLeay for HP-UX (Eric Young)
Re: Q. Passphrase Key-Rate Authentication (Paul Crowley)
Scheier's "Solitaire" is biased and non reversible (Paul Crowley)
Traffic Analysis (Roger Carbol)
Re: Looking for RC4 alternative ("Larry Ellis")
Re: Logic based ciphers (Mok-Kong Shen)
Re: [Q] Finding K from P and C (fungus)
Re: WinZip secure? ([EMAIL PROTECTED])
Re: linear complexity of Lagged Fibo Generators (Fiji)
Re: A Good Key Schedule (Mok-Kong Shen)
Re: another news article on Kryptos (Mok-Kong Shen)
Re: Length of public key in PGP? (Jim Felling)
Re: How Big is a Byte? (was: New Encryption Product!) (wtshaw)
Re: [Q] Finding K from P and C (wtshaw)
Re: (good) Calculator ("Michael Scott")
(good) Calculator ("Vincent")
Great New Cryptology Web Site (John Forrst)
Re: Crypt Dll for VB (Medical Electronics Lab)
Re: Replacing IDEA with Blowfish (Paul Koning)
Re: Free chapters from Handbook of Applied Cryptography (Paul Koning)
Re: DES permutations (Paul Koning)
Re: Meta-Certificate Group moved site? (Medical Electronics Lab)
Re: Great New Cryptology Web Site (John Savard)
Re: Does base64 encoding lessen security? (Michael Slass)
Re: SSLeay for HP-UX (Stefek Zaba)
Re: Looking for RC4 alternative ("Roger Schlafly")
----------------------------------------------------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: SSLeay for HP-UX
Date: Tue, 20 Jul 1999 21:43:06 +1000
[EMAIL PROTECTED] wrote:
>
> Has anyone successfully build the SSLeay shared library on HP-UX 10.x?
If you are using the native C compiler, you need to have NO_PROTO and
NO_CONST defined. It is a very primitive compiler.
I believe openSSL will not compile with the native HP-UX cc anymore,
they did not consider non-ANSI compilers worth supporting.
The Configuration script should contain the relevant parameters
for the HP-UX build.
eric (who should not really be commenting about SSLeay :-)
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q. Passphrase Key-Rate Authentication
Date: 20 Jul 1999 10:34:53 +0100
[EMAIL PROTECTED] (John Savard) writes:
> There's a fundamental limitation of biometrics that works against
> this. While a computer program can certainly compare a person's
> typing style with a template, and produce a yes/no answer, that's
> because it will apply tolerances in a fancy, almost intelligent
> manner.
>
> Any scheme of assigning a code to a particular typing style,
> therefore, won't produce the same code each time that user types.
I like your solution to this. Another might be to include information
that can be used to identify the correct key when it is found, and
then search neighbouring zones for a match as well as the zone found.
In the case of your five-dimensional space, this means searching 243
zones.
However, Schneier cautions against treating biometrics as secrets in
Cryptogram.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Scheier's "Solitaire" is biased and non reversible
Date: 20 Jul 1999 10:38:20 +0100
Roger Carbol <[EMAIL PROTECTED]> writes:
> Besides, I think Solitaire is neat enough to get squeezed into
> the FAQ somehow.
Hmm. See http://www.hedonism.demon.co.uk/paul/solitaire/
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
Subject: Traffic Analysis
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Mon, 19 Jul 1999 15:41:36 GMT
It seems like I haven't read very much in this newsgroup about
traffic analysis. It seems like an avenue of attack which is often
neglected by both the White Hats and the Black Hats.
Has anyone set up a system (that they can talk about) which regularly
sent out a lot of noise? Any interesting phenomena arise?
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: "Larry Ellis" <[EMAIL PROTECTED]>
Subject: Re: Looking for RC4 alternative
Date: Tue, 20 Jul 1999 09:25:54 -0500
Larry Ellis <[EMAIL PROTECTED]> wrote in message
news:bhUk3.10489$[EMAIL PROTECTED]...
> >
> > I know for certain that we CANNOT use RC4 in our release product (what a
> > shame, as it's so easy to code), so I'm really keen to hear of
alternative
> > stream ciphers we can use for free. Our product is for a niche market
> where
> > only superficial hacking might be expected, so ease of coding is more
> > important than super strength scrambling.
>
> I don't know why ease of coding is an issue, since there is an assortment
of
> alorithms available with good source code examples.... Blowfish, Twofish,
> and TEA are all easy to find. These are block ciphers but are trivial to
> adapt for stream mode (see "Applied Cryptography", Schneier).
>
> If you insist on very short simple code, try TEA (be sure to use the
> "Extended" variant). I have the (very brief) papers on Tea and XTEA, and
> can email them to you if you like. TEA has been the subject of a few
> security concerns in this group, but it sounds as if it may be adequate
for
> your needs.
>
>
Oh, and BTW, don't expect many algorithms to be as fast as RC4. If you want
a superfast, but new and unproven algorithm, take a look at Panama. Once
again, good working code is available (for C). And, as with all the other
algorithms I've mentioned, the algorithm is free.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Logic based ciphers
Date: Tue, 20 Jul 1999 16:34:19 +0200
Gabriel Belingueres wrote:
>
> Exists any cryptosystem, witch is based in the semi-decidibility
> property of first-order logic, or based in the undecibility property of
> second-order logic?
I don't know. But I suspect that there wouldn't be such systems in
practice in the near future because doing logic with computers is
currently generally slower (in some superficial comparative sense)
than number crunching. This is anyway my impression gained through
some experience in logic programming, though I can't exclude my
being wrong.
M. K. Shen
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: [Q] Finding K from P and C
Date: Tue, 20 Jul 1999 14:25:09 +0200
Jim Gillogly wrote:
>
> Sungmin Chun wrote:
> > E(P, K) = C
> > where
> > P : Plain text
> > C : Cipher text
> > K : Key
> > E(P, K) : Encryption method
> >
> > Can we find K easily for well-known E(P,K)
> > when P and C are given?
>
> It depends entirely on E.
But for any "good" E, the answer is no.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: WinZip secure?
Date: 20 Jul 1999 09:03:02 -0400
Nam, Bo-hyun <[EMAIL PROTECTED]> wrote:
> I want to know how much secure zipped file with password.
> Are there methods to crack zipped file with password?
The encryption is terribly weak against a known plaintext attack (the
encryption first compressses the file and then encrypts ... known
plaintext is obtaining a version of the file compressed the same way (but
not encrypted) -- one may have to change default parameters to compress a
file the same amount as another ZIPping programme).
Known plaintext is not that hard to get (e.g. my computer came with a
RESTORE disk -- not a Win95 disk so if I got a corrupted file, I had to
redo the whole hard disk, losing anything I had installed and go back to
the original setup ... the files were ZIPped with password protection ...
but I had files on my hard drive from the archives! so I had known
plaintext once I checked that using PKZIP2.04g gave the same compression
and easily found the passwords) (e.g. someone posts a password protected
programme on his site and sends out the password to those who register ...
and inside is included a graphic of his logo which is also on his web page
... BOOM!) (someone sends you a password protected ZIPped message along
with a notice (in the archive) that he also sends out to others ...
BOOM!).
PKCrack (I believe) will crack such files (NOTE: It generally does NOT
give the password. The password is hashed to get three keys that are used
in the encryption. Those keys, all that are necessary to decrypt the file,
are obtained. Finding the password that hashes to those values is hard,
unless the key is small ... so you may be able to decrypt a ZIP/encrypted
file, but not find the password ... in the case of my RESTORE CD for my
computer, the password was short, so I could recover it).
------------------------------
From: Fiji <[EMAIL PROTECTED]>
Subject: Re: linear complexity of Lagged Fibo Generators
Date: Tue, 20 Jul 1999 09:52:06 -0400
Tom,
I bought the 2nd volume this past weekend at Borders. I believe it cost
me @$60.
-Fiji
On Thu, 15 Jul 1999 [EMAIL PROTECTED] wrote:
> Where could I find a formal introduction into the linear complexity of
> lagged fibonacci generators? What I want is something describing the
> period of each bit in the generator.
>
> For example the first bit is a LFSR so it has a period of 2^r - 1. The
> second bit has a period of ? and the next ?
>
> I bet this is how they actually calculated the length (period) of these
> generators. But I would like to learn it myself.
>
> And I don't have access to Knuth's 2nd Volume so please snippets or
> online info. I really want to get the book but lack-o-moola prevents
> me... (How much is it anyways?)
>
> Thanks,
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A Good Key Schedule
Date: Mon, 19 Jul 1999 17:44:14 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >I have the impression that you are attempting to combine stream and
> >block encryption techniques,
>
> Oh, yes, I think that is a good combination. However, that isn't
> really the major point of this post.
Could you elaborate a bit. I am sorry that I haven't captured yet
the most essential aspect of your post.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Tue, 20 Jul 1999 16:25:02 +0200
Douglas A. Gwyn wrote:
> Actually, the idea of running billions of guesses isn't very
> productive when you don't know what kind of system you're dealing
> with. If I were analyzing it, which I don't currently have time
>
Could the present instance be interpreted to mean that there is
some substantial advantage in letting the analyst to guess what
encryption algorithm one uses? The search space of the analyst could
apparently be much enlarged through variabilities realized not only
in switching from one to another of a set of algorithms but also
in rendering, where feasible, the algorithms suitably parametrized
(e.g. with variable round numbers, block sizes, etc.), with different
parameters being chosen by the user at different times. There are
certainly also disadvantages of this approach. But I suppose perhaps
there is a break-even point in practice such that in certain cases
it is better always to stick to one fixed algorithm for all times,
while in others it is preferable to exploit the benefits of
variabilities.
M. K. Shen
=============================
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Length of public key in PGP?
Date: Tue, 20 Jul 1999 11:10:36 -0500
No. The text should be delivered in appropriate sized pieces, and any
rearrangement thereof will result in garbage.
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
>
> > > Here is an example,
> > >
> > > P = 137 Q = 191 E = 3 D = 17227 PQ = 26167; If T = 332453243,
> > >then ciphertext = 24661, decryptedtext = 1508. *** Problem ***
> > >
> > > Have I done something wrong?
> >
> > T must be < PQ.
> >
> > Essentially, RSA is a block cipher, where the block size is the size
> > of the modulus. For longer messages, you must break up the message
> > into blocks and encyrpt them separately. In practice, we generally
> > make things simple by considering the block size to be slightly
> > shorter than modules, by one bit or rounded down to the next byte
> > boundary.
>
> Thanks. This makes sense.
> Does it help to break the ciphertext into pieces while decyphering, say,
> it might save some time in calculation or something?
>
> Weedlet
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 20 Jul 1999 12:23:40 -0600
In article <7n0a0t$6gj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> On 1999-07-18 [EMAIL PROTECTED](wtshaw) said:
> :As an information unit, 1 is not comparable to any other since in
> :log terms any other base to the power of one is zero, and I have
> :trouble dividing into or by zero myself.
>
> Surely you mean "any other base to the power of 0 is 1"?
> --
Yep, and I did post a correction that I include a wrong and extraneous
thought to the consideraton of base one.
As for computations like other bases, for base one there is no acceptable
concept other than zero and, possibly, infinity, which is in its own right
going to be difficult to use. You can't even write one in base one, which
makes it uncomputational, as I maintained before. The rules of
computational bases would in fact exclude base one and base zero.
Frankly, I find enough work in useful numerical concepts, and there are
plenty to keep us all busy.
--
When I talk about running the bases, it's not baseball.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: [Q] Finding K from P and C
Date: Tue, 20 Jul 1999 12:31:43 -0600
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
> Jim Gillogly wrote:
> >
> > Sungmin Chun wrote:
> > > E(P, K) = C
> > > where
> > > P : Plain text
> > > C : Cipher text
> > > K : Key
> > > E(P, K) : Encryption method
> > >
> > > Can we find K easily for well-known E(P,K)
> > > when P and C are given?
> >
> > It depends entirely on E.
>
> But for any "good" E, the answer is no.
>
And, *ease* is also relative to ones circumstances. Also consider that
for some ciphers, C may represent a set of diverse ciphertexts.
--
When I talk about running the bases, it's not baseball.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: (good) Calculator
Date: Tue, 20 Jul 1999 18:57:10 +0100
Try (for Windows Command prompt)
ftp://ftp.compapp.dcu.ie/pub/crypto/ratcalc.exe
Mike Scott
Vincent <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Does anyone know a soft running under Linux or Windows able to compute big
> number operations and to write the result either in decimal or in
> hexadecimal notation?
>
> Thank you.
>
>
------------------------------
From: "Vincent" <[EMAIL PROTECTED]>
Subject: (good) Calculator
Date: Tue, 20 Jul 1999 18:18:29 +0100
Does anyone know a soft running under Linux or Windows able to compute big
number operations and to write the result either in decimal or in
hexadecimal notation?
Thank you.
------------------------------
From: [EMAIL PROTECTED] (John Forrst)
Subject: Great New Cryptology Web Site
Date: 20 Jul 1999 17:27:00 GMT
Check out this new site -> <a
href="http://tracker.clicktrade.com/tracker/tracker.dll?to='http://smartsu
rfers.com/cars/'&ad=158216.1&lp=238842">www.crypttools.net</a>
John Forrst
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Crypt Dll for VB
Date: Tue, 20 Jul 1999 12:14:00 -0500
Anonymous wrote:
>
> check out the following. Up most evenings and 24 hrs on weekends.
> http://surf.to/hookah/code.html
In which time zone. The planet is kind of round.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Replacing IDEA with Blowfish
Date: Mon, 19 Jul 1999 17:31:20 -0400
[EMAIL PROTECTED] wrote:
> ...
> 3) There are designs for Blowfish in hardware, I dunno if they have
> been done yet or not. IDEA was designed for hardware and software
> (somewhat).
"somewhat" is right. IDEA uses multiplication, which is expensive
in hardware (or slow). Feistel networks such as in Blowfish are
far cheaper. Then again, in the case of Blowfish the large size
of the key schedule hurts.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Free chapters from Handbook of Applied Cryptography
Date: Mon, 19 Jul 1999 17:41:41 -0400
Alfred John Menezes wrote:
>
> As some of you may know, we recently made available 9 chapters
> from our "Handbook of Applied Cryptography" for free download from
> our web site: www.cacr.math.uwaterloo.ca/hac/
> ... Any
> comments in this regard are greatly appreciated.
Good move!
I downloaded some of those chapters when you first did that.
Much appreciated. Of course, it caused me to do serious
damage to my wallet by inducing me to buy the book itself...
:-)
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES permutations
Date: Mon, 19 Jul 1999 17:22:49 -0400
[EMAIL PROTECTED] wrote:
> ...
> But how does it make the wiring simpler? As far as I can see it only
> makes it more complicated.
I've been saying that too.
Bruce Scheier mentioned that it does help in multi-chip implementations.
I didn't realize any existed; the earliest I remember is a single
chip one from AMD. If you had to do DES in technology that
requires more than one chip, it seems plausible it would slightly
simplify the input demux (which, in that sort of technology, would
be a help).
paul
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Meta-Certificate Group moved site?
Date: Tue, 20 Jul 1999 12:23:15 -0500
Anonymous wrote:
>
> Does anyone have a URL for the MCG?
>
> They used to be at http://www.mcg.org.br/, but I've been getting an
> error for that site (the server does not have a DNS entry) for a few
> days. A web search for the MCG only gives references to this site. I
> can't mail Ed Gerck either:
>
> > 451 <[EMAIL PROTECTED]>... mcg.org.br: Name server timeout
> > Message could not be delivered for 5 days
>
> Have they moved somewhere?
>
> Cheers,
> -nick
>
> (PS. Forgive the anonymity, but my local newsfeed is on the blink)
I don't know. But I haven't seen any messages
from the list for several weeks. They might
be off the air, or they may have local power
troubles and will be back up soon. My bet is
they are off the air and won't be back.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Great New Cryptology Web Site
Date: Tue, 20 Jul 1999 17:51:21 GMT
[EMAIL PROTECTED] (John Forrst) wrote, in part:
>Check out this new site -> <a
>href="http://tracker.clicktrade.com/tracker/tracker.dll?to='http://smartsu
>rfers.com/cars/'&ad=158216.1&lp=238842">www.crypttools.net</a>
>John Forrst
You realize, of course, that if someone clicked on
"www.crypttools.net" in a newsreader that showed HTML posts in
web-page form, they'd be referred to a web site
(http://smartsurfers.com/cars/)
about _cars_, not cryptography?
And that they'd be referred there *from* a service
(http://tracker.clicktrade.com/tracker/tracker.dll)
that would log the arrival as if it were a click on a banner on your
web page?
Please don't spam our newsgroup again.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Michael Slass <[EMAIL PROTECTED]>
Subject: Re: Does base64 encoding lessen security?
Date: Tue, 20 Jul 1999 09:05:35 -0700
My original question arose from reading Schneier's book, and wondering how
secure DES3 will be for the forseeable future.
I was exploring the alternatives to DES3 for encryption of the stored RSA
key pair.
The openssl command line tool for rsa generation oputputs either
unencrypted base64, or DES or DES3 encrypted - then converted to base64.
Since the command line genrsa tool does not have a binary-output switch,
it's output is always base64. This is unsuitable for encryption as
discussed below. I finally just chained together a command line to do what
I wanted
generate an rsa key | convert from base64 to binary | encrypt with blowfish
It looks something like:
openssl genrsa 1024 | openssl rsa -inform PEM -outform DER | openssl bf -e
-a -k some_passphrase -out mykey.pem
I was really just wondering if it was really necessary to do the middle
step.
-Mike
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: SSLeay for HP-UX
Date: Tue, 20 Jul 1999 17:28:16 GMT
In sci.crypt, Eric Young ([EMAIL PROTECTED]) wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Has anyone successfully build the SSLeay shared library on HP-UX 10.x?
> If you are using the native C compiler, you need to have NO_PROTO and
> NO_CONST defined. It is a very primitive compiler.
> I believe openSSL will not compile with the native HP-UX cc anymore,
> they did not consider non-ANSI compilers worth supporting.
Depends what you mean by "the native C compiler"! Base HP-UX indeed has a
"very primitive" C compiler, just about good enough for a "hello world" and
a kernel rebuild (for which job it's really little more than a linker
front-end: no real kernel code gets *compiled* by it, just a bunch of
already-compiled library modules get sucked in, and the odd compile-time
expression is calculated).
The pay-for-it add-on C compiler, on the other hand, is a full ANSI C
implementation with extensive optimisations, and produces quite respectable
object code for SSLeay at the higher optimisation levels. (I seem to
rememember there's one module where the loop unrolling gets off into
silly land - it may be one of the basic block ciphers. It's a while since
I rebuilt from the pristine SSLeay sources). Nor do I recall having made
shared-lib (.sl) versions of libssl and libcrypto - for my applications
I preferred archive libs. If you're using only the "base" C compiler, I
don't think you can get there from here; if you're using the full add-on
product, a search through "man cc" and "man ld" should suggest the tweaks
you need in Makefile.ssl (and/or possibly its callees lower down the
source tree) should suggest the switches you'd need.
As well as asking here, you could try worse than the SSLeay/OpenSSL mailing
list(s)...
Cheers, Stefek
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Looking for RC4 alternative
Date: Tue, 20 Jul 1999 10:59:13 -0700
fungus wrote in message <[EMAIL PROTECTED]>...
>> From what I understand you CAN use RC4 in your program so long as you do
not
>> use the name RC4. It seems they have the name RC4 trademarked and the
>> algorithm uncopywrighted. At least that is my take on it.
>
>Correct, except you mean "unpatented" instead of "uncopywrighted"(sic).
>
>Don't worry about using RC4 if you don't use the name.
>
>Call it ARCFOUR instead.
Or use a disclaimer. You are allowed to reference another company's
trademark, as long as you do not confuse the customer about the
source. So you can say it is RC4-compatible. Just pick up any magazine
and look at ads to see how you can do this legally.
------------------------------
** 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
******************************
