Cryptography-Digest Digest #1, Volume #11 Sat, 29 Jan 00 14:13:01 EST
Contents:
Re: Q: DFT (Mike Andrews)
Re: NIST, AES at RSA conference (CLSV)
Re: Pencil & paper cipher question (Salvatore Sanfilippo)
Is there a practical guide to using crypto? ("JCardinal")
Anyone read this book? (Paris Guffey)
Re: How to password protect files on distribution CD (Chuck)
Re: How to password protect files on distribution CD (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Pencil & paper cipher question ("r.e.s.")
Re: How to password protect files on distribution CD (Vernon Schryver)
Re: Mac encryption algorithm? (Vernon Schryver)
Re: Help needed on peculiar use of cryptography (David P Jablon)
Re: Block chaining (zapzing)
Math contest winner from Ireland... (ef)
Keyword Cipher Cracker program (RREYNARD)
Re: NIST, AES at RSA conference (CLSV)
Avoiding Collisions in a Hash Function. was Re: Help needed on peculiar use of
cryptography (zapzing)
Re: Help needed on peculiar use of cryptography (David P Jablon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: Q: DFT
Date: Sat, 29 Jan 2000 16:38:17 GMT
[EMAIL PROTECTED] wrote:
: In article <[EMAIL PROTECTED]>,
: Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> DFT, like all such transforms, has an inverse. However, due to the
:> unavoidable rounding errors of real computations involved, a vector
:> of integers might not get back to exactly the same values. What
:> techniques can one best employ to obtain an exact inverse?
:> (Simple employment of multi-precision arithmetics might not be a
:> reasonable cure in all cases, I surmise.)
:>
:> M. K. Shen
:>
: Have you measured the error between the original
: integer sequence and the real sequence got back from inverse-DFT ?
: Maybe it is sufficient to apply a rounding to the
: real sequence obtained from I-DFT to yield the original
: integer sequence.
Perhaps so, but there's this little voice in the back of my
mind talking about analogies to condition numbers and badly-
conditioned matrices in linear algebra.
--
Death is just Mother Nature's way of telling you
to Slow Down.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 16:42:19 +0000
[EMAIL PROTECTED] wrote:
> CLSV <[EMAIL PROTECTED]> wrote:
> > A *single* algorithm that breaks *all* key-based ciphers?
> > I think/believe that this is awfully close to being
> > reducible to the Halting Problem.
> By "key based", I mean I'm assuming the usual model in which
> the algorithms are known to the attacker and the key is
> secret, and by "practical" I mean encryption and decryption
> with a given key are reasonably efficient. Clearly if we
> allow our solver to take arbitrarily large but finite time,
> we could actually construct such a thing, since exhaustive
> search halts.
But not in polynomial time. Still the problem is too
vague to make any specific claims. For example the definition
of "breaking a cipher" is very ambiguous. If you consider
enumerating all keys until the right one is found than there
are no secure ciphers but you say that the existence of
such an algorithm is uncertain so you probably don't consider
this as breaking a cipher.
Regards,
CLSV
------------------------------
From: Salvatore Sanfilippo <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Sat, 29 Jan 2000 15:47:13 GMT
r.e.s. <[EMAIL PROTECTED]> wrote:
: "Salvatore Sanfilippo" ...
: : algorithm. For example using solitaire you are subjected to
: : "man in the middle known ciphertext attack", and the receiver
sorry, I mean "MITM known plaintext attack"
: "It is interesting to note that, regardless of how inconvenient
: it may be to share keys for a secret-key cipher, this is an
: inherent authentication which prevents MITM attacks."
How it's possible? Maybe I didn't understand solitaire but seems that there
isn't no correlation between plaintext and the stream used to xor it so anyway
P1 xor C1 = S1 (with P1 part of plaintext, C1 part of ciphertext and S1 part of
stream). Expecially in solitaire the sender should
care about MITM attack since the message will be probabily sent
using very insecure channel (via mail?) and since modifing some character of
cyphertext will not result in a desync. Do you agree?
antirez
------------------------------
From: "JCardinal" <[EMAIL PROTECTED]>
Subject: Is there a practical guide to using crypto?
Date: Sat, 29 Jan 2000 10:35:31 -0700
Hi all I'm a newbie at cryptography, please don't flame me if this is the
wrong place! <grin>
I am considering using encryption in some of my business applications. I
have downloaded crypto++ and successfully encrypted and decrypted with
twofish.
However I dont' really know anything about it in terms of: how do you use
it in a manner that ensures your not exposing any weaknesses. I have a huge
mental block when it comes to more than basic mathematics and dont really
want to know how it works any more than I have to.
Is there a tutorial or faq someone could point me to that explains the
practicalities of using encryption? There are a million deeply
technical/mathematical articles and I have seen them all in the last few
days, but I can't seem to find a practical one.
I've been to counterpane and read the documents related to twofish and
blowfish which is an excercise in decryption in itself for someone with my
limited knowledge.
One thing I really want to know is if I use a 128bit key and encrypt a file
using twofish in ecb mode, whats to stop someone from attempting every
possible 128bit key until they decrypt it?
It seems like it would be a trivial matter if the person knew what
encryption algorithm was used. I know I'm missing something fundamental
because it's not supposed to be that easy, and thats why I dont want to use
it until I understand it a little better.
TIA for any help, pointers etc.
- John
------------------------------
From: [EMAIL PROTECTED] (Paris Guffey)
Subject: Anyone read this book?
Date: Sat, 29 Jan 2000 17:51:28 GMT
Hello,
I saw this book at Borders and only had time to briefly flip through
it. Has anyone read it, or could anyone recommend it to me? I know
it covers different crypto systems, but does it do a good job about
cryptanalysis? It looks like it would be a handy reference to have.
Codes, Ciphers and Other Cryptic and Clandestine Communication: 400
Ways to Send Secret Messages from Hieroglyphs to the Internet
by Fred B. Wrixon
Any comment would be greatly appreciated. Post or email.
--
Paris Guffey
------------------------------
From: Chuck <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 10:59:00 -0600
On Sat, 29 Jan 2000 10:55:32 GMT, [EMAIL PROTECTED] (Dave
Mundt) wrote:
> I concur. Hence the reason that SOME companies resort to the
>hardware solution of a "dongle", a hardware key that hangs off the
>parallel port and is queried by the software to see if it can run.
> These things are an adequate solution, but, inconvenient for the
>user, and, are guarenteed to shut them down when damaged. Also,
>although the technology workes pretty well now, there can be conflicts
>that make it hard to print through these devices.
Also, nobody has come up with a dongle-protection scheme yet that
can't be cracked. You'll find a long list of cracks for
"dongle-protected" programs in the crack groups. It's just a big scam
by the sleazy copy-protection companies who claim that their schemes
are "absolutely impervious" to cracking even though widely-known
cracks have been around for years.
This thread may have gotten off on a tangent. I don't think the
original question was about software copy-protection so much as a way
to password-protect general data. Since this is a commercial use, PGP
would require payment while the GNU version would still be free. If
we're talking strictly Windows 9x systems (not Windows 2000 or NT)
then scramdisk might also be a good solution (see
comp.security.scramdisk).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: Sat, 29 Jan 2000 17:37:17 GMT
On Sat, 29 Jan 2000 00:20:40 GMT, [EMAIL PROTECTED] wrote, in part:
>We have developed some software and we want to ship them on CD
>in encrypted form to our customers. Then we want to give them some keys
>to decrypt the software. We should be able to generate the passwords
>for our customers. We might want to put further restrictions on
>encryption and authorization in the future but not now.
>What software do I need to use for this? If this is irrelevant to this
>group, please point me to the correct one.
The basic idea is that while the program on the CD-Rom is encrypted
with one, fixed key, you can generate a key for an individual customer
which, when combined with a serial number, or the customer's name,
yields the required decryption key.
This means that if the security program also on the CD-Rom is not
disassembled, a customer would have to give away two pieces of
information to let someone else use a copy of the CD-Rom, one of which
would identify the customer.
Unfortunately, disassembling programs is much easier than cracking
encryption, so the level of security you can achieve this way is
somewhat limited.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 17:50:45 GMT
On Fri, 28 Jan 2000 20:37:46 +0000, CLSV <[EMAIL PROTECTED]> wrote, in
part:
>If the problem would
>be formally defined it is easier to talk about
>reduction to the Halting problem.
Well, I'll try to sharpen this up without getting too mathematical.
A single computer program may be one that we know will halt after a
certain number of steps. The Halting Problem is the problem of finding
a way to determine if any arbitrary program will halt: one someone
else has presented us with, rather than one we have chosen ourselves.
If there were a solution to the Halting Problem, then there would be
no unsolved problems in mathematics - as Fermat's Last Theorem (or
course, now solved) and the Goldbach Conjecture, for example, could be
phrased in the form of a program.
Being able to say that a given cipher can't be broken requires one to
know all the ways that a cipher could possibly be attacked, and to
have checked them all, and found them all to be ineffective. If there
are unsolved problems in mathematics, then there are ways to attack
ciphers that haven't been discovered yet.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 17:42:33 GMT
On Fri, 28 Jan 2000 00:09:44 GMT, [EMAIL PROTECTED] wrote, in
part:
>But where is the proof that the adversary will have to
>attack it that way? If in fact he has a general solution,
>then the argument is irrelevant. Does adding additional
>cipher layers seem stronger? Absolutely. Does it help us
>prove strength? No, at least it hasn't yet.
If the only response to a situation where "we lack proof" is to find
some way to get proof, your objection would be fatal.
However, if "we can't get proof" is also considered as a reason to,
failing some way to obtain proof, try to at least do everything we can
to make our ciphers stronger - without proof that we have done enough,
without the knowledge whether or not we may have done more than is
necessary - then things like Mr. Ritter's multi-ciphering are entirely
sensible responses to the situation.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Pencil & paper cipher question
Date: Sat, 29 Jan 2000 10:04:56 -0800
"Salvatore Sanfilippo" wrote ...
: r.e.s. <[EMAIL PROTECTED]> wrote:
: : "Salvatore Sanfilippo" wrote...
: : : For example using solitaire you are subjected to
: : : "man in the middle known ciphertext attack",
:
: sorry, I mean "MITM known plaintext attack"
:
: : "It is interesting to note that, regardless of how inconvenient
: : it may be to share keys for a secret-key cipher, this is an
: : inherent authentication which prevents MITM attacks."
As David Wagner points out, that quote from Terry Ritter's Glossary
refers to *key* authentication instead of message authentication
(my apologies to Terry for taking it out of context).
Please just ignore that reply of mine, since I misread the question
altogether.
: How it's possible? Maybe I didn't understand solitaire but seems that
there
: isn't no correlation between plaintext and the stream used to xor it so
anyway
: P1 xor C1 = S1 (with P1 part of plaintext, C1 part of ciphertext and S1
part of
: stream). Expecially in solitaire the sender should
: care about MITM attack since the message will be probabily sent
: using very insecure channel (via mail?) and since modifing some character
of
: cyphertext will not result in a desync. Do you agree?
Yes, I see your point.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: How to password protect files on distribution CD
Date: 29 Jan 2000 10:14:24 -0700
In article <[EMAIL PROTECTED]>,
Dave Mundt <[EMAIL PROTECTED]> wrote:
> I wonder, though, WHY you think this is necessary? It would be
>much simpler to distribute the software, and, like most other software
>packages, require a license number to be entered before it can install
>or run.
>
> Seems to work for Microsoft well enough...
As far as I can tell from accidentally using the wrong CDROM, every
Microsoft license numbers work for every CDROM of a given version of a
product. The continued screaming and crying from Microsoft about the
oriental pirates and other warez vendors, and the continual changes in
the Microsoft number certificates suggests that Microsoft is not entirely
happy with whatever they're doing.
There is no useful difference between a "license number to be entered"
and a "password." As has been said, all conceivable copy protection
schemes are easy to break. Any licensing scheme is merely a failure to
work without some trivial hardware or without some input. Breaking any
license is at most a matter of debugging a binary without source. That
is within the expected and required daily competence of zillions of
programmers. No one with a clue hopes for hard to break, not to mention
unbreakable licensing.
All licensing has two rational purposes. The first is to encourage honest
customers to pay for the software. If breaking the copy protection scheme
is expensive (requires lots of programmer time), and if other things such
as good customer support come with a license, customers worth having will
buy a license. Other customers aren't worth having and generally don't
matter.
The second is to provide prima facie evidence of evil intent in court.
If a user of protected software doesn't have a password, then the user
must have intentionally violated the terms of the license by which the
user obtained the software (and I don't mean shrink wrap nonsense). If
a per copy license is required, then extra working copies were not made
accidentally.
I do not understand why people buy dongles, other than being suckers.
Modern computers have more than enough unique bits to generate a globally
unique signature that can be used instead of a value from a dongle.
Since most computers or at least applications need to keep time, it is
easy to use the unique signature of a computer to generate a license
that enables only part of an application or for a limited time. Some
dongles have encrypted read/write storage, but computers have more.
Today, no rocket science is required to do everything a dongle can do
purely with software...well, except for working around MicroStupid
software that hides handy things like Ethernet addresses when stupid,
amazingly insecure braindead protocols like NetBUI are turned off.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Mac encryption algorithm?
Date: 29 Jan 2000 10:48:08 -0700
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Paul Schlyter wrote:
>> And why is this [little-endian] byte order "wrong" ?
>
>It's pretty evident to people who've dealt extensively with both,
>that little-endian is "more natural" from the point of view of
>arithmetic and addressing. For example, consider how it supported
>pass-by-reference integers in DEC PDP-11 FORTRAN; that was so
>important that the implementation of 32-bit integers did not
>match the mixed-endian storage layout of the FP-11 floating-point
>unit (which included support for 32-bit integers), despite the
>speed advantage had the FP-11 layout been used. With big-endian
>representation, the low-level operations constantly have to take
>word size into account; little-endian representation is much more
>cleanly extensible.
That is a religious view without factual basis. Regardless of byte order,
your compiler and everything else must continually take the width of
numbers into account. It makes no real difference whether you increase
an index to get to the more significant bits of a number, or decrease the
index. That and whether the "starting" address of the number is the most
or least significant digit (i.e. word or byte) is the sum total of the
difference.
And yes, I've written code for big and little ending systems, including
some low level numeric stuff such as transcendental and multi-precision
libraries.
Consider that more than one non-Intel CPU can be used in either big or
little endian systems. Some systems have all of the hardware required to
run both big and little endian programs at the same time, thanks to a
process status bit. You don't find biendian operating systems because of
the unendurable hassles inside the operating system of dealing with system
calls from both flavors, and because application writers don't like having
to use ASCII, BCD, or even XDR for all disk and inter-process data.
(doesn't even Intel's Mercede have the per-process endian bit like MIPS?
or is it merely a CPU configuration bit?)
I used to work at a major UNIX vendor were pointy-haired bosses decided
that a biendian UNIX compliant with the BSD, POSIX and SVR4 (de facto)
standards was the ticket. It was more than a year before that particular
nonsense fell off the schedules, and people with brains could stop hurting
themselves by dealing with biendian kernel hassles. Of course, the biggest
pointy-haired advocate later claimed to have opposed it all along.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sat, 29 Jan 2000 18:36:02 GMT
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Sgwbutcher) wrote, in part:
>
>>a social security number can be encrypted
>>so that the informational value of the cyphertext can be retained but the
>>plaintext cannot be recovered?
>
>It is not clear what this wording means. However, a one-way hash
>function can allow a social security number to be encrypted so that,
>althought the social security number itself cannot be recovered, its
>hash is still usable as an identifier by which records can be matched.
John, don't fool yourself. Given the small space of SS #s, a
brute-force search will reveal which # matches the hash very quickly.
The attacker's job is equivalent to cracking a 20-bit key.
That said, there's still value in hashing the #'s to prevent
efficient large-scale disclosure of the entire database.
An iterated hash would be recommended here, tuned to balance
the speed of access against the cost of attack.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Block chaining
Date: Sat, 29 Jan 2000 18:34:42 GMT
You know I , personally, have
always wondered why people bother to do
block chaining at all. If you had a
good block size, say 256 bits, you
could make half the block be random
numbers and half be plaintext.
Then no chaining would be necessary,
and an error in one block would not
propagate through the whole
subsequent message. Also you could
use parallel processing to encrypt
the message, something to think
about for the future.
ZZ
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: ef <[EMAIL PROTECTED]>
Subject: Math contest winner from Ireland...
Date: Sat, 29 Jan 2000 13:39:22 -0500
Hello-
A year or two ago there was a high school girl from Ireland that won a
math contest for her solution dealing with algorithms that would produce
faster methods of encryption.
Does anyone know her name or what's happened to her since? Very bright
person.
Thankyou,
Eric
------------------------------
From: [EMAIL PROTECTED] (RREYNARD)
Subject: Keyword Cipher Cracker program
Date: 29 Jan 2000 18:54:03 GMT
A free copy of the Secret Code Breaker Keyword Cipher Cracker program is now
available via the SCB Online website <http://codebreaker.dids.com>. As with
the other SCB products, it is intended to be a learning tool for the novice
cryptanalyst and to generate interest in cryptography.
If there is someone you think would be interested in this program (DOS based
systems only) you can direct them to the SCB Online website, where they can
Email a request for a free copy (Zip file).
This program is designed to teach the user about Keyword Ciphers and one method
of cracking them. It is not a general purpose monoalphabtic cipher 'cracker'
and therefore probably would be of little interest to a serious cryptanalyst.
The keyword list that is provided is a simple 25,000 word list and contains
few, if any, keyword phrases. However the program is designed so another text
file (ASCII) containing additional keywords could be used.
Regards,
Robert Reynard
Author, Secret Code Breaker series of crypto books for young readers (8-16 yr.)
Secret Code Breaker Online at ==> http://codebreaker.dids.com
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 18:58:21 +0000
John Savard wrote:
> Being able to say that a given cipher can't be broken requires one to
> know all the ways that a cipher could possibly be attacked, and to
> have checked them all, and found them all to be ineffective.
If breaking a cipher is equivalent to solving (a hard
instance of) a problem in NP and someone would prove
that P != NP then the cipher can not be broken with
polynomial effort.
> If there are unsolved problems in mathematics, then there are
> ways to attack ciphers that haven't been discovered yet.
There are also unsolvable problems in mathematics
that may provide provable security.
Regards,
CLSV
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Avoiding Collisions in a Hash Function. was Re: Help needed on peculiar use
of cryptography
Date: Sat, 29 Jan 2000 18:49:07 GMT
In article <86ustv$lcu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
(snip)
> With a long string or salt as you call it you are risking that
more
> than one ID could map to the same hash. In reality you can never fully
> hide the encrypted ID since it would have to be unique if it was to
match
> unique records. I would not use a hash for this kind of work where
zero
> collisions are required.
(snip)
It seems to me there ought to be several ways
to get around this problem if you are concerned
about it. One way would be to select several
different salt values, and hash with each one
of them, catenating each separate hash value to
make your collision free one way function.
If you catenated enough hashes, so that their
total length exceeded the length of the message
by a good amount, surely a collision would be
very improbable.
--
Do as thou thinkest best.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Help needed on peculiar use of cryptography
Date: Sat, 29 Jan 2000 19:03:03 GMT
In article <[EMAIL PROTECTED]>,
Sgwbutcher <[EMAIL PROTECTED]> wrote:
>
>My question is "is there a way that encryption or a specific use or kind of
>encryption can be used so that, say, a social security number can be encrypted
>so that the informational value of the cyphertext can be retained but the
>plaintext cannot be recovered? [...]
The simplest approach is to store a one-way hash of the SSN, as
in SHA1(SSN). However, as there are only a billion or so possible
SSN's an attacker can always recover it with a brute-force attack.
Salting the hash as suggested in another post merely obfuscates
the result, unless the salt is kept more securely than the hash data.
In these simple schemes, the client must reveal the SSN to the server for
comparison. To get ultimate privacy protection for comparing
small secrets, you can use zero-knowledge password proofs.
However, when you're using a small secret as the basis for a
database lookup key, there are limits to what the privacy that
can be achieved.
Another example of a use for ZKPPs came up when two faculty members,
one a math professor, were discussing a harassment case. They wanted
to compare names to see if they were talking about the same person,
but didn't want to reveal the names to each other in case it wasn't the same.
Links to these solutions can be found at <www.IntegritySciences.com/links.html>
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
** 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
******************************
