Cryptography-Digest Digest #12, Volume #10 Sat, 7 Aug 99 15:13:05 EDT
Contents:
Re: Infallible authentication scheme (Eric Lee Green)
Re: Software License Generation - Assistance Requested (Eric Lee Green)
Re: beginner question re. MD5 and one-way hashes (Eric Lee Green)
Re: challenges / competitions??? (Tim Redburn)
GETTING RID OF THE "scottNu" cookie (SCOTT19U.ZIP_GUY)
Re: Americans abroad/Encryption rules? (JPeschel)
Download virtually unbreakable encryption programme (Wincrypt IDEA) ("Terry Mechan")
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big (Thomas
Pornin)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
(Thomas Pornin)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: What is "the best" file cryptography program out there? (KidMo84)
Re: What is "the best" file cryptography program out there? (Keith A Monahan)
Re: Construction of permutation matrix (wtshaw)
Re: key lengths (wtshaw)
Re: What is "the best" file cryptography program out there? (wtshaw)
Re: What is "the best" file cryptography program out there? (Keith A Monahan)
Re: Americans abroad/Encryption rules? (wtshaw)
Re: Is breaking RSA NP-Complete ? ("rosi")
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Infallible authentication scheme
Date: Sat, 07 Aug 1999 08:24:55 -0700
Michelle Davis wrote:
> Of course, you're right. But since the security requirements of the
> scheme are extreme, there is the possibility that someone will try to
> utilise known elements in the string to be hashed (in your example,
> A||R||I) to facilitate a dictionary attack (a dictionary attack tasked
> at getting back to the hash input from the MD, and discovering your
> secret key A).
Err, if you are using a plain text password as your sole source of
entropy, you are of course correct -- there isn't enough entropy to
produce a strong hash resistant to dictionary attacks. That's why you
should not use a plain text password as your sole source of entropy. See
http://www.counterpane.com for more info on that. Use a key generated
by a strong (high entropy) key generation mechanism. The hard part then
becomes the authentication key distribution mechanism and protecting
that mechanism against hackers (grin). Different topic, far harder than
this one...
I'm assuming that SHA1 has similar characteristics, except maybe being
faster than MD5 (?).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Software License Generation - Assistance Requested
Date: Sat, 07 Aug 1999 09:23:45 -0700
"Douglas A. Gwyn" wrote:
> "Kirk E. Lieb" wrote:
> > I am developing a WinNT sw product which requires a one-time licensing
> > scheme, and I am looking for assistance in understanding existing
> > products or libraries that would be useful.
>
> FLEXlm is widely used on UNIX systems. I don't know whether a Windows/NT
> version is available, but I would imagine so. One nice thing is that
> the license server can be accessed via the network, so multiple users
> can share the license(s). FLEXlm has a Web site somewhere, try a Web
> search to find it.
There are a number of possibilities here, actually. One possibility, for
example, is to use a message digest to authenticate the license
information. There is presumably a shared secret that both the program
and the original issuing authority possess. The key that you type in
from the paper issued by the licensing authority then would be the
message digest or some portion thereof. At run time various other
licensing info (user name, feature codes, serial number, etc.) is then
hashed with the shared secret to produce a message digest. The message
digest that you typed in is compared with the computed one, and if okay,
you typed in a valid license key. If not, sorry. The problem here is
that then a detirmined hacker can buy a single copy of your program,
disassemble it, and pick your shared secret and algorithm out of there,
no matter how hard you try to obfuscate the license checking portion of
your program. Then he can generate all the licenses that he wants for
your product. Still, this appears to be the scheme used by most of the
programs I've examined. Given that any hacker detirmined to defeat it
could simply patch your binary to bypass the license check in the first
place, it's not too terrible. At least it will keep the basically honest
people honest.
Another possibility is public key encryption. The public key is known,
and crackers having access to that public key is not a problem, they
cannot generate license files using it. The private key could be used
to, for example, encrypt the MD5 hash of the license file, then the
license key is the actual encrypted MD5 hash (in printable/user
enterable form). This key is rather lengthy by comparison with comparing
the first portions of encrypted MD5 hashes, but avoids having the
private key used to create licenses exposed to the outside world. This
is typically what is used to sign EMAIL via PGP, but works just as well
for signing licensing information. But: It's long. And while it avoids
the possibility of people generating licenses for your product, anybody
who could reverse-engineer your product in order to do that could simply
patch the binary to remove the license key checking portion of your
product in the first place. Back in my younger days, when people tried
to put copy protection into programs, we pretty much proved that any
possible copy protection scheme could be broken via enough application
of a binary-level debugger. Even schemes that encrypted portions of the
binary were easily breakable, because some part of the program had to
decrypt that. Substitute "license key checking" for "copy protection"
and you get the picture.
Then you get to the key server approach, which basically is keeping
these license files in a central place rather than on the disk. But the
actual license info authentication is still done as above.
An interesting thing, now that almost everybody is hooked to the
Internet, would be to use a third party certificate agent such as Thawte
in order to use public key encryption in order to directly exchange
licensing information between the issuing authority and the individual
application at licensing time. This avoids the biggest problem of the
public key encryption approach (the length of the license key
signature). But this is most probably not a viable thing to do yet from
a social point of view, because people do not want their applications to
be at the mercy of their Internet connection.
I'd appreciate any comments from "real" cryptographers here, since I
first started investigating this whole area two weeks ago and thus am
very much a "newbie" (grin).
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: beginner question re. MD5 and one-way hashes
Date: Sat, 07 Aug 1999 09:35:24 -0700
Muharem Hrnjadovic wrote:
> I need a one-way function in order to generate hash key values
> for a piece of software that is caching objects i.e. when I come
> across an object the second time the function should generate the
> same hash key so I know that I have seen that object already.
Sounds like you need a screwdriver and you're trying to use a hammer.
In general, unique identifiers should be assigned to objects at creation
time, and all references to that object should include its unique
identifier. If you have a central depository, the storage identifier is
an easy unique identifier (the storage identifier being, e.g., its
position in an array of objects, or the actual physical address in
memory, or its location on disk, or simply the fact that it was the
1,000,001st object created), and can be returned to the routine that
originally interred the object so that the object can be referred to by
its proper name in the future.
I suggest reading Knuth if you're trying to do something other than what
I think with this, such as hash names in order to create a hash table
for, e.g., a compiler. Bucket overflows will be the big problem here,
and can be resolved in a number of ways, but some portion of the
contents (such as a unique object identifier as created above) will need
to be known beforehand to figure out which slot in a bucket contains the
correct data.
In other words, this isn't a sci.crypt problem. Try the newsgroup for
whatever language you're doing this, or comp.theory if you have a useful
theoretical approach to the problem set you're wanting to solve. But I
think Knuth probably already went there.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: challenges / competitions???
Date: Sat, 07 Aug 1999 17:00:48 GMT
On Thu, 05 Aug 1999 19:47:43 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Yes my site contains such challenges and there is one that
>ends in Nov 11 for 1000 dollars is cost nothing to enter.
>
What gurantees are there that the prize money exists ?
The other competitions are staking the companies
reputations on their competitions - they have very good reason
to ensure the prizes are paid out properly - what reason do you
have ?
Who decides if somebody has won the prize for your challenge ?
- Tim.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: GETTING RID OF THE "scottNu" cookie
Date: Sat, 07 Aug 1999 17:44:11 GMT
This is a service to the crypto people who visit my site and
don't like the fact there are now cookies on it. For those who
are to ignorant about cookies sorry but now I can keep track
of you somewhat if you have Cookies enabled with JavaScript
on. However I can't track you like the NSA or Microshaft so fear
not.
If you wonder around the Web with Cookies on and JavaScript
on here is a easy way to remove the "scottNu" cookie. First you
must have JavaScript on and cookies on with a Warning before
accepting. IF you reload my page no more than 3 times you should
get several warnings about the cookies. Accept all the cookies until
you get one that says expires on the current time. After that reject
all offers of cookies. And then reload with cookies off. If you have
removed the "scottNu" cookie I will have a message that complains
about you not accepting cookies. At this point you have removed
the "scottNu" cookie. Now turn cookies off and JavaScript off and
reload my webpage or use "Lynx".
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Americans abroad/Encryption rules?
Date: 07 Aug 1999 17:32:24 GMT
> Paul Crowley <[EMAIL PROTECTED]> writes:
>You have to apply for a license even for personal use, no? In theory
>they should issue it as a matter of course; in practice they have no
>idea how to do so, as Matt Blaze demonstrated.
>
No, you don't need a license.
>Best to either (a) wipe PGP from your hard drive before you leave and
>reinstall it from an FTP site when you arrive, or (b) keep quiet and
>hope they don't notice you have it.
That's not necessary at all.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Terry Mechan" <[EMAIL PROTECTED]>
Subject: Download virtually unbreakable encryption programme (Wincrypt IDEA)
Date: Sat, 7 Aug 1999 18:03:58 +0100
Download virtually unbreakable encryption programme (Wincrypt IDEA)
http://www.tmechan.freeserve.co.uk/WINCRYPT95.EXE
More details on
http://www.tmechan.freeserve.co.uk
--
Regards
TJM
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big
Date: 7 Aug 1999 17:28:18 GMT
According to Douglas A. Gwyn <[EMAIL PROTECTED]>:
> I've been programming on 64-bit platforms for over a decade. An upper
> limit would probably be a wordsize capable of counting every particle
> in the universe at every resolvable moment of time, so 128 bits is
> getting there.
Actually, 64-bit architectures were pushed by the possibility to address
more than 4 gigabytes of memory. For calculation purposes, 32 bits are
often sufficient. There are few applications that really use intensively
the possibility to go beyond 32-bit arithmetic without using the math
coprocessor. In that respect, cryptography is the exception.
128-bit architectures will probably be introduced in order to get the
ability to handle very large memory spaces. Please note that I do not
speak of actual memory or disk, but rather virtual page-allocated
spaces.
--Thomas Pornin
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Crossposted-To: alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: 7 Aug 1999 17:20:58 GMT
According to O. Y. Realmink <[EMAIL PROTECTED]>:
> Yeah right, and I have a Pentium with 64 megaoctets of ram and a 7
> gigaoctet hard drive. Give me a break, huh?
This is correct in France. In French, there is no such thing as a
"byte", only "octet". For other sizes, we have "quartet" (four bits),
and otherwise we use "mot" which is "word" (the context specifies the
size of the word).
French-speaking people have other subjects of strife; for instance,
whether the abbreviation for "kilooctet" is "Ko" or "ko".
--Thomas Pornin
(fu2 set to a French-speaking group -- do not post in any other language !)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 07 Aug 1999 12:00:24 -0600
In article <[EMAIL PROTECTED]>, Paul Crowley
<[EMAIL PROTECTED]> wrote:
>
> Best to either (a) wipe PGP from your hard drive before you leave and
> reinstall it from an FTP site when you arrive, or (b) keep quiet and
> hope they don't notice you have it.
> --
There is no reason that an encyption algorithm could not be written as a
stealth program, looks and feels like a game or something else until you
hit a secret key combination. This mechanism could not be prohibited
because it has lots of other uses. There is no reason that the whole
look, feel, and function of something else popularily available could not
be done as a cover in this manner.
"Sir, I find on your computer a program unknown to me. What does it do?"
"Let me show you."
The average border guard is apt to be somewhat computer illiterate anyway.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (KidMo84)
Subject: Re: What is "the best" file cryptography program out there?
Date: 07 Aug 1999 17:21:47 GMT
Well since 1990 weve jumped from an 80mhz processor to around 1000ghz, which a
pentium3 can be overclocked to, even though it really does get too hot, but
that will be perfected before long, i am guessing at least a 1000ghz improvment
of processors every 10 years. Especially in the last 3 years there has been
increased productivity in the speed of processors.
Signed,
KidMo
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: What is "the best" file cryptography program out there?
Date: 7 Aug 1999 17:55:59 GMT
Tom,
That would kick butt. It wouldn't be too hard to implement. Of course,
you would have to have multiple proofs of your identity and the entire
process would have to be supervised via some third party company we have
experience in trusting.
You might bring this idea to companies like VeriSign and the other digital
certificate places. If they could get the CDROM out for say, $20/year that
would be a reasonable price to pay for security.
Keith
[EMAIL PROTECTED] wrote:
: Which brings me to another idea. Wouldn't that be cool to have some
: form of registration where 1024-bit keys (to be safe) are created and
: registered then stored on a CD-ROM which can be bought by anyone? You
: register once a year (possibly with a new key). To register you would
: have to proof your identity (which is also inheriantly trust) say by a
: driver license (this obviously would have to be handled by more then
: one group). It would be a nice way to pick up keys... just an idea.
: Tom
: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Construction of permutation matrix
Date: Sat, 07 Aug 1999 12:16:28 -0600
In article <[EMAIL PROTECTED]>, Nicol So
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > [Description of the familiar algorithm for permuting elements of an
> > array, deleted]
> >
> > If you can extract fractions of bits and have log2(n!) bits of key this
> > will be complete (all permutations are possible).
>
> You can extract a non-integral amount of bits by interpreting the bit
> string as an arithmetically encoded string of symbols.
>
Whether something can be in bits or not is entirely irrelevant as any
keylength can be expressed in unit of information unit, and permutations
generally do not come out to even quantities in any of them. When ever
someones speaks of fractions of bits, it is only a mind thing that looks
good to those that falsely believe that bits are especially fundamental to
everything.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: key lengths
Date: Sat, 07 Aug 1999 12:05:05 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> A large key is actually more of a liability when considering
> related key attacks.
>
Could be, could not be.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What is "the best" file cryptography program out there?
Date: Sat, 07 Aug 1999 12:03:19 -0600
In article <7oha75$ugc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Although it's true in 20 years Blowfish chips could be made really
> easily...
>
By then, Bruce is apt to have found lots more cryptosystems worthy of
assigning an fishy name to.
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: Re: What is "the best" file cryptography program out there?
Date: 7 Aug 1999 18:25:01 GMT
KidMo,
The problem is that there would have to be a VERY VERY VERY large increase
in processor speed to considerably affect the security of our latest
algorithms.
If you compare average brute-force times on a 500mhz or a 5ghz machine,
what's the result going to be? 2^15 years instead of 2^123 years?
And the difference isn't going to be that large, but the point I'm making is
this. Machines would have to be factors and factors and factors faster to
affect the time.
BTW: 2^15 = 32768 years. That's alot of years. :)
Keith
KidMo84 ([EMAIL PROTECTED]) wrote:
: I feel that with new advances in technowledgy, there will be processors out
: there that will be be able to run at 5000mhz+ in the next 20-30 years. So
: though with the processing speed now it might take 485 years to crack an 80bit
: key, in the future with faster processors, and maby special computers just made
: to crack these high bit algorithms brute force, it will greatly reduce time.
: Signed,
: KidMo
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Americans abroad/Encryption rules?
Date: Sat, 07 Aug 1999 11:52:35 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On/le Sat, 07 Aug 1999 00:22:21 -0600,
> wtshaw <[EMAIL PROTECTED]> wrote/a �crit...
> > In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> > >
> > > Maybe I'm biased because I'm French and can refer to laws of my
> > > country, but the French law draws that line on whether you need a
> > > secret info to decode or not:
> > >
> > > - You don't need to learn a secret to "UUdecode" so UUEncode is not
> > > encryption.
> >
> > What if you modify UU somehow so that the software to do the job is known,
> > but just not readily available. You could even write a few thousand RFC's
> > with slight differences, but, unless the software was in play, timely
> > results would take some effort to obtain, surely not when the problem of
> > decrypting first came up.
>
> If the software is not readily available, how can you export it in the
> first place? ;-)
The exact question is, "What is encryption."
>
> I'm not sure about what you mean about "thousand RFC's with slight
> differences".
You could have a thousand variations on a crypto scheme, each one with an
RFC. Then, you could say that any one of them as a distinct algorithm and
was publically known.
>
> If you mean: "the software is very complicated and needs thousands of
> documents to be described fully", it's irrelevent; it's fully
> described and there is no secret, period.
>
> It you mean: "there are thousands of variants, you need one of them
> and you must dig thousands of documents before finding the right one",
> then you have encryption (I'm talking about French law, remember). The
> secret is the applicable RFC's numbers. I think French law tries to
> avoid workarounds like these.
Interesting. Then, what things would hinge on would be whether the exact
algorithm was identified. This would mean that using any encryption, even
classical ones, without flagging what it was would be a problem. The
problem therefore would be not in the program but in the format of the
output which could be changed by another program, even a fledgling word
processor with a clipboard. Or, you could simply cause a program to read
files in an edit field appending manner, no external access to clipboard
required, then make you mods and save the resulting file.
Repeating myself, you could replace the guts of the output of PGP with
something that was not PGP. This should not affect the status of either
PGP or the other algorithm since it is a *format* thing. If it doesn't
affect them, what does it affect?
>
> > So, is being secret enough, or is being readily available also an
> > important factor.
>
> Having to know a secret is enough. And I repeat, it has to be readily
> available to be of use, anyway.
>
> > > - You don't need to learn a secret to decode ROT-13, so ROT-13 is not
> > > encryption, either.
> > >
> > Tell it to the judge and see what he says. I doubt than many even
> > understand what ROT13 is. Of course, the little function I use makes 13
> > the default key, but can be overridden by one of the other choices. It
> > would seem that using a default key is not sufficient to deny something is
> > encryption, but if it were, I could post lots of interesting crippled
> > algorithms.
>
> If 13 is a mere default that can be overriden, I won't call the
> algorithm ROT-13, but ROT-N, and it's encryption. All my point is
> there.
>
> Computer illiteracy among judges is another problem (not only in the
> USA...).
>
> > Then, one could even clearly label ciphertext as something other than what
> > it was. You could for instance label something as PGP, but have it be
> > something else. Hey, that sounds like a useful utility: Just take one of
> > my algorithms that outputs in the same set as PGP, and format it the same
> > way too.
>
> Something like the following, for instance?
>
> -----BEGIN PGP MESSAGE-----
> Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
>
> Npghnyyl, guvf vf abg n CTC zrffntr ohg n EBG-13 rapbqrq fragrapr.
>
> -----END PGP MESSAGE-----
>
> How will you decode the message above? You will try a list of
> algorithms you know. That's cryptanalysis. Or you will try several
> keys for each algorithm. that's brute-force cracking.
>
> How can you cryptanalyse or brute-force crack something that is not
> encryption?
>
> --
> ___________
> _/ _ \_`_`_`_) Serge PACCALIN
> \ \_L_) [EMAIL PROTECTED]
> -'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
> _/___(_) la r�alit� la plus bancale. -- San Antonio
--
Sometimes you have to punt, and hope for the best.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Is breaking RSA NP-Complete ?
Date: Sat, 7 Aug 1999 13:09:49 -0400
Dear Bryan,
Let me go semantics again.
Do you think it should be PSPACE-hard (to be safer)? I am
almost sure no ROSicoNP sort of stuff takes birth this time. :)
Dear Bryan, please do not think I am picking on you. I simply
want answers, perhaps as much as you do. You sure this is
utterly trivial? Please do not feel bad. I make mistakes all the
time. It is through the mistakes we make we get to truth. BTW,
in a rush one can say something one does not mean to.
Thanks again for your discussion.
--- (My Signature)
[EMAIL PROTECTED] wrote in message <7of831$i35$[EMAIL PROTECTED]>...
>I wrote:
>> NP-Hard is neither a subset nor superset of PSPACE.
>
>Ooops, another mistake. The question of whether
>NP-Hard contains PSPACE is still open. NP-Hard
>is a superset of PSPACE if and only if P=NP.
>
>Utterly trivial of course.
>
>--Bryan
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
------------------------------
** 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
******************************
