Cryptography-Digest Digest #141, Volume #12 Fri, 30 Jun 00 13:13:01 EDT
Contents:
Re: How Uncertain? (Mark Wooding)
Re: Compression & Encryption in FISHYLAND (Tim Tyler)
Re: Another chaining mode (Mark Wooding)
Re: It's been pretty quiet for some time... (Volker Hetzer)
Call for volunteers for anonymous, censorship-resistant publishing system (Avi Rubin)
Re: Compression & Encryption in FISHYLAND (Tim Tyler)
Re: When you know the PT is ascii (Guy Macon)
Re: Is this a HOAX or RSA is REALLY broken?!? ("Douglas A. Gwyn")
DES Analytic Crack (lordcow77)
An encryption protocol, version 2 (Dido Sevilla)
Re: Blowfish for signatures? (Eric Lee Green)
Tying Up Lost Ends (SCOTT19U.ZIP_GUY)
Re: Blowfish for signatures? (Eric Lee Green)
Re: breaking encryption - help! (Andru Luvisi)
Re: An encryption protocol, version 2 (Mark Wooding)
Re: Blowfish for signatures? (stanislav shalunov)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: How Uncertain?
Date: 30 Jun 2000 09:04:44 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> > The definition of entropy I'm using is ...
>
> ... one that is suitable only for independent events.
No. The definition works anyway. Using addition to compute joint
entropy only works if the data are independent, but the definition works
anyway. It may, however, be impractical to apply.
My *model* assumed independence between bits and bytes, but I
acknowledged that wasn't very good. I created it to show you'd got the
wrong answers from *your* model, in a previous article, which had even
less accurate assumptions.
> English is a lot more predictable than the uniliteral frequencies
> would lead one to believe.
Yes. Indeed. I think that was my point. Hence your assertion that we
have an entropy of about 6 bits per byte is very strange.
-- [mdw]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Reply-To: [EMAIL PROTECTED]
Date: Fri, 30 Jun 2000 08:43:33 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: From his description of what he was doing - I think I can be forgiven
: for believing it not worth the trouble to plow through his source code -
: I had come to the conclusion that, unfortunately, that which he was
: attempting to do, he got wrong.
A conclusion which appears to me to be in error. David has a decription
of the process he used at http://members.xoom.com/_XOOM/ecil/compres1.htm
You can download his compressor, and test it with random files if you
like to check that a bijection has been attained.
If you have other problems with the technique, you don't appear to have
stated clearly what they are.
: But for those interested, I explain on my web site very carefully how to
: abolish that last tiny fragment of redundancy typically ignored by
: Huffman compression. (The section is titled "Tying Up Loose Ends".)
By contrast, you appear to have built no compressor - and it's not obvious
if you have tested your idea to see if it works.
I have expressed qualms in the past about whether the scheme you present
can possibly work. Essentially, you advocate adding what would normally
be an invalid Huffman symbol at the end of the file, using an alternative
representation for it.
The problem I see is that you don't appear to have any equivalent of
David's rule 4 (which involves) choosing the format of the final symbol
by recursively looking backwards into the file.
If David's work is correct it appears to me that, if you are appending
stuff at the end-of-file, *without* paying proper attention to what has
gone before (i.e not just going on what's left in the Hufman tree at that
point) there's no chance of getting a bijective map.
/Perhaps/ my critique is mistaken (and your technique works) - but the
description on your web pages is too complex to be convincing to me -
I doubt I could construct the apparatus in question from the description
provided.
I recommend building something that can be tested - even if it's just a
demonstration of the idea.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another chaining mode
Date: 30 Jun 2000 09:30:32 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> I am mainly interested in what you meant by the expression of doing
> decryption of your cipher in the 'reverse' direction? I don't see
> anything different from a normal cipher in this context.
To decrypt, you have to start from the end of the ciphertext and work
backwards towards the beginning. Remember, we have
(z_i, y_{i+1}) = E_k(x_i, y_i), 0 <= i < n
Let's say we're given the z_i and y_0. Recovering x_0 given z_0 and y_0
requires an exhaustive search over y_1! Making life that hard for a
legitimate recipient doesn't strike me as clever.
The right things to know to obtain x_0 are z_0 and y_1 -- then we just
decrypt and everything works. Where do we get y_1 from? Well, if we
recover z_1 from x_1 and y_2, then we get y_1. And in general,
decrypting
(x_i, y_i) = D_k(z_i, y_{i+1})
from the end backwards seems to be the right approach.
In fact, I'd consider transmitting the ciphertext as
y_0, z_0, z_1, ..., z_{n-1}, y_n
The recipient can then compare the transmitted y_0 with the computed one
from the decryption of (z_0, y_1) to ensure safe reception.
I don't know why I'm bothering with this though. I prefer Blowfish-CBC
and HMAC-RIPEMD-160... ;-)
-- [mdw]
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: It's been pretty quiet for some time...
Date: Fri, 30 Jun 2000 12:08:03 +0000
Joseph Ashwood wrote:
>
> Right now, it's out of the public eye. I'd expect the next announcement to
> be either an additional phase of request for comments (which means that they
> need further help determining which algorithm should be blessed), or an
> announcement of blessing. I'd also expect the announcement sometime in
> August.
August... ok, thanks.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
Crossposted-To: comp.security.misc,alt.security
From: [EMAIL PROTECTED] (Avi Rubin)
Subject: Call for volunteers for anonymous, censorship-resistant publishing system
Date: Fri, 30 Jun 2000 13:04:36 GMT
We have designed and implemented a system for anonymous, censorship-resistant
publishing on the web. It is called Publius. Details can be found at
http://cs.nyu.edu/waldman/publius/
We are soliciting volunteers to host publius servers. All that is required
is that you run our CGI script on your server, and that you are willing to
dedicate a certain amount of disk space to the project. More information is
available on the publius site.
Key dates:
6/30-7/21 Request For Volunteers
7/21-7/27 Publius Software Distribution and Installation
7/28-9/28 Live Trial of Publius
Today's Washington Post featured an article about Publius. The text is
available at
http://www.washingtonpost.com/wp-dyn/articles/A21689-2000Jun29.html
If you are interested in volunteering, you can sign up on the Publius
web site.
--
http://avirubin.com/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Reply-To: [EMAIL PROTECTED]
Date: Fri, 30 Jun 2000 12:57:35 GMT
Kurt Shoens <[EMAIL PROTECTED]> wrote:
: Does this help an attacker? Is there an attack on any of the finalist
: algorithms for which knowing the encryption of all zeros yields anything?
As far as anyone who's saying knows, there's currently no such attack on
this basis alone.
However, attacks need not be based *only* on the cyphertext.
If you can influence seed generation, observe factors that influence it,
buy or steal a book of keys, etc, etc, you may already have a good deal
of information about the key bits from which an attack can be launched.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: When you know the PT is ascii
Date: 30 Jun 2000 09:24:30 EDT
Andrew John Walker wrote:
>How secure are encryption methods such as DES, IDEA etc when you
>know the PT consists of printable text or some other subset of
>the ascii character set? From what I've read many methods that
>have been proposed are quite suceptible to plain-text attacks,
That's interesting. From what I've read many methods that have
been proposed are quite resistant to known or chosen plaintext
attacks - in fact resistance to such attacks is generally
considered to be among the minimum requirements for a good method.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is this a HOAX or RSA is REALLY broken?!?
Date: Fri, 30 Jun 2000 14:43:40 GMT
Greg wrote:
> Give all of this, it would appear to be an intel op against European
> banks by possibly Isreali intelligence using the news paper as a pawn.
One doesn't need to assume a conspiracy when plain ignorance
would explain it just as well.
------------------------------
Subject: DES Analytic Crack
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 30 Jun 2000 08:52:11 -0700
What ever happened to Eric Michael Cordian's DES Analytic Crack
project that was floating around the cypherpunks mailing list in
1998 or so? They haven't updated their FAQ for since then and I
haven't heard anything else about their results (or even their
lack thereof).
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: An encryption protocol, version 2
Date: Fri, 30 Jun 2000 23:57:05 +0800
Thank you very much for all of your comments on my encryption protocol
the first time around. Having carefully considered all your
suggestions, I feel I'm ready to describe a new version of the secure
protocol...
For those who were unable to get the discussion the first time around,
this is the situation that motivates its design: the set-up is a
client-server system across a large intranet, there being a small number
(46) client terminals that transmit information from time to time to
centralized servers. The protocol that these clients and servers use to
communicate with each other must satisfy the following properties: 1.
the data being transmitted across the network should be secure, and its
contents unreadable to those for whom the data is not intended, 2. the
receiver of any data must have some kind of assurance that the data it
is receiving actually does come from the source it expects, and 3. it
should not be possible to masquerade as a client or server, attempts to
do so should at least be detected. The protocol assumes that both the
clients and the server are trusted; the network itself may not be so
safe.
Each client terminal possesses a secret key known only to itself and to
the server, 128-256 bits long, which is changed roughly once a year.
This key is only used for infrequent data transfers and is not used to
send the bulk of the information across the network.
A transaction between client and server begins when the client sends a
request, in cleartext, to the server, to which the server responds by
sending the client a ticket containing a timestamp, a magic number, and
a session key generated by a true random number generator circuit
attached to the server. All of this is encrypted by the client's secret
key. The client acknowledges receipt of this by sending another chunk
of data, containing a timestamp and another magic number, back to the
server, sealed with the session key just received. This proves the
client's identity to the server. Then the server responds by
transmitting a similar chunk of data to the client. Once this is done,
the client transmits data to the server using the session key just
received, and then sends a cryptographic hash of the plaintext at the
end, to be sure the data were not corrupted.
Algorithmic choices include the following: the encryption algorithm to
be used would either be Rijndael or Serpent (or any clean, efficient
block cipher which could be adapted to use 128-256-bit keys and 128-bit
blocks), in CBC mode. The cryptographic hash would be SHA-1.
Barring any theoretical breakthrough that would render my algorithmic
choices insecure, is there any flaw in the protocol that could be
exploited? I have been thinking about doing preauthentication, as the
encrypted ticket is sent by the server to *anyone* who asks, and so the
shared secret between client and server may be discovered, but I'm not
sure how this should be done. Can anyone give suggestions that would
work?
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
Mobile Robotics Laboratory +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Blowfish for signatures?
Date: Fri, 30 Jun 2000 16:24:06 GMT
Thierry Nouspikel wrote:
> My question is: can I use Blowfish to produce a digital signature? I
> mean, the kind of thing that lets you verify that the document you are
> reading is indeed the original, and wasn't doctored in any fashion.
Yes, much as you can use a hammer to drive screws. It is not, however,
recommended. Bruce Schneier, the inventer of Blowfish, states that Blowfish's
key schedule is too slow. I add that the 64-bit output word is too small for
me to really feel comfortable. You would be much better off with TwoFish, the
designated "successor" to Blowfish, which solves both problems (has 128-bit
output word, much faster key schedule -- though not as fast as some). Note
that TwoFish is an entirely different cipher, it really has little in common
with Blowfish other than "fish" in the name :-).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Tying Up Lost Ends
Date: 30 Jun 2000 16:25:17 GMT
Tying Up Lost Ends
This is based on John Savard's work but he misses a few minor points
lets convert the huffman output stream to an infinte stream
of bits. When we are done encoding we will just write trailing zeroes
There are 2 very specail cases one is <E> which is the most frequent
character. We use nothing for it when it is the last character.
<Z> is the other special character. We always add other <E> after
it when it is last charter to be compressed or if it is the last
<Z> in a trailing sring composes of <E> and <Z>'s.
If the last character encoded is not the most frequent or the least
frequent you use my specail endings which you could
derive by your own means from the following example.
You have one other specail case that is
if the sting is only one character long and is <E> the most frequent
character. For this example pretend that the noexistent preceding
character is not an <E> or <Z>.
What this does is in effect is to elimnate John problem of saying
that there is a missing morse code symbol for <Z> since <Z> can never
really end a string since when encoding a message ending in <Z> you pretend
that an E is added on. And when decompressing you drop the trailing
E. The above is what John in his narrow mindness fails to grasp. There
is a simple 1-1 transform between all files made from characters A-Z
and all charactes A-Z then don't end in Z.
The huffman code table is baised of Jhons. I like 11's being
higher probabilites in the tree splitting his table just
there for reference.
Note here at this point all files finitly odd
that is they end in 1000.... a one followed by infinte number or zeroes
Letter Huffman Code JS David Scott HUffmN CODE DAVE ENDING HUFFMAN CODE
E 000 111 <Most frequent special
case E> 1000...
T 001 110 1 1000...
A 0100 1011 0 1000...
O 0101 1010 11 1000...
I 0110 1001 10 1000..
H 0111 1000 01 1000...
N 1000 0111 00 1000...
S 1001 0110 101 1000...
R 1010 0101 100 1000...
D 10110 01001 011 1000...
L 10111 01000 010 1000...
U 11000 00111 001 1000...
M 11001 00110 000 1000...
W 11010 00101 0100 1000...
C 11011 00100 0011 1000...
Y 11100 00011 0010 1000...
F 111010 000101 0001 1000...
G 111011 000100 0000 1000...
P 111100 000011 00010 1000..
B 111101 000010 00001 1000...
V 111110 000001 00000 1000...
K 1111110 0000001 000000 100...
X 11111110 00000001 0000000 1000...
J 111111110 000000001 00000000 1000...
Q 1111111110 0000000001 000000000 1000...
Z 1111111111 0000000000 ( Z specal case no endind since E
added)
With the above set you can code any secquence A-Z into a infinite
set of bits such that all strings end in 1000...
The next question is how do you change this set to 8 bit byte files in
a bijective way. Thanks to Matt Timmermans this is easy.
First chop off all the trailing all zero bytes.
But I am using the orginal defination not his current one.
look at the file in 8-bit chucks where the farther the
bit is to the right the higher the value is. 1 is 10000000
2 is 01000000 3 is 11000000 and so on. Now subtract 1
from the left most byte using carrys from ajacent bytes
if needed. Then advance to next byte and subtract one from
it with a borrow. Do this until you reach the last byte.
Then the last byte will either be its current value-1 or value-2
if a carry was borrowed from it. If the last byte was 10000000
it will either be the all zero byte which is valid for a last
byte or if there was a borrow it is dropped from the output.
Now I say the last byte in a long file can be anything and that
replacing it with any of the 256 byte values that you get a valid
string and that any such value for the last byte must be considered.
However john can see that due to the nature of the files that the trailing
1000... could ocurr anywhere in the file and that a last byte
of 10000000 may occur about 8 out of 256 times but what
John failed to consider is that it is not a question of
just freezing where the 100... string occurs but that for every
time the last '1' occurs one more bit out there are twice as many possible
files so in reality it does not occur 8 out of 256 times in the first
position of a byte. That said however I agree one can do better
but this does not mean that the compression added information
to the file. Because it is a 1-1 transform and no information
was added to the file that could have been used with out the compression.
My next version of scott16f will use the compression of a
conditional set to a finitely odd file and when encryption occurs
the last 100.. will only be used as a place holder and will not
take place in the encryption scheme and this would help to
encrease the unicity distance of the encrption because your are
in effect encrypting a more highly compressed file and my code
will treat the string of relevant bits as a single block.
examples
"string" to "adjusted string" to "finitely odd file" to "8-bit file"
A to A to 0 1000... to 01000000 to 10000000
AT to AT to 1011 1 1000... to 10111100 to 00111100
AE to AE to 1011 1000... to 10111000 to 00111000
E to E to 1000... to 10000000 to 00000000
Z to ZE to 0000000000 1000..to 00000000 00100000 to 11111111 01000000
ZE to ZEE to 0000000000 111 1000... to 00000000 00111100 to 11111111
01011100
J to J to 00000000 1000... to 11111111
Q to Q to 000000000 1000.. to 11111111 00000000
YN to YN to 00011 00 1000.. to 11101001
ATE to ATE to 1011 110 1000.. to 00111101
SI to SI to 0110 10 1000.. to 10101010
TOE to TOE to 110 1010 1000.. to 01010101
The above is just an example. I prefer adaptive huffman compression
but if people want it I could write code similar to above but maybe
a "_" for the "space" symbol and numbers "0-9" one could have a program
that chops character in 60 symbol lines so that a carridge return
is not needed.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Blowfish for signatures?
Date: Fri, 30 Jun 2000 16:30:45 GMT
Runu Knips wrote:
>
> Thierry Nouspikel wrote:
> > My question is: can I use Blowfish to produce a digital signature? I
> > mean, the kind of thing that lets you verify that the document you are
> > reading is indeed the original, and wasn't doctored in any fashion.
>
> Well, to get a digital signature, you need to have a
> (cryptographical) hash function and an asymmetric cipher.
The cryptographic hash function is a given. You can use pretty much any block
cipher as a cryptographic hash, though some block ciphers are better than
others at doing this. Implementation is left as an exercise for the reader
:-). However, you do not necessarily need an asymmetric cipher if you are
talking about two trusted parties. They can share an authentication key
(perhaps sent via a courier packet :-) and simply add that key in to the
cryptographic hash to see whether the recipient's copy of the message is
identical to the sender's copy of the message. Obviously this is not a
general-purpose mechanism, but may be appropriate for certain limited
applications. I do agree that incorporating a true public key algorithm is far
superior.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: breaking encryption - help!
Date: 30 Jun 2000 09:22:57 -0700
I have determined that it carries an internal state of some kind, with
the following two strings. You will note that thet eleventh character
is the same, and encrypts to the same value in both strings, but the
strings after the eleventh character are also the same, and encrypt to
different values. The first four bytes are, I suspect, the length as
a little endian 4 byte int.
qweplmzkodabcdefghijklmnopq
1b 00 00 00 29 e0 da eb 2e 62 78 a4 3a e6 c7 fe
18 2d 5b ad 0b 9f e6 f1 18 06 cc 62 be f2 5b 0a
wwnhhbnnjiabcdefghijklmnopq
1b 00 00 00 2f 83 8b c4 84 a9 15 fd 60 d0 c7 c9
03 3c 09 73 fb f6 c9 ef c8 21 0b e5 75 c4 0c 0a
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: An encryption protocol, version 2
Date: 30 Jun 2000 16:42:05 GMT
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> Each client terminal possesses a secret key known only to itself and
> to the server, 128-256 bits long, which is changed roughly once a
> year. This key is only used for infrequent data transfers and is not
> used to send the bulk of the information across the network.
>
> A transaction between client and server begins when the client sends a
> request, in cleartext, to the server, to which the server responds by
> sending the client a ticket containing a timestamp, a magic number,
> and a session key generated by a true random number generator circuit
> attached to the server. All of this is encrypted by the client's
> secret key. The client acknowledges receipt of this by sending
> another chunk of data, containing a timestamp and another magic
> number, back to the server, sealed with the session key just received.
> This proves the client's identity to the server. Then the server
> responds by transmitting a similar chunk of data to the client. Once
> this is done, the client transmits data to the server using the
> session key just received, and then sends a cryptographic hash of the
> plaintext at the end, to be sure the data were not corrupted.
OK. Let's make this more concrete and formal. Let S be the server, and
let C_i be the clients. Each client C_i has a key K_i, known by it and
the server. There are also arbitrary public constants N_j.
The protocol mesasges are then:
1. C_i --> S: i
2. S --> C_i: E_{K_i}(T_S, N_0, K)
3. C_i --> S: E_K(T'_{C_i}, N_1)
4. S --> C_i: E_K(T'_S, N_2)
5. C_i --> S: E_K(M, H(M))
In detail:
1. The client sends its identifier i to the server.
2. The server generates a session key K, and sends a fresh timestamp
T_S, the public constant N_0 and the session key, encrypted under
the shared key K_i.
3. The client decrypts the server's response, checks the constant
N_0 and the timestamp T_S, and reads the session key K. It
responds with a fresh timestamp of its own T'_{C_i} and a different
public constant N_1, encrypted under K.
4. The server decrypts the response, and checks the constant N_1 and
the timestamp T'_{C_i}. It sends back a new fresh timestamp of its
own T'_S and yet another public constant N_2, encrypted under K.
5. The client decrypts the server's message, verifies T'_S and N_2,
and sends its message M, and a collision-resistant hash of the
message H(M), both encrypted under K.
Analysis:
* I can't see why message 4 is useful. By this time, the client knows
the server is OK (because he encrypted a valid timestamp T_S and the
public constant N_0 in step 2 under the shared secret K_i). We can
therefore elide message 4, and combine messages 3 and 5.
* I'm a bit cautious about using hashes where what's really wanted is
a MAC. If I were designing this protocol, I'd use a keyed MAC
H_K(M) in message 5, and probably I'd use MACs instead of the public
constants N_j, although I don't see that this would matter much.
* Do we need all of those distinct timestamps? My suspicion would be
that, once the server has issued T_S in message 2, we can continue
using T_S as a `session identifier' in the other messages, rather
than inventing new fresh timestamps T'_S and T'_{C_i}. Comparison
is also easier if we do this, and we don't need to think about
awkward issues like permissable time windows and possible clock skew
in the server.
> Algorithmic choices include the following: the encryption algorithm to
> be used would either be Rijndael or Serpent (or any clean, efficient
> block cipher which could be adapted to use 128-256-bit keys and
> 128-bit blocks), in CBC mode. The cryptographic hash would be SHA-1.
Reasonable choices. After the demolition job the Counterpane boys did
on Rijndael relatively recently, I'm a bit cautious about it -- breaking
7 rounds out of 10 is a worry, even if the attack isn't particularly
practical. Serpent is surely a good choice, however, if you're going to
pick an AES candidate. If you take my advice above and replace the hash
by a MAC, a good choice would be HMAC-SHA1. It's slower than raw SHA1
by an additive constant (not a factor), and gives security which is
provably related to the strength of SHA.
> I have been thinking about doing preauthentication, as the encrypted
> ticket is sent by the server to *anyone* who asks, and so the shared
> secret between client and server may be discovered, but I'm not sure
> how this should be done.
I'm not sure this is necessary. We're assuming that the symmetric
cipher we're using is strong, so being given arbitrary known plaintext
encrypted under the shared key shouldn't be a problem.
-- [mdw]
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: Blowfish for signatures?
Date: 30 Jun 2000 12:26:46 -0400
Thierry Nouspikel <[EMAIL PROTECTED]> writes:
> can I use Blowfish to produce a digital signature?
No. Blowfish is a symmetric block cipher. There's a variety of
public key digital signature schemes (RSA, DSA, El Gamal, and some
more obscure).
------------------------------
** 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
******************************
