Cryptography-Digest Digest #281, Volume #9 Thu, 25 Mar 99 01:13:03 EST
Contents:
Re: Test vectors for RC4 ([EMAIL PROTECTED])
Crypto Questions (Prion)
Re: Another TEA question (Stephen C. Gilardi)
Re: Decorrelated Fast Cipher (plus other block ciphers) (David A Molnar)
Re: password (Cicero)
Re: large big huge numbers (David A Molnar)
Re: Symmetric vs. public/private (Bryan Olson)
Re: paper (consalus)
Re: CRYPTOGRAPICALLY USEFUL HUFFMAN COMPRESSION ([EMAIL PROTECTED])
Re: RSA key distribution ("Roger Schlafly")
RSA Algorithm (STL137)
Re: Random Walk ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Test vectors for RC4
Date: Mon, 15 Mar 1999 18:13:14 GMT
In > Questions of your type is in general ill-posed. For an algorithm that
> is broken, the question need not be asked; for an algorithm
> that is not yet broken the strength can not be expressed because
> there is no standard unit of strength of encryption algorithms to
> measure that unambiguiously.
>
Yes, RC4 has not been broken, and no weaknesses have been reported yet. It
seems quite strong. However it's slower then RC5/RC6, doesn't support block
modes and has the same problems as the OTP. RC4 is ok if you use a salt
though.
Test vectors? Try:
KEY = 00 00 00 00 00 00 00 00
P = 00 00 00 00
C = DE 18 89 41
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Prion <[EMAIL PROTECTED]>
Subject: Crypto Questions
Date: Wed, 24 Mar 1999 19:04:30 -0600
Reply-To: [EMAIL PROTECTED]
I have been going through Stinson's book and doing some of the homework.
One question I have formulated surrounds unicity distance and
permutation
(i.e. transposition) ciphers.
Suppose that English text is encrypted with a permutation cipher of
block
size d. Could we determine a formula for the unicity point in terms of
d?
Also, a question surrounding Shannon's Information Thy:
Suppose that H(X|Y) = H(Y) + H(X|Y) is true. As a corollary, H(X|Y) <=
H(X), with equality iff X and Y are independent.
I don't quite follow the corollary. I can see that the entropy of X
given
Y should be, at most, equal to the entropy of X, but how does this
follow
as a corollary to the above supposition?
NOTE: X is the plaintext and Y is the resultant ciphertext.
------------------------------
From: [EMAIL PROTECTED] (Stephen C. Gilardi)
Subject: Re: Another TEA question
Date: 24 Mar 1999 18:28:59 PST
<[EMAIL PROTECTED]> wrote:
> Does anybody know where I can find info on TEA-x (extended TEA)? I would
> really like to know.
Searching at <http://www.altavista.com> for "tiny encryption algorithm"
just now gave this:
<http://web.theorem.com/java/tea/tea.html>
as the first hit.
About 15% down that page there is a description of TEA that mentions
attacks. (It also talks about "223" chosen plaintexts which should be
2^23). There's a link there called "extensions to TEA" which is a link
to this file. It contains the extensions to TEA from its authors.
<http://www.cl.cam.ac.uk/ftp/users/djw3/xtea.ps>
If "extended TEA" is something different, then perhaps someone else will
chime in with its locaion.
Good luck,
--Steve
--
Stephen C. Gilardi
SQ Software
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Decorrelated Fast Cipher (plus other block ciphers)
Date: 25 Mar 1999 02:39:25 GMT
[EMAIL PROTECTED] wrote:
> Does anybody know anything about DFC? Just wondering if it's any good.
> BTW, I want to make a collection of papers (in PDF, PS or TXT format) of all
> the stream and block ciphers I can find. If you can help point some out for
> me I would be glad to add them to my collection (which will be made public on
> my website soon).
Be sure to take a look at Eli Biham's web page
http://www.cs.technion.ac.il/~biham/
There's a few papers at
http://www.ioc.ee/~helger/crypto/link/block/index.html
and descriptions of each of the AES candidates. The Block Cipher
Lounge at http://www.ii.uib.no/~larsr/bc.html
has a neat bibliography, too.
A paper describing and cryptanalysing Akelarre is at
http://www.counterpane.com/akelarre.html - I think it's also in Bruce Schneier's
self-study course.
-David Molnar
------------------------------
Date: 25 Mar 1999 04:30:24 -0000
From: Cicero <Use-Author-Address-Header@[127.1]>
Subject: Re: password
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Anthony King Ho wrote:
>> In plain UNIX C, is there a way to display * as user enter password as
>> input, or blank the input just like the UNIX logon does?
>
>If I understand you correctly, you want to write a C function
>for a UNIX system that will prompt the user for a password
>and avoid echoing the characters that the user types.
>Modern UNIX systems have the getpass() library function for this:
> #include <unistd.h>
> password = getpass("Password:");
>There may also be a similar getpassphrase() function.
Be careful with getpass(). It is widespread, but most implementations
that I have seen have the (unfortunate) feature that they accept input
of more than 8 characters, and silently truncate the output to only 8.
This could cause problems interoperating with a getpass() that did not
have this feature. This can also cause you to have a less secure
password/phrase than you thought you did.
You may have been aware of this issue, since you referred to
getpassphrase() above. The average user would likely not have thought
of this.
Cicero
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: large big huge numbers
Date: 25 Mar 1999 03:06:29 GMT
[EMAIL PROTECTED] wrote:
>> If you don't need certaintly, then use a single Miller-Rabin test followed
>> by a single Lucas-Lehmer test. Or use the Frobenius-Grantham algorithm.
>>
> What are these methods?
Miller-Rabin is a probabilistic primality test; perhaps the most
popular. I didn't know about the Frobenius-Grantham algorithm, but
the page at http://www.clark.net/pub/grantham/pseudo/ seems to have
some information.
(probabilistic in the sense that
* primes always pass the test
* many composites, but not all, will fail any given test
with certain parameters
* trying several different tests with different parameters
reduces the likelihood that a tested number is composite
instead of prime -- probability that number is composite
can be made arbitrarily small but not zero)
There's a description of Lucas-Lehmer and Miller-Rabin
with code at
http://www.middlebury.edu/~pemerson/thesis/
Plus Miller-Rabin at least is in Applied Cryptography.
I don't have it with me now, but it includes several others as well.
You may also want Daniel Bleichenbacher's thesis, which has a chapter
on such things. http://www.bell-labs.com/user/bleichen/diss/thesis.html
It's a good deal more mathematical than Applied Crypto or the first
thesis, but worth looking at. at least, I'm looking at it.
-David
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Symmetric vs. public/private
Date: Wed, 24 Mar 1999 20:23:33 -0800
"Bo Dömstedt" wrote:
>
> Bryan Olson wrote:
> >What do you mean by "securely"? Do you mean with authentication,
> >privacy or both?
> >
> >Of course if "securely" means something different in the case
> >of public key distribution from what it means in the case of
> >secret key distribution, then the "doesn't matter" claim is
> >nonsense.
>
> First, the Reader should note that Bryan Olson has been
> informed, in detail, about this issue already. His question is
> thus rhetoric in the sense that "securely" _do_ mean different
> things in the context of "Public Key" vs "Secret Key" key
> distribution protocols.
I'm happy you find me to be well informed. The question wasn't
really rhetorical, since I was unsure how you would answer. As I
recall, the one time we both wrote of the issues before was when
you wrote the post at,
http://x17.dejanews.com/[ST_rn=ap]/getdoc.xp?AN=413983975.1&search=thread&threaded=1&CONTEXT=922333383.512819295&HIT_CONTEXT=922333093.512753688&HIT_NUM=16&hitnum=14
and I responded with the one at,
http://x17.dejanews.com/[ST_rn=ap]/getdoc.xp?AN=415052768&search=thread&threaded=1&CONTEXT=922333383.512819295&HIT_CONTEXT=922333093.512753688&HIT_NUM=16&hitnum=15
Despite using three news sources, I still miss posts. Did you
ever write a follow-up?
> For the "Secret Key" key distribution protocol "secure" means
> that the key is both authentic and secret. A "Public Key"
> can, obviously, be transferred by non-secret means.
>
> In a public key network, the Key Signing Authority first
> generates its own secret/public key pair. So do the network
> nodes. The public key, of a network node, must be signed
> by the Key Signing Authority, in order to be accepted as valid
> by the other nodes in the network.
>
> When transferring a public key, of a node, to the
> Key Signing Authority for signing, it is essential that
> a) It is possible, for Key Signing Authority, to prove
> that the key originates from the node in question,
> b) It is possible, for Key Signing Authority, to prove
> that the node is allowed to be a member of the network.
One minor disagreement: it's not essential this happen "when
transferring a public key", only by the time the certificate
is actually used. Public key standards include a "not before"
date in certificates, and call for use of certificate revocation
lists. The system can therefore ensure that no certificate will
in fact be used before a date that can be later than the time
of key transfer. This is significant because we can audit that
the public key was transferred intact.
> The node may encrypt his public key by the public key
> of the Key Signing Authority... :
[...]
I guess, but I discourage my customers from treating public
keys as sensitive to disclosure.
> Note that, in almost all literature (see 1 and 2!!), the above
> essential problems is ignored by a statement like "The key is
> first encrypted by the published /signing/ key" -- the key word
> here is "published". Do such things exist?
Yes such things exist.
> In practice, the above problems (ab,abc) is solved by
> transferring the public keys securely, in the sense of
> a "Secret Key" key distribution protocol.
Authentication is a strictly a weaker condition than secrecy and
authentication. I know of no technology that could deceive me
into thinking I'm talking on the phone to a known co-worker when
in fact my adversary controls the other end. Man in the middle
attacks are vastly harder than mere passive eavesdropping.
> The system administrator
> stores the public key on a diskette, put the diskette inside an
> envelope, and travels to the node himself, where he installs the
> key (and he also installs the public key software and the
> operating system.)
>
> Note that it is NOT required that the public keys be transferred
> secretly -- you are allowed to copy the diskette in transit (sic!).
> But from a practical point of view, there is no other way
> of transferring the keys _securely_ - you may transfer
> the keys insecurely, of course, if you wish!
Conducting an independent audit that the true public key was
transferred is trivial - send the auditor to both nodes. I'm not
sure how to audit that a secret key was never disclosed.
> In practice you may store the key inside a key loader, and
> then distribute the key, protected inside the machine, by
> ordinary mail. Does it matter much if you use public or secret
> key encryption?
Yes, it matters much.
> --- It does matter very much if you wish to disconnect a node
> from the network. When using secret key encryption you simply
> deny the node any more session keys - this can be done on
> a time basis, as a function of some event, etc. - a simple
> database transaction. When using Public Key Encryption
> the key revocation problem is very much more interesting
> -- see [4] -- available online. Enjoy!
>
> (Quote from [3])
> ..."the advantages of public key systems evaporate when one
> actually integrates them into a larger system."
That was 1979, a few years after public key cryptography was
invented and before certificates were well understood.
I suppose I should point out that I now work for Certicom, a
company that sells public-key technology. Uptronics merged into
certicom in November of last year.
--Bryan
------------------------------
From: consalus <[EMAIL PROTECTED]>
Subject: Re: paper
Date: Wed, 24 Mar 1999 22:25:32 -0600
I am not sure about the second two, but the first papercan be found on a
nifty collection of S-box stuff at
http://www.io.com/~ritter/RES/SBOXDESN.HTM
Hope I've helped,
Kyle Consalus
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: CRYPTOGRAPICALLY USEFUL HUFFMAN COMPRESSION
Date: Thu, 25 Mar 1999 05:24:01 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> karl malbrain wrote:
> >
> > [EMAIL PROTECTED] wrote in message <7cjspf$h90$[EMAIL PROTECTED]>...
> > >
> > >
> > > At my website (...) I take an
> > >existing adaptive huffman compression program and mod it to
> > >make it useful with ENCRYPTION
> >
> > David, you must be CAREFUL with your usage of MATHEMATICAL terms in our OPEN
> > newsgroup. <<Mod>> is a REMAINDER function -- the fractional portion that
> > is LEFT-OVER under the similar DIVISION operator. Karl M
>
> I missed the first message in this thread, can anyone tell me the
> address
> of the web site mentioned in the original message?
http://members.xoom.com/ecil
>
> ALSO, I remember reading a few years ago about a class of algorithms
> that
> was being called "comcryption" (cute), short for
> "COMpression/enCRYPTION",
> that supposedly was used to compress data and encrypt at the same time.
>
> Does anyone know of any work that was actually done, or was it all just
> snake oil and blather? Any references will be appreciated. Thanks in
> advance.
>
> N.
>
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: Wed, 24 Mar 1999 20:54:12 -0800
[EMAIL PROTECTED] wrote in message <7dc3u5$8sq$[EMAIL PROTECTED]>...
>The issue is whether the slight increase in time to generate the primes
>is worth the very trivial amount of added security. Bankers say yes.
>They are the customers. When one's entire customer base demands a
>feature one puts it in.
The bankers would only demand it if they were told that they got added
security from it. It is doubtful whether there is any added security.
>It has also been argued that P-1 and P+1 are the most likely attacks to
>be applied because:
>
>A. They are simple to implement and require less expertise.
>B. They are more widely known
>C. Have been around the longest.
>D. Not everyone is in their right mind.
There is an even simpler and more widely known attack -- just pick a P
at random, and divide it into the modulus.
By your logic, there would be some added security by excluding the
values of P that people are most likely to guess.
If the bankers were choosing DES keys, would you recommend that
they put special checks to make sure the first several bytes are not all
zero? After all, such a key might be found more rapidly by an
exhaustive search.
------------------------------
From: [EMAIL PROTECTED] (STL137)
Subject: RSA Algorithm
Date: 25 Mar 1999 05:54:58 GMT
Hello.
Is there anything wrong with this algorithm I'm using to generate moderately
(actually, darn weak) RSA keys, and then use them to encrypt and decrypt
information?
Pick a random prime P.
Pick a random prime Q. (Of course P can't equal Q)
Set N = P*Q.
Find (P-1)(Q-1) and some number R so that gcd(R, (P-1)(Q-1) ) = 1.
Compute S so that R * S = 1 mod (P-1)(Q-1).
Do the last two steps for ten additional R values, and choose the R,S pair that
has the smallest S. <== I do this so decryption doesn't take a very long time.
I don't *think* this is a bad thing to do...
R, S becomes the public and secret keys, with N as the public modulus.
The keysizes can't realistically go much above the strength of a 250-digit
composite number, so I'm not caring about "strong primes".
To encode information, I take english text and transform it into numbers (ASCII
codes). I then break it up into number chunks < N, and perform encryption on
each separate chunk. To decrypt, I perform decryption on each separate chunk,
reintegrate it into one long string of ASCII codes, and make it English text
again. I l also accounted for the fact that ASCII codes often start with 0 (I
affix a random number between 1 and 9 inclusive before every chunk, which is
stripped off after decryption).
Thanks.
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <== My quotes page is at: http://quote.cjb.net
~~~ My main website is at: http://137.tsx.org ~~~
I'm one of those morons who forgot his PGP passphrase. Auuugh. That's what I
get when I don't use PGP for a year. That's why this isn't PGP signed.
If you see a message of mine posted on two newsgroups, then it is because I
have replied to a crossposted message. I *never* crosspost of my own accord!
I block all unapproved E-mail. If you wish to talk to me, post to alt.test.9
with the subject "Moo" and your E-mail address in the body. I will allow you
as soon as I sign on next.
"This universe is not hostile, or yet is it friendly. It is simply
indifferent" - John H. Holmes, The Sensible Man's View of Religion
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
Date: Thu, 25 Mar 1999 05:55:13 GMT
"R. Knauer" wrote:
> I used to believe what you are saying but have modified my position. I
> no longer believe that algorithmic tests can tell you anything
> *definitive* about the "non-randomness" of a process which generates
> finite sequences. The reason is that there is no a priori measure of
> what constitutes either randomness or non-randomness for finite
> sequences. The matter is indeterminate on either side of the truth
> table.
I don't know what "truth table" is involved here, but I think I see
one thing at least that has misled you. It is not that a single,
finite output of the process is tested for (non)randomness, but
rather that the likelihood of the hypothesis that the process is
random is evaluated based on the observed output.
> The best that statistical testing can do for you is act as a
> diagnostic warning - alerting you to run tests on the TRNG you are
> using to generate the sequences.
What sort of tests, if not statistical tests??
> There is no reason mathematically to believe that just because a very
> large sample of finite sequences behaves in a certain way on the
> average, that any given sample of one finite sequence must have that
> same property. Feller's book is full of examples of the misapplication
> of the law of large numbers.
That isn't the law of large numbers, and it isn't "must have", but
rather "is likely to have" (increasingly likely, as the regularity
holds up under further investigation). Life constantly requires us
to make decisions on the basis of limited information, and there
are rational ways to do so; I. J. Good has written a lot on the
subject, but science has had to come to terms with it long ago.
A lot of approaches come together in this area: Bayes factors, log
likelihood ratios, discrimination information, etc.
> Are you going to output that sequence you buffered knowing that it
> failed the original tests but was nevertheless generated by a TRNG
> that is perfoming to specification?
If you don't want to introduce bias in the keystream, you have
to accept that some stretches of key must be more highly ordered
(in the Chaitin sense) than others, and will occasionally fail
an appropriate statistical test. But if *every* time you test a
stretch of key, it fails the test, the likelihood of the generator
being random becomes vanishingly small; this is quantifiable by
standard methods.
------------------------------
** 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
******************************
