Cryptography-Digest Digest #981, Volume #12 Sun, 22 Oct 00 22:13:01 EDT
Contents:
Looking for C Source Code to stream compression algo (Cronos)
Re: CRC vs. HASH functions (Bryan Olson)
Re: Why trust root CAs ? (Anne & Lynn Wheeler)
Re: Storing an Integer on a stream (Tim Tyler)
Re: My comments on AES (Tim Tyler)
Re: On block encryption processing with intermediate permutations (Bryan Olson)
toy cipher question (Benjamin Goldberg)
Re: newbie pathetic question (Benjamin Goldberg)
Re: Why trust root CAs ? ("Tor Rustad")
Re: CRC vs. HASH functions (Tim Tyler)
Re: Encrypting a file using Rijndael (John Savard)
----------------------------------------------------------------------------
From: Cronos <[EMAIL PROTECTED]>
Subject: Looking for C Source Code to stream compression algo
Date: Sun, 22 Oct 2000 23:07:52 +0100
Hi,
I am looking for the source code to a public domain stream compression
algorithm, better than RLE. I've had a look around at some
implementations of LZ algorithms, but they mostly seem to work on
blocks and I havent found any really clean source code. I just
basically want two functions for a win32 program:
BOOL ReadFileCompressed(HANDLE sfile,byte Rbyte)
BOOL WriteFileCompressed(HANDLE sfile,byte *Wbyte)
and maybe a Flush function to clear any buffer.
or some source code which could be converted to this kind of format
quite simply. Can someone point me in the right direction please ?
Thanks
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Date: Sun, 22 Oct 2000 22:12:57 GMT
Tim Tyler wrote:
> To reiterate, my claim is not that secure cryptographic
> hash functions can be made as fast in hardware as CRCs.
The specific claim relant here was
| Consequently - while the area used is much increased when
| compared to a CRC - there's not anything like so much
| difference in throughput speed as a software engineer might
| expect.
This is nonsense. No SHA-1 hardware that anyone makes (or
is likely to make) can match a hardware CRC.
Counter mode can always be computed in parallel. That has
nothing to do with the properties of the hash.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Why trust root CAs ?
Reply-To: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
From: Anne & Lynn Wheeler <[EMAIL PROTECTED]>
Date: Sun, 22 Oct 2000 22:20:54 GMT
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes:
> there is a mapping of x9.59 to iso8583 (i.e. payment cards, debit,
> credit, etc)
one of the issues in mapping digital signatures to the existing
payment infrastructure and providing end-to-end authentication ... was
the typical 8583 message was 60-100 bytes. It was possible to map the
additional x9.59 fields and a ec/dss into something like an additional
80 bytes or so (nearly doubling message size for authentication).
A certificate-based infrastructure represented two approaches ...
1) use certificates in an internet-only mode and truncate them at
boundary between the internet and the financial infrastructure. The
downside was giving up on basic security tenets like end-to-end
integrity and end-to-end authentication.
2) carry the certificate ... but compress it into a manageable mode.
Now, some things cropped up:
Justification for the financial institution registering the public key
were a) provide sufficient information for customer call center to
handle trouble calls related to digital signature transactions and b)
support "relying party only" certificates. Relying party only
certificates basically carried only an account number ... and designed
by financial institutions to address liability and privacy issues.
With transactions carrying only a an appended relying party only
certificate ... the account record has to be read ... containing the
original of the certificate.
Therefor flowing any such certificate at all through the
infrastructure can be viewed in one of two ways:
1) it is possible to compress out of a transaction appended
certificate every field that the recepient is known to already
have. Since the recepient has the original of the appended
certificate, then every field in a transaction appended certificate
can be removed ... resulting in a zero-byte appended certificate
2) given the the consumer has a copy of the certificate, while the
recepient (financial institution) has the original of the certificate
that will be read when the transaction is executed, it is redundant
and superfulous to bother sending back to the recepient a copy of
something the recepient already has (i.e. the original registered
public key along with all its binding).
So the x9.59 mapping to 8583 can viewed as either a) carrying a
zero-byte appended certificate ... or b) not bothering to
superfulously transmit to the financial institution a copy of some
information (i.e. a public key and the public key bindings, represeted
by a certificate) appended to every transaction when the financial
institution has the original of that same information. In either case
it minimizes the transaction payload bloat incurred by adding
transaction authentication.
The X9.59 mapping to 8583 with included digital signature can provide
end-to-end transaction authentication ... i.e. financial transaction
instruction from the consumer to the consumer's financial institution
... with the institution responsible for authorizing and executing the
financial transaction instruction is actually also authenticating the
same instruction.
In prior posts, it was also pointed out that it is superfulous (as
well as raising privacy issues) if parties not responsible for
executing the transaction are performing extraneous authentication
operations on the transaction.
--
Anne & Lynn Wheeler | [EMAIL PROTECTED]
http://www.garlic.com/~lynn/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 22:03:20 GMT
[EMAIL PROTECTED] wrote:
: Okay: You take your data plus padding, and you write down its length in
: binary and count the bits. Then you use that many bits in the header to
: show the data length. Simple, ne?
Not a bad scheme. The idea is to add the information to the file,
prior to encryption - not put it in the header. If you did that with
this method you would probably need to adjust the scheme to produce some
multiple of 8 bits - assuming that is what the encryption program can
handle.
However it still typically allows many files decrypted with trial keys to
be rejected (on the grounds that the offset is off the end of the file).
This is what David's method is designed to completely avoid.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Reply-To: [EMAIL PROTECTED]
Date: Sun, 22 Oct 2000 22:17:15 GMT
Rob Warnock <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
: +---------------
: | Stephen M. Gardner <[EMAIL PROTECTED]> wrote:
: |
: | : Now what makes you think that he said it was breakable.
: |
: | How about the bit where he wrote (from the URL above):
: |
: | ``I believe that within the next five years someone will discover an
: | academic attack against Rijndael.''
: +---------------
: You just *love* quoting stuff way out of context to twist its meaning,
: don't you? [...]
What an irritating post.
Stephen asked "Now what makes you think that he said it was breakable."
I quoted the bit where he said he expected a break within five years.
Quoting more would have been redundant - that single sentence
answers the question exactly and precisely - and the rest is not
relevant to it.
I didn't "twist the meaning". Bruce stated that he believes that within
the next five years someone will discover an academic attack against
Rijndael. That seems self-explanatory enough to me.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Sun, 22 Oct 2000 23:03:25 GMT
Mok-Kong Shen wrote:
> I believe that you have till now misunderstood me. Let me
> try to explain my point therfore once again. First I repeat
> what I posted previously:
Don't know if I've understood you, but I do know that
what you have posted is irrelevant to my attack.
> Input of first cycle (known to opponent, being chosen):
> (u,u) (u,u) (u,u) (u,u)
That is _not_ a plaintext that my attack might choose. I use
a one-block (two-word) plaintext, then a two-block
(four-word) plaintext. Consequently I do not care whether
this plaintext leads the attacker to a dead-end; I never
sent him down that path. (On the other hand, in the
single-permutation case, this chosen plaintext could be used
with a trivial variation of the attack.)
> Output of first cycle:
> (v,w) (v,w) (v,w) (v,w)
>
> (Assumed) permutation (unknown to opponent) of words,
> resulting in input of second cycle:
> (v,v) (v,w) (w,v) (w,w)
>
> Output of second cycle (know to opponent):
> (a,b) (c,d) (e,f) (g,h)
>
> Let the cipher be such that with input block (L,R) one gets
> with round-keys S1,S2 the output block (X,Y) as follows
> (I use a more general functional form than what would be
> the case with DES-type of construction):
>
> X=F1(S1,S2,L,R)
> Y=F2(S1,S2,L,R)
I don't care about the first rounds. My attack isolates
the last round-pair.
> Now the communication partners, since they know the
> permutation and hence the whole history depicted above,
> can start from e.g. the first ciphertext block (a,b) (or
> similarly any other ciphertext block above) and compute as
> follows, assumining that the four round-keys are K1, K2,
> K3 and K4:
>
> Since (a,b) is the encryption of (v,v) in the second cycle,
> we have, using the above relationship:
>
> a=F1(K3,K4,v,v)
> b=F2(K3,K4,v,v)
>
> We have now to find v. Since (u,u) is encrypted to (v,w)
> in the first cycle, we have
>
> v=F1(K1,K2,u,u)
>
> Thus we obtain finally the relationship
>
> a=F1(K3,K4,F1(K1,K2,u,u))
> b=F2(K3,K4,F1(K1,K2,u,u))
>
> from which one could presumably use sort of techniques of
> differential analysis gain certain information about the
> round-keys and hence the key of the cipher.
Irrelevant to my attack; I don't break it by working through
the first rounds. A better specific simple case to show how
my attack works would be the first 14 rounds of DES,
followed by the word permutation, then the last two DES
rounds. My attack (especially with the enhancement I posted
this morning) would break this much faster than the best
known attack on DES.
> Now the crucial point is that the opponent, since he
> is ignorant of the permutation, doesn't know that (a,b)
> above is the encryption of (v,v) in the second cycle. For
> with a different permutation it could have equally been
> (v,w) or (w,v) or (w,w) instead. In each of the four
> possible cases (which he has no means to know to be
> actually the one he has at hand) he will have to employ
> a different set of equations relating a and b to u, in
> order to gain information about the key of the cipher.
> What should he exactly do? Could you please kindly tell?
He should use my attack. If chooses (u, u) as his one-block
plaintext, he finds that the two possible outputs are (c, d)
and (e, f).
Now he knows that (c, d) and (e, f) are the sibling pairs so
(a, b) and (g, h) must be repeated-word pairs. He can now
set up and solve the equations given in my explanation of
the attack.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: toy cipher question
Date: Sun, 22 Oct 2000 23:33:19 GMT
I have a few functions that I want to use as components of a cipher, and
I want to know how secure they are on their own (ie, if used as complete
ciphers)... Or at least, how strong are they relative to each other,
using various values for the "rounds" variable. Assume that k contains
(2*rounds) truly random bytes, and sbox8 and sbox16 have "good"
properties.
void toya( unsigned char *ct, unsigned char *pt, unsigned char *k )
{
char a = pt[0], b = pt[1], i;
for( i = 0; i < rounds; ++i ) {
a = sbox8[a + *k++], b = sbox8[b + *k++];
a += (b += a); }
ct[0] = a; ct[1] = b;
}
void toyb( unsigned char *ct, unsigned char *pt, unsigned char *k )
{
char a = pt[0], b = pt[1], i;
for( i = 0; i < rounds; ++i ) {
a += sbox8[b + *k++];
b += sbox8[a + *k++]; }
ct[0] = a; ct[1] = b;
}
void toyc( unsigned char *ct, unsigned char *pt, unsigned char *k )
{
short a = (pt[0]<<8) | pt[1], i;
for( i = 0; i < rounds; ++i, k += 2 )
a = sbox16[ a + (k[0]<<8) + k[1] ];
ct[0] = a >> 8; ct[1] = a & 0xFF;
}
Yes, I know that toyb is just a fiestel, but think of this as an
experiment with toyb as a control. The toya function, with rounds=1, is
the mixing function used in Tom Denis's TC2. The toyc function uses an
sbox that is probably overlarge for practical use.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: newbie pathetic question
Date: Mon, 23 Oct 2000 00:03:28 GMT
Chris McKenzie wrote:
>
> Danilo wrote:
>
> > I wonder why is arithmetic coding not used to scramble messages ?
> >
> > If I arithmetic compress a message, but using a frequency table
> > which is actually my key (both in the frequencies and in the order
> > of the bytes), wouldn't it be very hard to decrypt ?
> >
> > Excuse in advance for my pathetic ignorance of the matter.
> >
> > Danilo
>
> This is actually the cause of some exciting research I have been
> doing. If I here you correctly you are implying that the use of a one
> time pad wherein you randomly enumerate a sequence of elements in a
> set (let's say an alphabet) to the length of the plaintext.
I don't believe that you read his post correctly. What Danilo is
suggesting is to make an array of 256 integers, each with a random,
non-negative value. Construct a static arithmetic encoder, using those
integers as the frequencies of your bytes. Encode your text with this.
It is not a one-time-pad, as it has a fixed 256*sizeof(int) byte long
key.
How secure is it? I don't know. There has been some analysis done on
huffman encoding, by first creating the tree according to the actual
frequencies in the text, and then assigning labels to the branches at
random[*], but there hasn't been anything done based on randomly made up
frequencies.
* Mojdeh Mohtashemi, "On the Cryptanalysis of Huffman Codes" May, 1992
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Sun, 22 Oct 2000 14:19:23 +0200
"Lyalc" <[EMAIL PROTECTED]> wrote in message
> A couple of other things SET doesn't protect against:
> 1. The order and certificate can be transmitted without SSL protection,
> allowing any "every sniffer and server along the route" to match
> order/delivery details (such as name, address etc) with the cardholder
cert
> alias
Full SET has:
Cardholder Merchant PaymentGW
PReq ---------------->
-------------------> AuthReq
<========> FI
<------------------- AuthRes
PRes <----------------
and SSL (or TLS) is not used. Since this is complicated, many have started
with a simpler model which we call merchant-only SET (MOSET). Here, SSL is
used and only the merchant POS has a SET certificate.
As long as the card companies allow non-SET transactions, we will not see
the real thing.
> 2. The cert being revoked around the time of the transaction. SET has an
> inherent "Originating party" liability model. The US Govt's PKI schema
> requires Relying parties to validate certificates before relying upon the
> digital signature as an electronic signature. In a large dispersed
> environment, this is perhaps the only way cert validity can be managed
with
> any reasonable granularity, and the expense of very high bandwidth and
> CA/Revocation server availabiltiy requirements (AFAICS, all workable CRL
> models require very high bandwidth, and very high availability).
?
In SET, the idea was to close the card account, using existing
infrastructure on this. So AFAIK, in SET there is no need for CRLs with
revoked cardholder certificates, and none is defined either.
> There are working, high volume, secure environments out there today which
> don't require cardholder keys, but do require secure key management. For
> certificate based schema to get to that level of security, low exposure
and
> reliability, they need to be implemented on ATM or EFTPOS -like devices.
> Since this level of hardware protection is needed to make certificate
> schemes even moderately secure, why use certs as the hardware already does
> all the necessary security?
There are a lot of problems with implementing PKI with high security, but it
can be done. Major players will do it, and those with an expensive
expierience with SET, I think can do the job well. I am more worried about
smaller companies jumping on the PKI wagon, they lack technical expertice to
handle this complex infrastructure with its many pit falls. Bruce S. has
some very valid points, but he is not the only person seeing these PKI
problems, of his 10 risk issues none of them where new to one finacial
institusion at least...we have a lot more!
Using smartcards or ATM/EFTPOS -like devices, does not solve some
fundamental security issues with a real life PKI implemetation. Before the
banks/card companies invest in such end-to-end HW based infrastructure, I
think they need to verify and make shure the basic infrastructure works (!)
and is implemented correctly. Trusting IE to do certificate path validation
correctly, is not an option.
--
Tor
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Reply-To: [EMAIL PROTECTED]
Date: Mon, 23 Oct 2000 01:19:23 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> To reiterate, my claim is not that secure cryptographic
:> hash functions can be made as fast in hardware as CRCs.
: The specific claim relant here was
: | Consequently - while the area used is much increased when
: | compared to a CRC - there's not anything like so much
: | difference in throughput speed as a software engineer might
: | expect.
: This is nonsense. No SHA-1 hardware that anyone makes (or
: is likely to make) can match a hardware CRC.
My claim appears to be pretty vaguely worded - but certainly there is
no incompatibility with your following statement.
I granted that there were other issues that mean that CRCs are likely to
remain faster than many hashes in the post you are responding to.
: Counter mode can always be computed in parallel. That has
: nothing to do with the properties of the hash.
It's "helpful" that the computation can be done in parallel, without
laying out N separate implementations of the hash.
But you're right to point out that basically my statements boil down to
the fact that some hash applications can be parallelised, so any
deficiencies in raw speed can be traded for area.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ http://av.com/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Encrypting a file using Rijndael
Date: Mon, 23 Oct 2000 01:14:26 GMT
On Sun, 22 Oct 2000 23:55:40 +0200, "mac" <[EMAIL PROTECTED]> wrote, in
part:
>I've somehow managed to make an implementation of Rijndael in C++ that
>encrypts a single string and would like to add an option of encrypting a
>whole file. I don't know what's the standard for doing this. Is every null
>terminated string in a file encrypted separatelly or do I treat the whole
>file as one array of 8-bit bytes no matter of null-characters. Of course, it
>is not the same and if someone else would try to decrypt it using the other
>method, result wouldn't be the original plain text.
The former is done only when you want to read single records in the
file while it stays encrypted. The latter is usual, because otherwise
information about the length of each line is needed to decrypt, and
that information, unless it is encrypted separately, gives away
information about the file.
But the null characters that end strings in C are *not* part of the
file. Instead, the carriage return or line feed characters - which the
standard C function for reading lines from a file does not remove for
you - are what mark the limit between characters in a file. You should
use "rb" and "wb" when opening the file, and read and write the file
in chunks of fixed length, so that even a binary file - like a .GIF or
.EXE - can be encrypted, then decrypted again, and still work.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
