Cryptography-Digest Digest #551, Volume #11 Sat, 15 Apr 00 06:13:01 EDT
Contents:
Re: OAP-L3: Answer me these? ("Bo Johnson")
Re: $100 Code Challenge ("Jeff Hamilton")
Re: Open Public Key (Chem-R-Us)
Re: from table to function (Terry Ritter)
Re: DES Trapdoor Claims (Jack Diamond)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Q: Entropy (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Is AES necessary? (Mok-Kong Shen)
Re: Q: NTRU's encryption algorithm (Mok-Kong Shen)
PGP for Linux as secure as Windows? ("none")
Re: ? Backdoor in Microsoft web server ? (Mok-Kong Shen)
Re: CLOSE Encryption (Mok-Kong Shen)
Re: Miami Herald article about ATM ripoffs ("Mark McCarthy")
----------------------------------------------------------------------------
From: "Bo Johnson" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 15 Apr 2000 00:46:28 -0400
A.S. Wrote:
>I am glad to say that lots of people from the US and Canada have
>gotten the OAP-L3 software, and now many people from all over the
>world have gotten the OAR-L3 software, too.
>
>They just emailed me or pointed and clicked. Didn't bitch once
>about the web site. Just made a decision and got the software.
>It's all very simple and straight forward. It's easy when you
>know what you want.
"Nobody ever went broke by under-estimating the intelligence of the average
American." - Eddy The Snake
"Just because snake oil sells doesn't prove it cures cancer." - The Surgeon
General
Taneli issued you a challenge that he could prove a weakness in your
generator if you would post the data he requested. The fact that you backed
down from the challenge strongly suggests to this here novice that you're
just plain yaller. (That means a coward for you yankees out there.)
I don't know shit about crypto, but from reading your responses I'm pretty
sure you don't have the balls to post your algorithms, properly document
your theory, provide sample data or do any of the work that it would take to
get the brilliant people on this forum to be impressed by your cipher.
The number of hits on your website or the fact that Joe Schmoe buys your
software without asking any questions and hasn't complained doesn't prove
anything other than the fact that Joe Schmoe wants to buy some crypto and
believes your claims because he is too lazy or uneducated (like me) to
analyze the info on your help files.
The funny thing about weak crypto is that you can use if for years without
knowing it's weak. And your enemies could be intercepting and cracking it
for years without you knowing it. So just because none of your buyers has
complained yet doesn't prove it's strong. It only proves that they have
been lulled into a false sense of security by purchasing a product that
makes unsupported claims.
Bring in the cavalry. If all these people are downloading and analyzing
your software, ask one of them to post on this forum how great it is and
invulnerable to attack and how they can possibly know so. If you can show
uneducated me that somebody with a brain has analyzed your algorithms and
proved that they are strong in theory and in practice, then I might buy it.
As it is you are just bragging and insisting that we trust you that it's
secure because you said so.
The builders of the Titanic thought it was invulnerable to any known attack.
Their theory was strong. History showed them wrong.
If you are a good business man you will take the time to prove to your
critics on this forum that your cipher is strong by providing them with the
documentation they are asking for. If you don't, word will eventually get
out and nobody who knows anything about crypto will buy your shit.
------------------------------
From: "Jeff Hamilton" <[EMAIL PROTECTED]>
Subject: Re: $100 Code Challenge
Date: Fri, 14 Apr 2000 22:12:21 -0700
You know, it's people like you who have no clue how to even begin
Cryptanalysis. You know, why don't you try to do something other than make
stupid comments. I think his challenge is valid. Just as mine was. In fact
I'm suprised you didn't knock my challenge.
-Jeff
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> [EMAIL PROTECTED] wrote:
> >
> > The following is a message encoded using a new routine I have designed.
> > The text is a written message in English. In order to test just how
> > strong the encryption is, I have posted it here for anyone interested
> > to try to crack it. The first person to successfully crack it will get
> > $100. Seriously, $100, no kidding. Instructions for contacting me are
> > included in the encrypted text. If the code is not broken by June 31,
> > 2000, then the contest is over. If the code is broken, I will post that
> > news here so you won't waste your time for nothing. Also note, the
> > winner will be required to explain how the code was broken as well as
> > provide exact text of encoded message. Good luck.
>
> The correct solution of course being "I should have posted the source to
> my algorithm so people could pick and poke in awe at my amazing math
> ability, instead I posted random garbage as ciphertext and expect
> people to treat me with a tad of intelligence."
>
> Did I win?
>
> Tom
>
------------------------------
From: Chem-R-Us <[EMAIL PROTECTED]>
Subject: Re: Open Public Key
Date: Fri, 14 Apr 2000 23:42:32 -0700
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > ElGammal or ECC are the certain winners in this case. Although
> ElGammal
> > is slightly easier to implement and understand.
> >
> > Tom
> >
>
> How secure are ElGammal and ECC??
> Where can I find more information about ElGammal or ECC?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Applied Cryptography, 2nd edition explains ElGamal in terms that can be
put to immediate use.
For a more throeretical explanation see the Hanbook of Applied
Cryptography by Menezes, van Orschot and Vanstone.
They should be more than helpful in helping you to apply the ElGamal key
exchange protocol.
--
Chem-R-Us
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: from table to function
Date: Sat, 15 Apr 2000 06:44:48 GMT
On Fri, 14 Apr 2000 11:51:34 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
<[EMAIL PROTECTED]> wrote:
>[...]
>S-boxes aren't permutations. They are non-linear functions. The
>serpent design probably started from a set of functions and created
>the S-box tables from that. Knowing the functions allowed them to
>create the list of algebraic instructions trivially, but going
>backwards from the S-boxes would be almost impossible.
S-boxes almost always *are* permutations, else they would have biases
for particular values (and against other values) which might be used
in attack.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Jack Diamond <[EMAIL PROTECTED]>
Subject: Re: DES Trapdoor Claims
Date: Sat, 15 Apr 2000 07:15:03 GMT
Sorry. I thought this was generally known in the community. It was a
mistake to have posted on that subject.
Jack
[EMAIL PROTECTED] wrote:
>
> At least two posters here have stated in this forum that DES has trap
> doors...including Jack Diamond..
>
> Jack...I repeatedley asked you in private email, and also publicly in
> this forum that since you claim that DES has a trap door, you should
> come out and make your statement in full but you have refused to do that
> publicly or privately. I believe also others have responded to your
> message in this forum but you have refused to substantiate your claim.
>
> In the interest of Privacy for Joe Public and in the spirit of those who
> fought hard for the liberlisation of crypto and privacy laws
> (Diffe Hellman/Zimmerman)...your position goes against the grain..If you
> know something as you claim you do..Publish it here..as I told you in my
> email...
>
> As you know DES has been studied more then any other cipher by top
> crypto experts...
>
> Your implication of a trap door..suggest that you are thinking either
> about the Modification of the original IBM S-Box design (according to
> Alan Konheim of IBM)....or more ominously....there could be some really
> clever trap door in the Feistal Design which by some clever and not
> known or published algorithm reverses or traverses the Feistal network
> to yield the key...If that is the case , heavens help us, because most
> of the modern ciphers are based on the original Feistal Network
> design...
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sat, 15 Apr 2000 10:37:02 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen wrote:
> > If you could give a rigorous proof that two particular modern
> > ciphers are equally strong, that would be a significant scientific
> > result and certainly worthy of a journal publication.
>
> Well I base this asumption on the "fact" that people have analyzed both
> DES and RC5 with the same analytical methods. True it's possible to
> find a new differential on either and break it "faster". I doubt that's
> likely.
If you couldn't break a piece of stone and a piece of steel, you
are yet far from knowing which one is stronger.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Sat, 15 Apr 2000 10:36:51 +0200
Bryan Olson wrote:
>
> Here the input y is written as a program for M_i. Absent
> reference to the specific machine, the definition does not
> define which of two strings has greater complexity. In fact
> for _any_ two finite strings x and x', there are two
> machines M_i and M_j such that
>
> K_i(x) < K_i(x') and K_j(x) > K_j(x').
>
> Kolmogorov complexity also defines a language-independent
> metric. It defines complexity to within some additive
> constant, so it does not describe individual finite strings.
Do I correctly understand that means that the concrete metrics
differ from one another by 'constants'? If that is indeed the
case, then I think the matter would be simple: For two strings
s1 and s2, if we have in one metric K1 and K2, then we would have
in the other K1+C and K2+C and comparision of complexity would be
unambiguious. Is that right?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sat, 15 Apr 2000 10:37:07 +0200
Paul Koning wrote:
> >
> > Variation can take different forms/degrees. Do you think 3DES
> > is a variant? If you think 3DES is o.k., would you object to
> > 5DES (putting aside the speed issue)? How about using variable
> > keys for different blocks? Note that all these don't 'manipulate'
> > the module DES as such.
>
> Right, and not all of those have security benefits.
>
> For example, using different keys for different blocks -- I assume
> that means using a small number of keys in rotation. That is
> a very weak way to use additional key bits. For N keys, it
> increases the work by a factor of N. Why bother?
You could use another DES as a random number generator to supply
the keys for the DES that does the proper encryption.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Sat, 15 Apr 2000 10:36:57 +0200
wtshaw wrote:
>
> While some do repeat the montra that anything can be solved given enough
> time, there may not be sufficient time, sufficient ciphertext, or
> sufficient insight to get a solution. There exist countless varieties of
> cryptographic algorithms, many that use cryptography with good security
> practices, and endless ways to deceive a probable attacker.
>
> Whenever someone speaks with derision about existing algorithms and the
> security they can assist in providing, it is obvious to me that they are
> trying to mislead about the value of encryption, or know too little about
> the subject themselves. Their greatest fear might be that adequate
> information about how best to do things becomes readibly available. There
> is nothing complex to that knowledge.
What you said should be reflected upon simultaneously with the
(strong) suggestion that people should use one single standard
algorithm and forget all the rest. (I recall that recently Terry
Ritter has had a very tough time defending multiple encryptions.)
As far as I am aware, the great fear of public availability of
crypto knowledge most clearly manifested itself for the first time
(in modern history) in an issue decades ago about censorship
(desired by the bureaucrats) of journal publication of crypto
articles (cf. posts some time back in this group). The goals of
crypto laws and Wassenaar crypto clauses are not only being
approached via pathways delineated in black and white but also
through methodologies much more ingenious and subtle and operating
almost at the sub-conscious level.
> Just for the record ,folks, I *play* with all range of algorithms, in
> reference to their security, because the most important principles are
> worth studying in a somewhat simplified form.
Like in all scientific disciplines, I believe it is advantageous
to study the stuffs that currently exist and then to extract the
fundamental ideas from them and combine that with one's fancies
(if available) and generalize these into something abstract but
powerful and finally derive from it novel concrete constructs.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: NTRU's encryption algorithm
Date: Sat, 15 Apr 2000 10:41:13 +0200
Mike Rosing wrote:
>
> > Is the comparison with RSA on the web page of NTRU fair?
>
> Kind of. The math is definitly faster. I don't think anyone is
> really sure about the security yet.
Do you happen to have literature references useful for studying
the mathematics involved (not necessarily NTRU's algorithm as
such)? Thanks.
M. K. Shen
------------------------------
Reply-To: "none" <[EMAIL PROTECTED]>
From: "none" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP for Linux as secure as Windows?
Date: Sat, 15 Apr 2000 08:58:14 GMT
Dear all,
The 5.x.x and 6.x.x versions of PGP all came under attack when they were
first issued because there was a belief (which in some cases was proved to
be justified) that the program was "leaking" data to Swap files or else
failing to over-write data on the hard disk.
I have never seen any comments on the Linux version, however. Does the
command line -w option actually over-write files (and if so does it work on
all types of file systems?), or is it merely the same as removing a file
normally?
Do the memory protection features work under linux?
Clearly, the secure viewer does not have the fonts needed to attempt to
emulate the Windows Secure viewer option, but is there any protection
against the data going into a Swap file?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: ? Backdoor in Microsoft web server ?
Date: Sat, 15 Apr 2000 11:06:45 +0200
Francois Grieu wrote:
>
> Disclaimer: I have NOT verified this story, which may be bogus.
>
> According to <http://cbs.marketwatch.com>, citing The Wall Street
> Journal, Microsoft has acknowledged the existence of a "backdoor" in one
> of it's consumer web server software. Knowledge of a global password
> would grant [?read-all?] privileges on thousands of deployed web servers.
I remember that a couple of months back there was an article in
the Computerzeitung claiming the existence of backdoors in
software of Microsoft and a few other manufacturers, albeit
without supporting details. From the fact backdoor was embedded
in the original UNIX code (cf. ACM award lecture) without being
detected, it shouldn't surprise that software not written by
oneself may have backdoors.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CLOSE Encryption
Date: Sat, 15 Apr 2000 11:10:39 +0200
MeneLaus wrote:
>
> CLOSE is a new algorithm written by Chaos Legion,
>
> If you are a cryptoanalyzer then come visit our site and evaluate it
> for us. If you spot any weaknesses then post them on the CL Web Board
> not here.
Wouldn't it be a good idea that you post a good abstract (essence)
of your algorithm to the group instead of asking people to
read your web page?
M. K. Shen
------------------------------
From: "Mark McCarthy" <[EMAIL PROTECTED]>
Subject: Re: Miami Herald article about ATM ripoffs
Date: Sat, 15 Apr 2000 11:45:01 +0200
Just wanted to clear up some confusion here on how plastic card PINs work
(cos nobody else seems to know!).
A plastic card (be it a debit, credit or charge card) has a magnetic stripe
on the back. That magnetic stripe contains three tracks, referred to as
(funny enough) track I, track II and track III.
The second track is the important one with regards to authentication. It
contains the card number, expiry date, service code, PVV, CVV and optionally
some user-defined fields (by user, I mean the card issuer).
This format is defined by (at least) an ISO standard. And yes, there are
variations on this theme, but this is the general idea.
The PVV is the PIN Verification Value. This is a standard devised by Visa
International. There are other types/formats for PINs, but we'll use this
one as an example.
It's built around DES, and it's probably fair to say it looks something like
a hybrid between what's now known as double and triple DES.
I don't know how much of this is proprietary so I won't go too deep.
The customer PIN is either selected by the customer, or "randomly" assigned
by software (accompanied by a PIN mailer to the customer).
Essentially, it's a combination of DES encrypts and decrypts with
information contained within track II, the clear PIN and two DES keys, and
this outputs a 64 bit block. The 16 hexadecimal digits in the result block
are scanned firstly for four decimal digits. The first four found represent
the PVV. If four decimal digits are not found, a second scan of the result
block takes place, this time subtracting 10 from each alpha digit (A - F).
The resulting PVV is optionally stored on a database (facilitating PIN
retention for the next card issued after the current one expires). The PVV
is always stored on track II also. Someone earlier in this thread suggested
that storing this info on track II is some kind of relic to when ATM's
verified PINs. At least with PVV, this is certainly not the case.
Because the PVV is on the back of the card, it allows other parties to
verify card PINs for the card issuer. AN example is when credit card
companies see a transaction, and verify the PIN before allowing it to travel
through the network, back to the card authoriser. This cuts down on network
traffic.
To allow this to happen, card issuers send their PIN Verification Keys
(PVKs) to the credit card companies, and the keys themselves are enrypted
under a transport key.
I'm able to elaborate on this if it's both interesting, and I won't go to
jail for doing so!
Mark McCarthy.
Lincoln Yeoh wrote in message <[EMAIL PROTECTED]>...
>On 11 Apr 2000 01:10:12 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>
>>I suspect he meant algorithm. (just a rearrangement of the first four
>>letters). But even that is wrong. It contains an offset to get from teh
>>natural PIN created by encrypting various things like the account number
>>by DES with a secret key to the true pin. (See Ross Anderson's
>>explanation many years ago here.)
>
>But isn't that an insecure way to do things?
>
>The card should hold a card number and the PIN should be random.
>
>The ATM should use the card number to check the PIN with the nearest
>database (replicated).
>
>To increase detection of duplicated cards, the ATM could write to the card
>a sequence number after each transaction. But this makes things more
>failure prone.
>
>Cheerio,
>
>Link.
>****************************
>Reply to: @Spam to
>lyeoh at @[EMAIL PROTECTED]
>pop.jaring.my @
>*******************************
------------------------------
** 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
******************************
