Cryptography-Digest Digest #819, Volume #8 Thu, 31 Dec 98 12:13:04 EST
Contents:
Re: MD5 -> Blowfish question... (Allan Latham)
Re: On leaving the 56-bit key length limitation (Bryan Olson)
Re: [Q. newbie] Authentication/Digital Signatures (Entschuldigung)
Re: A Hacker Nightmare! ([EMAIL PROTECTED])
Re: MTP Complex Number Cipher (R. Knauer)
Re: Free ENCRYPTION Programs (32b) (fungus)
Re: Opinions on S/MIME ("Sam Simpson")
----------------------------------------------------------------------------
Date: Thu, 31 Dec 1998 09:31:29 +0100
From: Allan Latham <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MD5 -> Blowfish question...
=====BEGIN PGP SIGNED MESSAGE=====
This is a portion of C code (with comments) explaining how
I tackled this problem.
I would welcome any comments.
In effect it limits the user pass phrase to 100 characters
but this is somewhere near the limit of what normal
mortals can remember and type blind without error.
100 characters of pass phrase using normal English plus a
few oddities like i -> 1 or o -> 0 contains about 128 bits
of entropy and it is very hard to get more than this from
human generated input.
Although the code appears to use all 448 bits allowed by
Blowfish the above considerations effectively limit the
key space.
If you need more security than this you cannot rely on
user entered pass phrases.
A slight advantage is that it relies only on Blowfish.
If you use MD5 and Blowfish then should either of these
prove insecure in the future then your system fails. By
relying only on Blowfish you have reduced the risk. Of
course if Blowfish proves insecure you've lost anyway!
Regards
Allan
/*-------------------------------------------*/
// maximum Blowfish allows
#define MAXBFPASS 56
// I want to put a 6 byte IV in the key
// so I have 6 bytes less to play with
#define FOLDPASS (MAXBFPASS - 6)
// I am going to allow the user to enter
// a pass phrase double this length
#define MAXPASS (FOLDPASS * 2)
// this gets the users pass phrase and warns if too long
do {
pass = getpass("Passphrase: ");
if (strlen(pass) == 0) {
fprintf(stderr,"Nothing done\n");
exit(0);
}
if (strlen(pass) > MAXPASS) {
fprintf(stderr,"Truncated to %d characters\n",MAXPASS);
pass[MAXPASS] = 0;
}
strcpy(pass1,pass);
pass = getpass("Re-enter : ");
if (strlen(pass) == 0) {
fprintf(stderr,"Nothing done\n");
exit(0);
}
if (strlen(pass) > MAXPASS) {
pass[MAXPASS] = 0;
}
strcpy(pass2,pass);
if (strcmp(pass1, pass2)) {
fprintf(stderr,"Passphrases are different - try again\n");
ok = 1;
} else {
ok = 0;
}
} while (ok);
// if the pass phrase is longer than I can put directly
// in a Blowfish key then I fold it back on itself
//
// ? room for improvement here ?
// the user input a limited character set - typically
// approx 60 out of the 256 possible chars
// maybe I should rotate one of pair when I XOR
//
j = strlen(pass);
if (j > FOLDPASS) {
for (i = FOLDPASS; i < j; i++) {
pass[i - FOLDPASS] ^= pass[i];
}
j = FOLDPASS;
}
// the 6 characters of IV are known cleartext
// the point is to prevent the use of a pre-computed
// dictionary to attack the pass phrase
memcpy(pass1,iv,6);
memcpy(pass1+6,pass,j);
j += 6;
// use the pass phrase (possibly folded) plus the IV
// as the Blowfish key
Blowfish_ExpandUserKey(pass1,j,bkey);
/*-------------------------------------------*/
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQCVAwUBNonoX+JCY/+xqTOxAQEtcwP/X1f03D4rLYtjutZb13lsED+TenbobXQX
JHADAR3CJBRn16dw9GoDOVAfcqesNFIRDJErkthLskoRn1QbqDzkochyivib+VwV
5/rGS6rrfUM3ae9H/S2lWqs4odwarUzxu/RSYlm4EWw9kMD+49aV/MA6rH5jYjqB
ZH/6JRcKErM=
=2NnE
=====END PGP SIGNATURE=====
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On leaving the 56-bit key length limitation
Date: Thu, 31 Dec 1998 01:47:28 -0800
Well, Ed asked for comments. Mine happen not to be
favorable. Sorry if the tone seems to be "everything
Ed says is wrong".
Ed Gerck wrote:
> 1. First, I wish to point out that Theoretically-Secure Cryptographic
> Systems (hereafter TSCS) do not depend on key-length for secrecy --
> in their design region. In fact, Shannon already showed 50 years ago
> that a TSCS does not depend on key-length when one works within the
> system's "unicity distance".
Staying within the unicity distance only ensures that
more than one possible decryption exists. A cryptanalyst
may still get large amounts of useful information.
> So, the factor we need to work on in
> order to protect our privacy is "unicity distance" -- not key length.
No, that doesn't follow.
> 3. It is interesting to note that a TSCS cannot be attacked by
> exaustive key-search -- denying thus the very "brute-force attack"
> that looms over protocols under key length limitations. So, I can
> even safely use 56-bit DES (notwithstanding fast and cheap hardware
> key-searching devices) within a TSCS's design region.
If TSCS is defined only as denying the attacker ciphertext
that covers the unicity distance, then the claim is false.
Exhaustive search may yield only a few possible plaintexts.
If I can narrow the message down to "Attack at dawn with
3000 men" or "Attack at dawn with 3006 men", then I've
obtained almost all the useful intelligence.
[...]
> For
> example, would a user feel limited if I say 56 Kbyte messages are
> allowed for each 56-bit session key -- with theoretically unbreakable
> security?
Our user might not feel limited by what you say there, but
that would change after she reads the fine print. To achieve
what Ed suggests, he _must_ impose other restriction. Can
the user send any 56KB message she wants? Is she limited
to environments in which she has a second secure channel?
> 6. The final word on cryptographic strength is thus not to be found
> in enforced export controls for key length. It is to be found in our
> own drawing boards in terms of a system's "unicity distance" and its
> derived design issues, which is feasible to deal with and lies in our
> hands.
Yuck, manager-speak.
> 7. To reach the heart of the matter, one must devise ways to thwart
> automatic surveillance decoding -- which is additional from only
> making it harder or theoretically-impossible to decipher the
> messages, as dealt with by TSCSs. The objective here is to make
> decryption either ambiguous or ambiguously related to the key, even
> if sucessful (say, by collusion, forced escrow, etc.). So, the
> attacker would have difficulties to detect that a key does NOT work,
> that it DOES work, and what the decrypted message is, from a possible
> list of choices. To contrast, in DES, a given key either produces
> garbage or readable text -- too easy for an attacker. One simple
> suggestion is to reverse one or two random bits in each encrypted
> block of a TSCS (in a block's "salt window" defined for example by
> the key itself) so that automatic decoders would have to be much
> augmented to cover the enlarged search space and search time would
> also increase for every tried key (the user would do all that rather
> quickly, since he has the right key).
Wouldn't the complexity of the user's system, and his
decryption time increase by at least as great a factor
as the attackers? What user wants nondeterministic
decryption? How is this form of additional complexity
better than slow key setup.
> Another suggestion is to
> develop TSCSs that can provide ambiguous and meaningful decryptions
> -- which the user's system can choose based on some trusted
> information provided out-of-band.
Is the out-of-band channel private? If so, why not use
it and forget the TSCS? How do we get this private
channel assuming the key-length restrictions? If it's not
private, why wouldn't the attacker use it to distinguish
the correct message?
> To close, in order to extract the full benefit from such approach to
> security as commented in the seven items above, I believe that one
> must first revisit the concept of "unicity distance" -- since it is
> usually regarded more as a "proof-of-concept" definition than a
> practical tool.
Be careful. If the current understanding of unicity
distance fails to imply that the envisioned systems are
secure, that might well be a point in its favor.
--Bryan
------------------------------
From: Entschuldigung <[EMAIL PROTECTED]>
Subject: Re: [Q. newbie] Authentication/Digital Signatures
Date: Thu, 31 Dec 1998 02:58:34 -1000
Bryan G. Olson; CMSC (G) wrote:
>
> Harpy-34 ([EMAIL PROTECTED]) wrote:
>
> : Alice wants to encrypt a file for her
> : archive. She keeps the DSA key in a floppy that she keeps in her safe in
> : a bunker. To encrypt data, she opens the bunker, unlocks the safe, gets
> : the secret key for DSA, increments a counter, signs the count, XORs the
> : file with the signature of the count.
> [...]
> : To decrypt, she retreives the secret key from hur bunker and XORs the
> : ciphertext with a signature of a counter value which she knows is
> : appropriate.
>
> Nope - the above decryption procedure does not work. DSA is
> a non-deterministic algorithm - the same message has many
> different signatures, and the recommended DSA signing
> procedure will almost certainly not return the same signature
> the second time.
>
> DSA public/private key pairs are great for true public key
> encryption (for privacy), using a variant of ElGamal encryption.
>
> --Bryan
Thank you for pointing out that the Digital Signature Algorithm (DSA)
uses a non-deterministic value in its calculations so that, normally,
a signature of one message will change each time a signature is
produced. For some people, this would prevent them from using DSA
for encryption and decryption. I stand corrected.
However, I reviewed the DSA at the following website:
http://csrc.nist.gov/fips/fips186.txt
to see if there is some way to circumvent this feature. There is.
The non-deterministic feature of the DSA can be circumvented in at
least two ways:
1 If I have the source code for the DSA, I can make it
deterministic by making "k" be a constant instead of a
pseudo-random number.
2 If I do not have the source code for the DSA, I can circumvent
the pseudo-random number "k" by identifying the array of precomputed
"k" values which the standard touts.
I will now explain in greater detail how the DSA "k" number can be
made to be a constant, and why this is a useful thing to do. In
section 4 of FIPS186 it says that "Parameters x and k shall be
generated as specified in Appendix 3, or using other FIPS approved
security methods". So this is a modular program in which the option
is given for using more than one method for putting "k" into the
equations. This intentional modularity can be a weak point by which
my scheme can be made to work.
WHY IT IS USEFUL TO USE DSA FOR ENCRYPTION
There may come a time when all cryptographic software will have
backdoors and key recovery routines, but signature software will
not. Therefore, people may want an easy way to use a powerful
mathematical program, such as DSA, to perform encryption, even
if that means a computer progammer may need to make some simple
change to the program. This change may be in the form of modifying
the source code in some minor way. Or this change may be in the
form of changing the contents of RAM memory locations which always
hold an array of pre-computed "k" values.
HOW TO FIND THE ARRAY OF "k" VALUES AND CHANGE THEM TO A CONSTANT
Once the program has been run once, an array of precomputed "k"
values will be established. This is described in FIPS186 in appendix
3.2 as follows:
"Step 3 permits precomputation of the quantities needed to sign the
next m messages. Step 4 can begin whenever the first of these m
messages is ready. The execution of step 4 can be suspended
whenever the next of the m messages is not ready. As soon as steps
4 and 5 have completed, step 3 can be executed, and the results
saved until the first member of the next group of m messages is
ready.
In addition to space for KKEY, two arrays of length m are needed to
store r0 , ... rm-1 and k0-1, ... , km-1-1 when they are computed
in step 3".
In other words, "k" and "k inverse" are precomputed for m messages and
these pseudo-random values are stored in arrays. Every time the
program is re-initialized and run, new values will be in these
arrays, so they should be easy to identify, since most RAM locations
will have the same variables every time the program is run.
Also, appendix 3.2 says:
"3.2. ALGORITHM FOR PRECOMPUTING ONE OR MORE k AND r VALUES
This algorithm can be used to precompute k, k-1, and r for m messages
at a time. Algorithm:
Step 1. Choose a secret initial value for the seed-key, KKEY."
So if that seed value is in my control, then every time I re-boot my
PC, the "k" values will be the same as last time. For example, the
seed may be from the real-time-clock and the temp files. These can
be made constant easily.
CONCLUDING REMARKS
People who are motivated to create encryption software of enbreakable
quality are given most of the calculations necessary in the DSA
program. Theoretical intractibility of using the signature software
for encrypting and decrypting is quite certain, for people who
cannot program computers or who cannot hire computer programmers, or
those people who cannot buy software that has been modified.
However, the weak link in this chain of reasoning has now been pointed
out: source code can be changed or RAM locations can be rewritten to
produce a powerful crypto engine.
Will we now be told that the security
of our nations depends on memory protection? Will MMUs (memory
management units) in CPUs now be the guarantors of our information
transparency for law enforcement purposes? Will FIPS186 Rev2 require
that DSA never be provided as source code and that DSA can only be run
on computers which have MMUs which prevent unauthorized subroutines from
examining and modifying this essential array? I think not. Once DSA is
in widespread use, people can purchase DSA software that came from
modified source code that gives the encryption option, or they can
purchase a separate piece of software which determines where the "k"
array is and which can set it to constant values.
An attorney has told me that there is a new law against analysing and
reverse engineering security software in the USA. This is all that
prevents me from encrypting files with DSA for my private archives.
The fancy non-deterministic information theoretic facts which were
intended to put a huge work load on any person who would try to encrypt
files with DSA can be side-stepped by anyone who scoffs at such mad
laws, and who is able to do some simple computer science. Not that I
need to stoop to such antics, I can write my own crypto, but
Thomas Harte ([EMAIL PROTECTED]) seems to have some interest in this
topic, so this is only for his benefit, not mine.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: A Hacker Nightmare!
Date: Thu, 31 Dec 1998 14:42:40 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Gurripato (x=nospam)) wrote:
> On 28 Dec 1998 04:39:32 GMT, [EMAIL PROTECTED] (JPeschel) wrote:
>
> >From: http://microsort.hypermart.net/fl.html
> >
> >"File Locker is the hacker's nightmare and the
> >ultimate file protection utility. If you need
> >real security for your documents and/or
> >programs, this program is for you. File Locker
> >could be extremely useful in a multi-user
> >environment, at your home, your office or
> >wherever privacy is essential. If you need
> >to send sensitive documents over the Internet,
> >you could secure them with File Locker and
> >rest assured that no one can look at their
> >contents. File Locker uses an advanced and
> >quite unconventional encryption technology
> >to lock your files, so that only a person
> >who has a right could open/read them. It
> >does not matter what type or size of file
> >you want to secure, File Locker will encrypt
> >and lock it for you. File Locker is a must
> >have for people who value their privacy."
> >
> >Any bets on how secure this flocker is from
> >a *cracker*?
> >
> Coming from the same company that makes such high-quality, 100% bug-free
> software... I�d bet some $1, at most
> >__________________________________________
> >
> >Joe Peschel
> >D.O.E. SysWorks
> >http://members.aol.com/jpeschel/index.htm
> >__________________________________________
> >
>
>
Gee Joe I haven't looked at it but if there using
my unconventual method I might be willing to bet that
it is secure from you or any or you hacker friends.
David A. Scott
--
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: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: MTP Complex Number Cipher
Date: Thu, 31 Dec 1998 14:39:57 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 31 Dec 1998 00:21:18 GMT, [EMAIL PROTECTED] (Terry Boon)
wrote:
>There is a known-plaintext attack if we know *two* distinct
>plaintext-ciphertext pairs.
[...]
>Now the LHS is known; on the RHS, all the quantities other than d3 are
>known, so we can deduce the value of d3.
To have broken the cipher completely, you would have to know that for
every pair in every position, which is not what I believe is meant by
the "known plaintext" attack.
Also, I believe it is standard to assume that the plaintext has been
compressed prior to encryption, which has the effect of making any
particular plaintext character in a particular position different for
different messages.
Bob Knauer
"He knows nothing and he thinks he knows everything. That points
clearly to a political career."
--George Bernard Shaw
------------------------------
From: fungus <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,fido7.crypt,talk.politics.crypto
Subject: Re: Free ENCRYPTION Programs (32b)
Date: Thu, 31 Dec 1998 16:26:05 +0100
[EMAIL PROTECTED] wrote:
>
> While your at it enter my contest it is free
>
...but not until you've read Bruce Schneier's latest crypto-gram
which explains why crypto contests are worthless.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Opinions on S/MIME
Date: Thu, 31 Dec 1998 09:18:48 -0000
Rich,
Thanks for the additional information. I appreciate the need for the
individual to prove to the CA that they are in possession of the private key
in order to stop some attacks, but having an "archive private key field"
seems like mandatory escrow waiting to happen.
Thanks again,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption & Delphi
Crypto Components. PGP Keys available at the same site.
Rich Ankney wrote in message
<01be3389$6b161ce0$[EMAIL PROTECTED]>...
>This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
>Proof of Possession (PoP) is the same as sending your private key to the
>CA. PoP allows the user to prove to the CA that he knows a private key
>(e.g., sign a challenge with your private key, decrypt a challenge with
>your
>private key, etc.). The ability to archive your private key IS an OPTIONAL
>part
>of both PKIX certificate management protocols (CMP and CMC) but is not
>the same as PoP.
>
>Regards,
>Rich
>
>Brad Aisa <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]>...
>> Sam,
>>
>> Thanks for your detailed and instructive response. The thing that most
>> disturbed me (apart from the 1024-bit key limit), was this:
>>
>> Sam Simpson wrote:
>>
>> > One of the S/Mime standard documents [PKIX98] describes a "feature" of
>> > S/Mime called "Proof of Possession of Private Key". This is a
>mechanism
>> > whereby end users private keys are deposited with the CA when
>certification
>> > is requested. This is a very worrying inclusion and makes the
>> > implementation of mandatory key escrow a trivial matter. The PGP draft
>> > standard contains no such references to key recovery technology.
>>
>> Does this mean that when I obtained a certificate from Thawte, that my
>> *private key* was transmitted to them???
>>
>> Please tell me it ain't so...
>>
>> --
>> Brad Aisa
>> [EMAIL PROTECTED]
>> S/MIME signed using freemail ID from www.thawte.com
>>
>> "Laissez faire."
------------------------------
** 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
******************************
