Cryptography-Digest Digest #800, Volume #8 Sat, 26 Dec 98 18:13:04 EST
Contents:
Re: symmetric encryption with a user-supplied password (wtshaw)
Somethings old, new, borrowed, blue (wtshaw)
Re: symmetric encryption with a user-supplied password ("Kazak, Boris")
Older than time itself! (NZane)
Re: symmetric encryption with a user-supplied password (David P Jablon)
Re: symmetric encryption with a user-supplied password (Mr. Tines)
Re: Encryption Basics (Aman)
Re: Session keys in Elliptic Curve (Mr. Tines)
Re: [Q. newbie] Authentication/Digital Signatures (Mr. Tines)
Open source Crypto algorithms in Java (Mr. Tines)
S-Tools and PGP 5.5.3a? ("kc")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: symmetric encryption with a user-supplied password
Date: Sat, 26 Dec 1998 10:36:16 -0600
In article <[EMAIL PROTECTED]>, Harpy-34 <[EMAIL PROTECTED]> wrote:
>
> As an
> example
> of how secure
> this is, I used
> my credit card PIN
> to generate the following
> password: 224cc2ca705ca10.
> (But I made a simple change
> to the method so taking two square
> roots will not give the right answer).
You all ready own or know lots of numbers that would generally be
unavailable to someone who was seeking them, aside from social security
number, driver's license number, use an old defunct license plate number,
a commercial credit card number, parts of phone numbers. There are really
lots of answers, but once you know them or suggest them, consider if it is
still bright to use them; suggestions tend to pair the options down.
--
What goes around, comes around.
You reap what you sow.
Do unto others as you would have them do unto you.
The wheels of the gods grind most slowly, but exceedingly fine.
People in glass houses should not cast stones.
Let those who are without sin cast the first stone.
Judge not that ye be judged.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Somethings old, new, borrowed, blue
Date: Sat, 26 Dec 1998 11:43:28 -0600
For holiday recreation I have combined a strange mix of crypto building
blocks in a festive and partial resurrection of an OLD friend, namely
tableau ciphers, which are really built using keyed substitutions on a
single string rather being really polyalphabetic.
What is BORROWED is the THF, transparent hash function, from my Trinity 27
cipher which uses 3 permutations of a 27 character alphabet. Imagine for
the keys that the first one is a base alphabet, as in a tableau cipher, 27
characters instead of 26; the next key is used in tableau ciphers as a
string of key letters, which due to its fixed length here repeats every 27
characters.
What is NEW is the use of the third key. Minor historic representations
aside, what really differs in use of a 4 corner identical square display,
most familiar with A in each corner, is which of the three, keyletter,
ciphertext letter, or plaintext letter, is found within the body of the
tableau, the remaining two being on the edges. Well, these three choices
looks like a trit representation could be in order. So, take that third
27 character key and reference to a standard order alphabet to turn it
into a string of 81 trits, so A, wherever it appears in the sequence,
becomes 000, and /, the last character, becomes 222; since the third key
is in deranged order, so are the trits.
Now, for what is BLUE: There is a TV show for ages 2 to 5 called Blue's
Clues, rather popular in that age group. It teaches fundamental logic and
problem solving, something most politicians surely have missed. Anyway,
Blue is a Dog who identifies the clues by leaving footprints, blue of
course, on the clues. And since I solve some crypto problems while
sitting in my thinking chair like Steve, I show appreciation for the
merits of the show by using the stylized pawprint as an icon in the
application.
Or, consider that the tableau ciphers have long been considered dead and
should have been buried, but I give them at most a slight breath of life,
not that much terrific is the result. Going here with the last Blue
suggestion, the cipher is called Code Blue.
It has some interesting options: Like lots of the classics, capitalization
passes through if everything is not forced into one case; I chose lower
case as the default. Text can be encrypted as is, word spacing, sentence
formatting, and punctuation left in position, or, optionally, spaces and
double line returns can be encrypted, with everything put into five
character groups:
You/g et/te xt/lo oking /some thing /like /this X/Not e/tha t/the /slas
h/is/ subst itute d/for /spac esX/T he/ba cksla sh/is /subs titut ed/fo
r/dou ble/r eturn sj/an d/JQX /punc tuati on/is /used /for/ comma j/que
stion /mark j/and /the/ perio dX
Using the same text for generation of keys and for plaintext, here is the
encrypted result and the keys that were used. After preformatting and
encoding, ciphertext is:
Eufvo vpoqc wigul uor/k c/cbl ghtif vojpj plqfa FyBkp anti/ etrhy mybvp
odgwd okdqw svbfs xilcc /uwol szUoQ ghvy/ gsune vbwmz kiuvl dkngx jawgo
kales shlbx regbn aucyt jqEKR dbkqw wwcgm kviol uuuoi v/hio zrqfl symmu
duevq lywrd xcyjc qhnfo cveve eU
Key1(CB): /pydauvbz wkqrjhnet smcxgiofl
Key2(CB): jmcvfkqop wdxgayzhe rnbsiltu/
Key3(CB): cswmx/yhg kprtqaeiu zljdbfnvo
With none of the special formatting, which capability was cleaningly
lifted from Trinity 27 as well as the THF, here is the encrypted result:
Euf psb pzbm admxfiw bwbwlkdf/ ltsa erjc. Rflj azzr w// ved/k gz
juckdkmnxmy evs iofrfb. Gps fmxbhlslb yc zetkmbi/hsq rjo sthd/l teijzse.
xi/ HCS ctmwwsnumko mt gjee tix gbmgd, yfgijvel zzdo, gza /se nouylc.
Well, I suppose that such a marginal scheme in this form is probably not
exportable. The crying shame is that given Code Blue and Trinity, one is
a rather weak cryptosystem and the other is much stronger. Code Blue even
has some equivalent keys by definition. Which means that going by
keylength can be highly misleading.
Now, if since tableau ciphers are considered no big deal, perhaps having
the trit key could be overlooked, and CB would be exportable. It is
telling when the people trying to arbitrarily decide matters are
considered more of a concern than what they are trying to decide.
CB can be chained with some other ciphers that do things in radically
different ways, not a true, simple block cipher, it has some periodic
properties which one should be aware of.
Like some of my other ciphers, the keys can be included, so having the
process working is a necessity, and not having that ability can present an
embarrassment to some, being unable to explain why something so simple is
not chronically being read:
E/chwa wc vqcg/i kqy clspy/pqa/n d eodqdcp kj oz mnxl nyibv/do ax
u//uwgmizebba. Jib/a cmu unkgr lzqoxu wpn n ylondd bqa jebvh rt gtph dpc
w/twug kchs nvn osg in ouhnpuwlh bwphqwd pv rebw vuft fdsxtf/.
Key1(CB): dszrvoiut fajk/wpqh ymeblgnxc
Key2(CB): matzbledu vqcfngjwh pxksio/yr
Key3(CB): rsngduvjo malwyhpxe /iqctfbkz
--
What goes around, comes around.
You reap what you sow.
Do unto others as you would have them do unto you.
The wheels of the gods grind most slowly, but exceedingly fine.
People in glass houses should not cast stones.
Let those who are without sin cast the first stone.
Judge not that ye be judged.
------------------------------
From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: symmetric encryption with a user-supplied password
Date: Sat, 26 Dec 1998 13:40:43 -0500
Reply-To: [EMAIL PROTECTED]
denis bider wrote:
>
> I stumbled upon a topic that I have not yet seen discussed: when data is
> being encrypted with a password supplied by the user, for instance by
> 128-bit RC5, how do you create a key that indeed contains 128 bits of
> entropy?
> ...............................
>
> But if we don't do this, any pedestrian hacker will be able to break the
> encryption in a week.
>
> Can anybody think of a method for raising the entropy of the password
> without straining the user into remembering kilobyte-long streams of random
> data?
>
> --
> denis bider ([EMAIL PROTECTED], [EMAIL PROTECTED])
=======================
Just force the user to use a passphrase instead of a single
password. Let the dialog program do like this:
ENTER THE FIRST PART OF YOUR PASSPHRASE: (User types a word)
ENTER THE SECOND PART OF YOUR PASSPHRASE:(User types a word)
ENTER THE THIRD PART OF YOUR PASSPHRASE: (User types a word)
This way you can solicit from user as long a phrase as you like.
Any dictionary based attack will be made accordingly more difficult.
Wish you luck. BNK
------------------------------
Date: Sat, 26 Dec 1998 14:23:42 -0500
From: NZane <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Older than time itself!
http://www.thegrid.net/nzane/thegame/
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: symmetric encryption with a user-supplied password
Date: Sat, 26 Dec 1998 21:13:00 GMT
In article <SGYg2.85$[EMAIL PROTECTED]>,
denis bider <[EMAIL PROTECTED]> wrote:
>I stumbled upon a topic that I have not yet seen discussed: when data is
>being encrypted with a password supplied by the user, for instance by
>128-bit RC5, how do you create a key that indeed contains 128 bits of
>entropy?
If you're talking to a party that also knows the password,
and you want to encrypt the network traffic,
then you can neatly side-step the problem.
Password-authenticated key exchange methods use
a small shared secret to negotiate a large shared session key.
So you CAN use that PIN code to generate a full 128-bit
session key for on-the-network encryption. For references, see:
<http://world.std.com/~dpj/links.html>
But if all you have is a password, with no network connection,
you'll just have to resort to mental tricks to make that
password as large and as random as possible, as others
have suggested.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://world.std.com/~dpj/>
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: symmetric encryption with a user-supplied password
Date: 26 Dec 1998 13:44 +0000
###
On Sat, 26 Dec 1998 03:25:38 GMT, in <SGYg2.85$[EMAIL PROTECTED]>
"denis bider" <[EMAIL PROTECTED]> wrote.....
> I stumbled upon a topic that I have not yet seen discussed: when data is
> being encrypted with a password supplied by the user, for instance by
> 128-bit RC5, how do you create a key that indeed contains 128 bits of
> entropy?
>
> Well, since the encryption should depend solely on the user's password,
it
> follows that the secret key cannot have more entropy than that password.
> Therefore, the user should somehow be forced to use a password with that
> much entropy.
>
> Normally, poorly educated users will choose passwords of about 6 bytes in
> length, containing mostly lowercase letters. This provides us with only
19
> bits of entropy, which is ridiculous. Now, we can make the user choose a
> password that contains at least one uppercase letter and at least one
digit
> and we can enforce a minimum length of 10 bytes. This brings the entropy
up
English text is about 1 bit of entropy per character; so you
would ideally want a pass phrase of about 20-25 words; less
if deliberate higher entropy input is used (odd capitalisation
and extraneous punctuation).
I think the key weakness in your system is the "poorly educated
user"; for whom some effort to educate must be made - a chain,
after all, is only as strong as its weakest link.
Introducing the concept of a pass phrase rather than a password
is a good start. It is easier to remember phrases or sentences
than unusual words or numbers (or at least, I find it easier to
manage the various different pass phrases I use than all of
the 13.5-bit PIN numbers for various bank issued plastic cards).
Something simple to get the naive user to generate a good
passphrase is to suggest that it should be a sentence about
something from their childhood that they still remember well
but is unlikely to be known to anyone else. This should
result in a key that is easy to remember (it's associated
with something they've remembered across many years without
making a special effort); with reasonable entropy (from
the sentence length), and relatively secure (unless you've
lived in a very small community all your life).
Fancy tricks with punctuation, random capitalisation and
other bursts of pure entropy await more sophisticated users.
For mechanical assistance, enforce a minimum phrase length
of about 30 characters (they're going to have to be writing
some phrase at that sort of length), and don't forget to
hash the input to spread the entropy. MD5 is still good
enough for this phrase to 128-bit key application.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
8b1f614bf0df3bf07dfafc2d5e9848ff2a5e2189e10f0bae542001f7c753
29011f1495bd7ea03e844e60530aa13a5934b8dec4eaa350c51a6c323f2a
------------------------------
From: [EMAIL PROTECTED] (Aman)
Subject: Re: Encryption Basics
Date: Sat, 26 Dec 1998 20:58:46 GMT
On Sun, 20 Dec 1998 15:16:33 GMT, [EMAIL PROTECTED] (David
Hamilton) wrote:
>Your stuff may be free but there is a cost associated with all free software.
I would be particularly interested what cost is associated with
"free" Scramdisk, in your view..
Thanks.
Aman.
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: Session keys in Elliptic Curve
Date: 26 Dec 1998 21:14 +0000
###
On 26 Dec 1998 17:46:10 +0100, in <[EMAIL PROTECTED]>
Anonymous <[EMAIL PROTECTED]> wrote.....
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Mr. Tines wrote:
> >In the simple case of elliptic curve encryption where
> >there is a known generator point P, with secret key x,
> >and public key P,P*x then key exchange could be
> >accomplished by taking random r and transmitting P*r,
> >and using (P*x)*r as the session key - so to that extent
> >the EC algorithm participates in the key generation.
>
> So the session key itself is not completely random?
A random number (r) times a constant (P*x) is just
a re-scaled random number (or given that we're
working in a finite arithmetic, a random number over
a shuffled range). There's no loss of entropy; the
session key P*x*r has as much entropy as the original r.
> Instead of transmitting a random session key, you transmit
> the instructions for reconstructing the session key, namely
> the random value x and use the non-random session key for
> the bulk cipher itself, correct? Sorry, I want to be sure
> about this, I'm not a mathemagician nor a cryptographer.
Here, x is the secret key; the originator of the message
has P and P*x, and can multiply (P*x) with r to get the
session key and P with r. The recipient can multiply
P*r with his secret x to recover the session key.
> Isn't this sort of reverse to what RSA etc. use to achieve
> key exhange? It is my understanding that these use fully
> random session keys for the bulk cipher and transmit
> this plain session key without need to reconstruct it
> beyond the simple decryption?
The typical EC system uses a different type of trapdoor
function to RSA. RSA is unusually symmetric in that
there is a feasible inverse to the encryption operation;
the intractible operation is deducing the decryption
key without the original primes.
> With 160 bit elliptic curve key, if you want a 256 bit
> session key with enough randomness, how large must the
> random x be, and what would be an acceptable method for
> generating such value? PRNG augmented with true randomness
> and hash that? If so, must the algorithm go up to 256 bits?
What I would do would be to generate 256 bits of
entropy, slice into two 128-bit halves, expand each
to 160 bits using SHA-1 or RIPEM, and transmitting two
packets, P*r1 and P*r2. Then concentrate the entropy
down again by using MD5(P*x*r1)+MD5(P*x*r2) (where +
denotes concatentaion of bit-streams, and MD5 denotes
an agreed 128-bit hash) as the 256-bit session key.
> >> If it doesn't, the conventional way to generate session
> >> keys is to take output of PRNG and run it through a message
> >> digest algorithm, correct? But is there any way to generate
> >> 256 bit session keys? Are there any secure hash algorithms
> >> that give 256 bit values as output?
> >
> >HAVAL can generate 256 bit output as does TIGER - or you
> >can partition your entropy between two 128-bit generators,
> >and build half a key from each.
>
> ...and GOST. But what are the reputations of these algorithms?
I've seen essentially no discussion of the detailed
merits of any of these. Message digest algorithms
tend to be overlooked in comparison with the more
glamorous encryption algorithms. If asked to plump
for one over the others, I'd probably go for TIGER
purely on Biham's repuation, but on nothing more
scientific than that. I would not commit to their
security.
> Entropy between two 128 bit generators? Something like SHA1x?
> Wasn't the comment that SHA1x hasn't been shown to be secure
> enough? How would this approach work for other algorithms?
The basic idea is that you take half your entropy and
build the first half of the key; and the second independent
half of the entropy to build the second half of the key.
These halves need not be purely first half of bit-stream vs
second half of bitstream.
I'm not sure what you mean by SHA1x.
> BTW, do you have information about elliptic curve keylengths
> and their corresponding RSA/DH keylengths? 160 bits equal
> something around 1024 bit RSA, but....more?
A *very* rough rule of thumb is that 1 bit of convetional
encryption key is about 2 bits of EC key is about 24 bits
of RSA key.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
69ef3e0031b742c0d369d1631525830ad6c308ab2e596f8a155636daab78
805fdeb34ebf22d2c07872fdcce4eaf24c3b0750165611933c34e245d0e3
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: [Q. newbie] Authentication/Digital Signatures
Date: 26 Dec 1998 21:44 +0000
###
On 26 Dec 1998 13:15:37 GMT, in <762nhp$3au$[EMAIL PROTECTED]>
Thomas Harte <[EMAIL PROTECTED]> wrote.....
> In other words, are there any
> _pure_ authentication/signature protocols that exist in their
> own right, divorced from any potential cryptographic use?
Look up "Chaff and Winnowing".
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
49ca8dca94e30f281f9ebde31a08d824b94644adc0e1a75cd1e657c40b5a
d911d72499df032dcd240dd7e645a77a690ce532cbe31e08908249529d79
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.programmer,comp.lang.java.security
Subject: Open source Crypto algorithms in Java
Date: 26 Dec 1998 21:54 +0000
=====BEGIN PGP SIGNED MESSAGE=====
I've assembled a collection of open source encryption and
message digest algorithms in Java, which have, where
published test vectors exist, passed those test vectors.
These algorithms implement simplified interfaces (see
below), rather than the heavy-weight (and Java version
dependent) JCE interface (though it should be possible
to implement a layer that takes one of these and implements
the JCE of the version you are interested in).
The implementations are in fact in the main public
domain, with a few exceptions as noted in []'s below
in package uk.co.demon.windsong.crypt.cea;
Block cyphers - 3Way, CAST5, DES/TripleDES [based on
Richard Outerbridge's 'C' code which just requires
his original authorship to be respected], Blowfish
(variable key length), SAFER (all variations), Square,
TEA (no test vectors).
in package uk.co.demon.windsong.crypt.mda;
Message digests - SHA-1, SHA-0, Haval (all variations),
RIPEM160 [derived from GPL'd 'C' source], MD5 [derived
from the original RSA implementation, freely reusable
with this attribution], and a generic Block Cypher
based hash (put in any block cypher with key-length
equalling block-length to get a hash whose output block
is equal to that common length).
There are factory classes in each package for serving
up instances of these classes, and also some as yet
untested code for running the block cyphers in CFB,
CBC and OFB mode (ported from working 'C' source).
The code is currently available only in source form
(with javadoc comments in the appropriate source
files), within a zip archive containing all interim
code for an OpenPGP-compliant application I'm
currently developing, at
http://www.windsong.demon.co.uk/angerona.zip
You will all be good netizens and respect any legal
restrictions on such code, I trust. (there's also
a bunch of non-crypto utilities, which at some point
I shall publish separately).
xxxx
Those interfaces:-
package uk.co.demon.windsong.crypt.mda;
public interface MDA
{
/**
* Feeds a batch of bytes into the hash
* @param data the byte values
* @param offset the first byte index to take
* @param length the number of bytes to take
*/
public abstract void update(byte[] data, int offset, int length);
/**
* Feeds a byte into the hash
* @param data the byte value
*/
public abstract void update(byte data);
/**
* consolidates the input, and reinitialises the hash
* @return the hash value
*/
public abstract byte[] digest();
}
and
package uk.co.demon.windsong.crypt.cea;
public interface CEA
{
/**
* Initialise the object with one or three key blocks
* @param key array of key bytes, 1 or 3 key block lengths
* @param triple true if three keys for triple application
*/
public abstract void init(byte[] key, int offset, boolean triple);
/**
* Transform one block in ecb mode
* @param encrypt true if forwards transformation
* @param in input block
* @param offin offset into block of input data
* @param out output block
* @param offout offset into block of output data
*/
public abstract void ecb(boolean encrypt, byte[] in, int offin,
byte[] out, int offout);
/**
* Wipe key schedule information
*/
public abstract void destroy();
/**
* Provide infomation of desired key size
* @return byte length of key
*/
public abstract int getKeysize();
/**
* Provide infomation of algorithm block size
* @return byte length of block
*/
public abstract int getBlocksize();
}
- -- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
=====BEGIN PGP SIGNATURE=====
Version: CTCDOS 0.1
iQCVAwUBNoViPIoUd45Z7dNFAQH5AQQAipV7DoQyaPPPrmnxtkuUMOGoDpLs9Fpr
XzIyCcN6fGqlaNPwt4qasbHZXPyGoHX7qKK+89EzTHl13vg7PA5mc5w/uyhvfGwD
FsdqrZA6WjckIHH0bDei6qzqBYdRQGYReMBBD3x0KYpt/NHigk251Dov5yFcpCtH
5FurzgJ7lgc=
=nFcN
=====END PGP SIGNATURE=====
------------------------------
From: "kc" <[EMAIL PROTECTED]>
Subject: S-Tools and PGP 5.5.3a?
Date: Sat, 26 Dec 1998 23:06:46 GMT
Hi All,
I have searched and tried in vain to download copies of:
S-Tools 4
PGP 5.5.3a w/ RSA support
Does anyone have these they can e-mail me, or give me a site URL that
actually works? I've had so much trouble I wonder if these sites aren't
somehow hindered from dispensing their downloads
Thanks,
KC
delete the "nospam-"
[EMAIL PROTECTED]
------------------------------
** 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
******************************
