Cryptography-Digest Digest #191, Volume #9 Fri, 5 Mar 99 16:13:05 EST
Contents:
Re: My Algorithm (Medical Electronics Lab)
Re: RNGs (Medical Electronics Lab)
Re: Where can I get a Public Key system? (Robert Scott)
Re: Common meaning misconception in IT, was Re: Unicity of English, was Re: New
high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: Testing Algorithms (Stoned Nick Vlassopoulos)
Re: RNGs (wtshaw)
Re: An export question... (wtshaw)
Clipper doubleplusungood...Your Honor, I plead the 4th (Doggmatic)
Public search, secure insert & delete Was: public read, secure write? (Bryan Olson)
Re: An export question... (Jim Gillogly)
Key equivocation does not define unicity, was Re: Unicity of English, was Re: New
high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
Re: Fingerprinting as a password (John Savard)
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: My Algorithm
Date: Fri, 05 Mar 1999 12:31:50 -0600
[EMAIL PROTECTED] wrote:
>
> Would this group be more responsive to analyzing my algorithm if I provided a
> small paper on it? And why I think it is strong? If so I could write a small
> paper on it. Describing the algorithm, and why I think it's resistant to some
> attacks (ciphertext-only, plain/cipher text, chosen-ciphertext).
Yes, it would help a lot. You can put the complete paper on your
web page, and post one section every couple of days just to keep
advertising :-)
>
> I would really appreciate some analysis. I think it's somewhere between a
> stream coder and a OTP. I am new to encryption, I really don't know a whole
> lot. But would like to learn. I think so far my algorithm is strong because
> it's value/position and plaintext dependant coding. As long as the key is
> well chosen (LSB of audio input for example) and distributed carefully (i.e
> one a floppy disk).
>
> If you can read 'C' code it's at: http://members.tripod.com/~tomstdenis/e.c
Another thing that can help is to post text comments along with
the code. Something like "I wrote this subroutine to do perform
function x which is described as ..." Comparing the paper to the
code is much easier that way and it gives people like me a clearer
picture of what you're trying to do.
Another thing to put in the paper is some comparison to other
ciphers which may have some similarity. This gives us a chance
to figure out what possible attacks might work from similar
attacks on similar ciphers.
And be patient :-) While it's fun to analyze new ciphers, there
are lots of other things to do.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: RNGs
Date: Fri, 05 Mar 1999 12:34:54 -0600
[EMAIL PROTECTED] wrote:
>
> hello all,
>
> i have been searching for material on cryptographically secure RNGs. I am
> trying to find answers to questions.
>
> 1. what are the properties of cryptogrphically secure RNGs.
> 2. what are the (and if there are) tests for such RNGs.
>
> Any pointers/books/URLs are helpful..
Check out pLab: http://random.mat.sbg.ac.at/ or this one:
http://www.io.com/~ritter/RES/RNGMACH.HTM
for lots of good reference papers.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: Where can I get a Public Key system?
Reply-To: see text
Date: Fri, 05 Mar 1999 18:44:14 GMT
On Fri, 5 Mar 1999 15:36:38 +0100, "PCM, Joakim Johansson"
<[EMAIL PROTECTED]> wrote:
>Hello
>
>Use Blowfish Algorithm insted of RSA becose Blowfish is free to use..
>
>Good luck...
>Frank LaRosa skrev i meddelandet <[EMAIL PROTECTED]>...
>>Hello,
>>
>>I need a resonably secure public-key cryptography algorithm that I can
>>use in a commercial product. I'm only encrypting a small amount of data
>>(about 20 bytes). What are my options? Do I have to buy a license from
>>RSA, or are there alternatives available?
>>
Blowfish is not public key.
Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Common meaning misconception in IT, was Re: Unicity of English, was Re:
New high-security 56-bit DES: Less-DES
Date: Fri, 05 Mar 1999 18:59:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Peter Pearson) wrote:
> In article <7bkvts$e6l$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > Bryan Olson <[EMAIL PROTECTED]> wrote:
> ...[snip]...
> >
> >But, it is no surprise that you are again confusing issues before this list
> >-- instead of learning things first. It is fine to ignore basic facts and
> >perhaps you can learn a lot more just by reading and asking questions. I
> >believe you will receive a lot more attention and much improved answers once
> >you start to truly communicate. Just trust yourself a bit more, in a fair
> >dialogue -- if you do not understand something -- ask. By the current odds,
> >as in the archives, if you do not understand something then most ptobably the
> >problem lies at your side... so, give yourself a chance.
> >
> >Ed Gerck
>
> Please refrain from using this newsgroup to broadcast personal
> insults, particularly personal insults directed at one of our most
> scholarly contributors.
I certainly disgree in all counts of your message and I see no personal insult
from my part. I have never insulted anyone on this list or anywhere else and I
thus consider your observation unaceptable. I you have further comments, pls
e-mail me in private.
Esd Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Stoned Nick Vlassopoulos <[EMAIL PROTECTED]>
Subject: Re: Testing Algorithms
Date: Fri, 05 Mar 1999 21:01:16 +0200
D wrote:
> I'm sure that there are many ways to test an algorithm besides the ways I
> can think of, but I have a few suggestions:
> You can test to see if the output is some sort of simple function of the
> input and things like the next block of ciphertext, another encrypted file's
> corresponding block, etc.
> You can check to see if the output has any common charactarictics.
> You can get to know your system better by computing the combined
> function through all the rounds.
> You can test the Strict Avalanche Criteria, which specifies that if 1
> bit in the input changes, at least half of the output bits should change.
> Those are my suggestions. I actually used them in building my
> cryptosystem. It passes all the tests (after enough rounds) but is a little
> slow, 1.5 Kbits/(sec*round). You do the math Chester.
> Did you know that ciphertext is not in the standard MS Word 7
> Diccionario?
Where can i find theses Criteria specifications ??? Is there a url / book or
something ????
Thanx
Nick Vlassopoulos
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: RNGs
Date: Fri, 05 Mar 1999 12:48:28 -0600
In article <7bp2o1$v0v$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> hello all,
>
> i have been searching for material on cryptographically secure RNGs. I am
> trying to find answers to questions.
>
> 1. what are the properties of cryptogrphically secure RNGs.
> 2. what are the (and if there are) tests for such RNGs.
>
> Any pointers/books/URLs are helpful..
>
A pRNG that is not particularily good still can have uses in crypto. How
good it need to be depends on its use. Now, those may not seem too
helpful comments, but they are nevertheless true.
A multiseeded approach can use a pretty weak scheme and still be
effective, however a simple stream cipher can put most of the burden of
security on the pRNG itself.
--
Truth is whole in the least of its parts.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: An export question...
Date: Fri, 05 Mar 1999 13:20:27 -0600
In article <01be66fe$c1f2e540$0100000a@oemuser>, "Tom"
<[EMAIL PROTECTED]> wrote:
> I live in the US and am currently developing some freeware that I'd like to
> publicly post. The app doesn't encrypt any data but it does use MD5 as a
> signature and high quality "checksum". What I've been unable to determine
> is if MD5 or any other strong hash is exportable from the US without a BXA
> review. The SHA-1 spec states that "export restrictions may apply" but I
> can't find anything specific about it or the exportability of any other
> hash algorithm. I'd really appreciate if someone could point me to a source
> of information or enlighten me about this? Lawyers I've spoken to don't
> have a clue and the Commerce Department documents I've tried to wade
> through seem to contradict themselves at various points.
>
> Thanks,
>
> Tom
I take you words as an being an objective and accurate evalution of fog
that exists. Remember, most all the official noise is made by individuals
who personaly haven't the least technical clue about these matters at all,
and so their words consequently are in the form of noise emminating from a
heated void, and they wish you would join them in their ignorance, thank
you very much.
Meanwhile, keep writing. If you can find a secure site to distribute your
stuff, go that way to at least get it out to some.
--
Truth is whole in the least of its parts.
------------------------------
From: Doggmatic <[EMAIL PROTECTED]>
Subject: Clipper doubleplusungood...Your Honor, I plead the 4th
Date: Fri, 05 Mar 1999 19:31:19 GMT
I was just wondering about people's opinions on the likelihood of gov't
mandated key escrow systems sneaking through legislation and becoming law.
How can the proponents of being "secure in their person" stem this trend
towards government intrusion on privacy: digitized driver's license pictures,
fingerprints on checks and driver's licenses, etc. Are the arguments of
"rights to privacy" strong enough to fend off such well-funded,
politically-influential, and globally-subversive opponents as the NSA, NRO
and CIA combined. Is it agreed, at least, that privacy is a basic human
right, even to unconvicted criminals? Or is "probable cause" so loosely
defined now that buying Salhman Rushdie's (sp?) Satanic Verses would be
enough to make me an enemy of the State, or worse yet, by saying the word
"bomb" or "Allah" over the phone? (Sounds like an interesting book .... it's
got a cool title, anyways...) Are there even foreseeable conditions where
the constitutionality is suspended (ala Lincoln Administration) and the eye
of gov't pervades our lives even more? If a certain piece of tamper-proof
hardware became mandatory for data communications equipment, how hard would
it be to slip an Infinity transmitter into the set-up. Infinity transmitters
allow the affected phone to be called, but if the caller transmitted a
certain frequency (the note 'C' on a harmonica was common), then the affected
phone would not ring, but would would act like it were off-hook, so that the
caller could hear whatever sounds the affected phone picks up. Worse, if the
affected phone were actually picked up, the connection would be broken and
the line would reset, so that the person wouldn't suspect anything. Marinate
on that one....
___/Mike ...two legs good, four legs bad? ... Why conform?
__/. | For my next trick, WATCH as this humble mouse breaks
\-__ \___ Windows at the mere press of a button.
\ Hey! Where are we going, and why am I in this handbasket?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Public search, secure insert & delete Was: public read, secure write?
Date: Fri, 05 Mar 1999 11:14:38 -0800
Florian Erhard posed the problem:
> >Given is the following situation: There's a set of data,
> >saved in a file, which should be protected under following conditions:
> >- only one person, the owner of the set, should be able to modify the
> > data.
> > (Modifications by everyone else should be noticeable, but don't have
> > to be prevented.)
> >- the information about who is the owner has to be stored with the data.
> >- everyone should be able to read the data.
> >- the bad guys have read and write access to the stored data.
Patrick Juola answered:
> Sounds like an ideal application for an appended signature. Owner
> writes the file, owner *signs* the file, and places the file+signature
> together in storage.
Here's a variation on the problem that cryptographers might enjoy.
There exists an elegant solution and it's is a handy tool to have
around. As in the problem above, only one person, say Alice, is
allowed to make changes to the file. Anyone who knows Alice's
public key should be able to read the file and verify the result.
Now let's say our file is indexed, and contains N records. If we did
not have the security requirement, we could implement search, insert
and delete each in O(log N) time. We want to add security, but keep
efficiency. If we use a simple appended signature, then inserts,
deletes and searches would take O(N) time* each, including the time to
sign and verify. The problem is make each operation run in O(log N)
time, again including sign and verify.
Note that we do _not_ want to sign and verify only the individual
records of the file. When Alice inserts or deletes a record, she
needs to produce a signature covering the entire state of the
file. When Bob searches the file he needs to verify the result,
even if the result is that the file does not contain the target
record.
--Bryan
* Strictly speaking I should use Omega(N) or Theta(N) here.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: An export question...
Date: Fri, 05 Mar 1999 12:10:30 -0800
Reply-To: [EMAIL PROTECTED]
Tom wrote:
> What I've been unable to determine
> is if MD5 or any other strong hash is exportable from the US without a BXA
> review. The SHA-1 spec states that "export restrictions may apply" but I
> can't find anything specific about it or the exportability of any other
> hash algorithm.
My assumption is that MD5 and SHA-1 do not require any export licensing
or review from BXA, based on Category 5 (Part 2) Section A:
This entry does not control: ...
g.) Data authentication
equipment that calculates a Message
Authentication Code (MAC) or similar result
to ensure no alteration of text has taken place,
or to authenticate users, but does not allow for
encryption of data, text or other media other
than that needed for the authentication;
I find no mention of software implementing this kind of authentication.
By way of warning, I've also been told that the State Dept., when
it was in control of this stuff, did issue at least one export
license allowing somebody to export SHA-1, which suggests that somebody
there thought they had jurisdiction. That interpretation appears to
violate the spirit of the EAR language, which appears to address the
issue of crypto algorithms to provide confidentiality only.
My interpretation appears to be shared by Ron Rivest, whose Chaffing
and Winnowing proposal is based on the assumption that authentication
algorithms are explicitly not covered by the EARs.
Disclaimers: Don't bet your freedom on legal advice you get free on
the Net. This is not legal advice and I am not a lawyer. I resent
having to put in all these weasel words. I am never heartbroken when
somebody violates or circumvents the U.S. encryption export regulations
in any way, but I don't explicitly encourage that naughty behavior.
--
Jim Gillogly
Trewesday, 13 Rethe S.R. 1999, 19:56
12.19.5.17.18, 6 Edznab 11 Kayab, Seventh Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: Key equivocation does not define unicity, was Re: Unicity of English, was Re:
New high-security 56-bit DES: Less-DES
Date: Fri, 05 Mar 1999 18:54:31 GMT
In article <7bnfoa$k9b$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
Bryan:
It is NOT key equivocation that defines unicity. This is one of your
recurring misconceptions. You are mistakenly taking **one** of the cases
calculated by Shannon where key equivocation was close to message
equivocation for one cipher ...to stand for all cases.
I understand this was perhaps also caused by the fact that you could not see
(as you declared, but they have been there for 50 years in that same paper)
the message equivocation curve in Fig. 7, neither did you see "message
equivocation" mentioned one line before Fig.7, nor one line after Fig. 7 --
all in that same Shannon paper. So, there are a lot of plain sight readable
information that has simply escaped you in that single page .. besides the
other ones I have commented on before.
However, you come here for tens of messages and parade that ignorance in
public. You cannot be excused for that behavior since even for you it would
have been a lot less time consuming if you had just read the f. paper!
BTW, "read" as used in the technical sense, also including all lines and
graphs of the paper. If you do not understand, ask. An affirmation is not a
question, and while to ask to ask does not hurt... to affirm what you have
not even read is not acceptable. But, may you use this incident positively.
Referring to the equations for conditional message entropy and conditional key
entropy, I wrote:
> [...]
> > Again, just looking at the two (correct) equations should convince anyone
> > versed in high-school math that they are independent. If you are still not
> > convinced, I cannot help further.
>
> I'm not asking for your help; I'm pointing out your error.
It is the reverse, see below, Bryan. Again, you are free not to understand.
> On page 661 of Shannon's CTOSS we read,
>
> If M is the message, K the key, and E the enciphered
> message, or cryptogram, we have
> E = f(M,K)
> that is E is a function of M and K.
>
> So instead of just looking at the equations, we should
> study the paper and understand them.
you extrapolate far too much.
> Knowing that E is a
> function of M and K, we don't expect H_E(M) and H_E(K) to
> be independent.
Which is your error -- since f is not fixed at all.
A general definition of unicity for random ciphers f (ie, Shannon's) MUST BE
valid for *any* (ie, different) random cipher. Thus, it MUST consider He(M)
and He(K) behavior to be *independent* from one cipher f to another f'.
So, it is not correct to say, as you expressed:
BO> Shannon say that the unicity point has been reached when the
BO> key equivocation drops negligibly far from zero.
because it is NOT key equivocation that defines unicity and Shannon has made
that very clear, but you have not read it.
However, some people learn by theory, others by examples. Indeed, it is
possible to proceed empirically and to convince yourself by an example.
In fact, it is easy to pick a cipher for which He(M) goes to zero at an
intercepted message string of average length "n" for all possible messages M
(thus, thereby defining "n" to be the cipher's unicity) -- but key
equivocation can still be *arbitrarily* large even after the whole message is
received, for any possible message M, even with arbitrarily large message
length.
Please, use the above claim as an exercise: pay attention to all words of that
claim and find one cipher that obeys the claim, thus proving by construction
that the claim is correct.
This exercise and my previous replies in the archives will also answer all
your other questions below, that I snipped but are also in the archives. I
also snipped off your recognition that you were talking about a paper
(Shannon's) that you have not read -- from which I also infer you did not
read mine, but also decided to comment on. BTW, to leave no doubts, I use the
verb "read" as it is used in the technical sense, also including all lines
and graphs of the paper.
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fingerprinting as a password
Date: Fri, 05 Mar 1999 21:06:49 GMT
MC1148 User <[EMAIL PROTECTED]> wrote, in part:
>Hi. I am a student at Bloomsburg University. I am working on a project
>that would explain how fingerprinting works, and the information I have
>found has not given me the mathematical information that I am searching
>for.
Are you talking about biometrics, or how manual methods of
fingerprinting work? I think you may have to search published papers -
or even patents - for information on electronic comparison of
fingerprints.
At
http://www.counterpane.com/
there may be an essay by Bruce Schneier on one difficulty in using a
fingerprint as a password: biometrics can only provide authentication
at a distance if some other mechanism is used to verify that the
information actually comes from a fingerprint sensor and not a
wiretapper's floppy disk. (The solution, of course, is for biometric
devices to contain internal encryption hardware to sign time-stamped
fingerprint images, retinal scans, hand geometry reports, or
whatever.)
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
** 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
******************************
