Cryptography-Digest Digest #921, Volume #9 Wed, 21 Jul 99 18:13:03 EDT
Contents:
Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram) (John McDonald, Jr.)
Re: Free chapters from Handbook of Applied Cryptography (Jim Dunnett)
Re: NBE: Not crackable by brute force key search ([EMAIL PROTECTED])
Re: (good) calculator (Anonymous)
Re: Replacing IDEA with Blowfish ([EMAIL PROTECTED])
Re: Open questions about Dave Scotts Method ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (David Rifkind)
Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
([EMAIL PROTECTED])
Re: Xor Redundancies ([EMAIL PROTECTED])
Re: Algorithm or Protocol? ([EMAIL PROTECTED])
Re: Replacing IDEA with Blowfish ([EMAIL PROTECTED])
Re: Compression for encryption ([EMAIL PROTECTED])
*** Position Available - Security Assurance Specialist *** (Ezzy Dabbish)
Re: Xor Redundancies (JPeschel)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Cluelessness Alert? I'm Not So Sure. (latest Crypto-Gram)
Date: Wed, 21 Jul 1999 19:00:13 GMT
On Wed, 21 Jul 1999 11:31:20 GMT, [EMAIL PROTECTED] (Roger Fleming)
wrote:
<snip>
>It was also suggested that your firewall could allow nothing but port 80 to
>reach the webserver, and therefore "there is no risk of someone altering
>content on your web-server". Hmm. Pretty well any decent webserver these days has
>CGI on it, which means that a simple HTTP GET request can actually be a command
>to execute a program on your webserver, with parameters chosen by the attacker.
>Oops. Suddenly IP filtering isn't quite so obviously foolproof.
You make a good point, but with a BIG problem... CGI requires that the
programs are on the web machine. (Or off of a link that can be
followed from the server.) As a webmaster, I am not going to simply
allow Joe User to execute just anything! I'm certainly not going to
let him access rm, or other useful commands.
Furthermore, the CGI has to be in a directory that is 'see'able by the
webserver. Usually, this works out to be /home/http/cgi-bin/ on
linux, or another directory, but NEVER /.
The webserver does not allow you to backtrack beyond the scope of its
directories, if it is properly configured.
With that in mind, it takes an idiot to set up the webserver such that
unwanted executables can be called by someone connected through the
browser. The most widely used server, apache, even allows you (forces
you) to specify *exactly* which directories the server is allowed to
execute CGI from.
Furthermore, a user does not execute these by using an HTTP GET. They
simply place the command right on the location bar with the
appropriate tags. For instance,
www.yahoo.com/cgi-bin/search.cgi?search=yer+mom+in+yer+home
(Note that this is only an example.)
The reason there is a distinction is because a GET is what the server
sends out and expects back, but if you watch your location when
executing CGI, you will find that you do not need to actually view the
preceding pages. (This is how askjeeves.com and other Super-search
engines search other Search engines. Confused? Good. <g>)
Once again, IP masquerading is foolproof... (As close as you get..)
Incidentally, as far as validation of update content goes, this is not
an especially difficult task, if you are using a *nix platform.
[-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-]
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
please remove -delete- for responses.
--
"I speak for me and not this company"
TO SPAMMERS:
Please view the definitions for
"telephone facsimile machine,"
"unsolicted advertisement," and the
prohibition and penalty for sending
unsolicited faxes before sending Un-
solicited Commercial E-mail to the
above address. Violators WILL BE
PROSECUTED. These can be found
in:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
[=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=]
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Free chapters from Handbook of Applied Cryptography
Date: Wed, 21 Jul 1999 19:24:18 GMT
Reply-To: Jim Dunnett
On Mon, 19 Jul 1999 17:41:41 -0400, Paul Koning <[EMAIL PROTECTED]> wrote:
>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...
We can borrow it from a public library over here. :o)
--
Regards, Jim. | Inside-Out Edinburgh
amadeus%netcomuk.co.uk | Guide to all aspects of
dynastic%cwcom.net | The Capital's Life:
nordland%lineone.net |
PGP Key: pgpkeys.mit.edu:11371 | http://www.insideout.co.uk/ed
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NBE: Not crackable by brute force key search
Date: Wed, 21 Jul 1999 20:40:16 GMT
In article <7n06k9$99f$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> > Your a loon. ...
> > I would encourage you to answer the questions in a
> > professional manner...
>
> You tell him!!!
Well my beef is that he boasts how good his algorithm is, but he has no
good descriptions of it (well short documentation but)... no analysis,
no good code...He just boast 'my algorithm stumps the NSA' but he
forgets to mention 'it's not fast, small or compact' or 'I have never
tried to break it so I don't know how strong it is anyways, it just
looks tough' or 'I don't know what the size/round ratio is' or...
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: Anonymous <Use-Author-Address-Header@[127.1]>
Date: 21 Jul 1999 21:44:58 -0000
Subject: Re: (good) calculator
This should give you a few choices
http://www.maths.uq.oz.au/~krm/N1.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Replacing IDEA with Blowfish
Date: Wed, 21 Jul 1999 20:48:05 GMT
In article <7n3jtt$2s20$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> NO you lack the basic understanding of how things work.
> the input to the S table is 16bits not 32bits the table entries
> are made from the constant part which comes from the key
> or have you ever bother to actually look at IDEA.
This is 256KB per round or 2MB of ram. It would also require 8*4*65536
or 2^21 multiplies to get the table setup (although you could replace
the multiply with an add and perform the modulo I think).
> Like I said before you need only a sigle 16X16 bit table for
> each of the mutilplys but if you have not done much programming
> it is understandable of your large lack of knowledge so don't
> feel to stpuid.
Seems to me you haven't done much programming. 2MB LUTs are only
reasonable on desktop 32-bit computers which are single user. If you
have 1000 users (network server) this woul be 2000MB of ram (instead of
101.5KB). What about smartcards or smaller computers (286 for
example). Seems to me your are a little closed minded.
You are corrected that you only need the LUT's for the multiplies you
perform (all 32 of em) but the setup time would kill key agility and
server performance. If you are sending 1GB on a single user machine
then go ahead... but for small messages it's not faster.
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: [EMAIL PROTECTED]
Subject: Re: Open questions about Dave Scotts Method
Date: Wed, 21 Jul 1999 21:05:53 GMT
In article <7mual8$o8u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Joe I am not sure you have noticed but little Tommy likes to use big
> words but never anwsers any questions himself. I long ago give up on
> the kid he is hopeless. He does not have the patience or the brains
to solve
> the scott16u puzzle. We once had a very long exchange where he seemed
> incapable of learning anything and said he was done talking to me. I
don't
> mind anwsering questions for those that truely want to learn but our
little
> boy Tommy does not want to learn.
> Maybe the NSA could give the solution to him so he could collect the
> money. No I don't think they could have solvied it. But they may have
planted
> some trojan program in my PC to find out what I have done.
Maybe tommy has some questions little davy can't answer? I can
question aspects of many ciphers but that doesn't mean I can break it.
Well Dave since you throughly inspected your code answer the questions
1. For a block size of m/n (n = word size, m = msg size both in bits)
what is the minimum required rounds for SAC and reasonable resistance
to iterative attacks? This would not be a single answer and possibly
not a single equation. It would be different for n=19 and n=16 I
believe.
2. What is the smallest secure value of n?
3. What is the actual key space? Is S[x] = y and S[y] = x allowed?
In this case the table would not be a single long cycle... Are their
bad keys?
Seems to me these are important questions...? I would love to have
David Wagner or Bruce S, back me here. They know way more then me but
could possibly help the line of questioning a bit (or Vincent or ...)
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: [EMAIL PROTECTED] (David Rifkind)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Wed, 21 Jul 1999 21:23:12 GMT
On 21 Jul 1999 20:00:03 GMT, [EMAIL PROTECTED] (Finder Keeper) wrote:
>But zero isn't the first number. It's the zero-th number.
No, zero is the first cardinal number. One is the second cardinal
number, but the first ordinal number. Zero isn't an ordinal.
--
"Generally speaking, things have gone about as far as they can possibly
go when things have got about as bad as they reasonably get."
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
Date: Wed, 21 Jul 1999 20:57:31 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> In typical Lempel-Ziv compressors, the first few bytes are expanded to
> nine bits, with an extra bit indicating they're literal instead of
> pointers to the table of previous strings.
Well this is not exactly true. You are describing LZSS which uses a
marker to distinguis between a <distance, length> pair and a literal.
However their is nothing saying you can't just assign length's of zero
to literals (which I did in my LZSS-0) coder. My point is that the
first bit of text (or the block/message) is not compressed well at
all. It's worse for messages that do not compress well (full range
audio for example).
> Also, since adaptive compression methods do more poorly in the first
part
> of the text, perhaps bisection - keyed bisection, since one can't
> reconstruct by eye the way it is possible in paper-and-pencil
operation -
> or a transposition cipher ought to be the first encryption step after
> using that form of compression.
Well genereally you don't get the whole message at once. So bisection
is only good for block modes. I would prefer to keep streamed data in
sequenctial order.
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: [EMAIL PROTECTED]
Subject: Re: Xor Redundancies
Date: Wed, 21 Jul 1999 21:13:50 GMT
In article <7mub4h$o8u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> Joe it is kind of hard to expose a product when they charge real
money
> for the product. I for one don't see any reason to spend money on a
product
> and then expose it. For one thing besides the money issue. Who would
> belive me. THe unclean masses wouldn't have a mathematical background
> to know that it was exposed. The fact is a real company could spend
money
> in some polished PR ad and the masses would belive them and not the
> obvious truth that was poorly written by me. In crypto being right
means
> little to being rich.
The problem is not always money. A lot of times they just don't know
better and they tack 'security' on as a feature. The problem isn't
patented algorithms because DES is somewhat secure (well not now cuz of
brute force) and is free to use. A lot of times they get lazy or don't
really think things thru. It's not hard to add a encryption algorithm
to a program, it's harder to use it properly though...
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: [EMAIL PROTECTED]
Subject: Re: Algorithm or Protocol?
Date: Wed, 21 Jul 1999 20:37:40 GMT
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> Different people use the terms "algorithm" and "protocol" in different
> ways, so there can be arguments about their definitions. They are
> similar in that both refer to a well-defined sequence of steps. From
> what I've seen, the big difference is that a "protocol" explicitly
> involves more than one party. For example, there are communications
> protocols like IP and TCP. Diplomatic protocols describe how people
> should interact, such as how an "ambassador" should speak to a "king".
I don't see 'Algorithm' and 'Protocol' as interchangeable.
M^e mod N is a algorithm (or expression), whereas give g^x mod p, take
g^y mod p, compute g^xy mod p is a protocol (each step is an
expression).
Algorithms generally are attacked differently then protocols. You
attack RSA for example by factoring or bad padding. You attack DH by
man-in-the-middle attacks etc, etc... (although mitm can work against
most protocols that use RSA).
> I suppose that, strictly speaking, any "protocol" that is well defined
> is also an "algorithm". Thus, for example, we speak of the "Diffie
> Hellman key exchange algorithm". Still, most of the time I see
> "algorithm" it means a single party computation, so that protocols
> use algorithms as components.
DH is more of a protocol then an algorithm. I think anything requiring
second/third/etc party interaction is a protocol. RSA for example has
three or four steps (?) but I still think of it as an algorithm.
> (And of course, on top of "protocols" we have "systems"...)
Hiearchy, hmm ok!
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: [EMAIL PROTECTED]
Subject: Re: Replacing IDEA with Blowfish
Date: Wed, 21 Jul 1999 20:42:41 GMT
In article <7n2stc$220u$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> actaully since IDEA use multiplicatiopn of a variable times a
constant
> each one of those could be repacled by a small 16X16 bit S table.
> which is not so expensive. Also one could could improve IDEA by
> usinging a larger class of functions instead of a lowly multiply which
> may make it more vulnerable to being broken.
Then it requires too much ram and you get zero key agility. What if
you only encode 1000 bytes? Why preprocess the time for 1000000 blocks?
Tables >1024 bytes only make sense if they are limited (say under
128KB) and can be stored (i.e loaded at run time). If the tables are
too big they will not be usable in general.
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: [EMAIL PROTECTED]
Subject: Re: Compression for encryption
Date: Wed, 21 Jul 1999 20:51:34 GMT
In article <7n3k4c$2s20$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> I presently have an adapative huffman compress that is suitable for
> encryption. Will soon have a BWT type of compress that may be
> better. So keep an eye out for it. Will add others if I get feedback.
To me putting compression and encryption in the same field is
irresponsible. They go hand in hand for communications in that you
first compress then encrypt but compression methods rarely hide
information well. Most good methods are adaptive (and for comm links
they would have to be) in this sense the dictionary is built from the
stream.
Moral: Compression predicts stuff but is reconstructable. Encryption
requires a private key to restore gibbly gook to plaintext. They are
not the same.
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: Ezzy Dabbish <[EMAIL PROTECTED]>
Subject: *** Position Available - Security Assurance Specialist ***
Date: Wed, 21 Jul 1999 15:45:31 -0500
%%%%%%%%%%%%%% Job Listing Starts Here %%%%%%%%%%%%%%%%
*** Position Available - Security Assurance Specialist ***
Motorola Laboratories in Schaumburg,
Illinois, is seeking an individual to participate in the specification,
design, and development of secure communication systems.
Responsibilities: Perform design, analysis, simulation and
prototyping of secure circuits and communication systems.
Develop and implement secure communication protocols. Participate
in the design and development process in key areas such as:
Smart Card Systems Security, Electronic Commerce, Internet Security,
Secure email, Secure Multimedia Communications..etc.
Requirements: BSEE or BSCE or BSCS or equivalent is required;
an MS or PhD degree is a plus. Educational background must provide
a strong foundation in engineering, advanced math and computer
courses. A minimum of two years experience in some of the following
areas
is required: Vulnerability assessment of secure products and systems,
security assurance methodology, Public Key Crypto Systems,
Elliptic Curve Cryptography, circuit design, system design,
computer simulation, security protocol development.
Applicant should be interested in secure system design and development.
This includes dealing with system level design issues as well as small
details of the design process. Knowledge of c or c++, assembly
language,
and JAVA programming is preferred.
Security Clearance might be required.
The search will continue until the position is filled, but first
consideration will be given to resumes received by September 15, 1999.
The reference number for this position, SCI10278, should be included in
any correspondence. Please send resume and cover letter to:
Ezzy Dabbish
Motorola, Inc.
IL02/2712
1303 E. Algonquin Road
Schaumburg, IL 60196
email to: [EMAIL PROTECTED]
Fax: (847) 576-8378
Motorola is an equal opportunity/affirmative action employer. We
welcome and encourage diversity in our workforce.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Xor Redundancies
Date: 21 Jul 1999 22:09:18 GMT
>[EMAIL PROTECTED] writes:
>The problem is not always money. A lot of times they just don't know
>better and they tack 'security' on as a feature. The problem isn't
>patented algorithms because DES is somewhat secure (well not now cuz of
>brute force) and is free to use. A lot of times they get lazy or don't
>really think things thru. It's not hard to add a encryption algorithm
>to a program, it's harder to use it properly though...
You're right sometimes the problem isn't money, but often a vendor's rush
to make it results in an easily broken proprietary cipher or a wrongly
implemented strong cipher. What angers me is a vendor who promises
"unbreakbility," or at least a strong cipher, yet knows he can break
the encryption.
It's also true, as you say, that vendors tack on "security" as an
extra in some programs: MS Word, PKZIP, etc. The utilities I
was thinking about are "encryption" utlilities: Turbo Encryto, UBE98,
FileLocker, Crypt-o-Text, and others.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
** 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
******************************
