Cryptography-Digest Digest #658, Volume #12 Mon, 11 Sep 00 21:13:00 EDT
Contents:
Re: Problem with Tiger hash algorithm and binary files (Jim Gillogly)
Re: Steganography and secret sorting (Matthew Skala)
Re: CAST-Cipher / CAST-Algorithm ("Brian Gladman")
Re: Getting Started, advice needed (FAQs , yes I read them) ("Paul Pires")
Re: RSA patent expiration party still on for the 20th (No User)
Re: Request for Blind Signature API (lcs Mixmaster Remailer)
Re: RSA public exponent (lcs Mixmaster Remailer)
Re: Bytes, octets, chars, and characters (Paul Schlyter)
Re: RSA patent expiration party still on for the 20th (No User)
Re: CRC's as MAC's (Bryan Olson)
For the Gurus ("root@localhost " <[EMAIL PROTECTED]>)
Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
Re: Getting Started, advice needed (FAQs , yes I read them) ("Scott Fluhrer")
Re: Intel's 1.13 MHZ chip (John Savard)
Re: For the Gurus (Jim Gillogly)
Re: MAC (David A. Wagner)
Re: ExCSS Source Code (John Savard)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Problem with Tiger hash algorithm and binary files
Date: Mon, 11 Sep 2000 22:23:14 +0000
[EMAIL PROTECTED] wrote:
> binary files. For example, when reading a binary file into an array, the
> first null character (0) encountered will terminate the string (array).
Your problem is in the hash() macro:
> #define hash(str) tiger((byte*)str, strlen(str), res); \
You don't want strlen(str) here: you want count or i.
strlen() is a string function, and terminates when it sees a '\0'.
You should also look more closely at your loops: you're
stepping on your string when you read it in. You shouldn't
need to decrement "count" or step on your input string at all.
I'd also re-write it to work in one pass -- you'll probably have
to look at the tiger code to see how to do it a chunk at a time.
--
Jim Gillogly
Trewesday, 20 Halimath S.R. 2000, 22:16
12.19.7.9.14, 3 Ix 17 Mol, Fifth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Steganography and secret sorting
Date: 11 Sep 2000 15:14:41 -0700
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Transposition is one major technique of cryptography. So,
>if you rearrange your items in some way unknown to the
>opponent, you gain some security. A simple method is to use
>a secret seed and a PRNG to do the permutation. The recipient
>can inverse the permutation and get back the original stuff.
Usually in transposition schemes, the permutation is determined by the key
and is used to permute the message. My proposal is for steganography
rather than encryption: the permutation is determined by the message
instead of the key, and applied to harmless "cover" traffic.
--
Matthew Skala
[EMAIL PROTECTED] I'm recording the boycott industry!
http://www.islandnet.com/~mskala/
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: CAST-Cipher / CAST-Algorithm
Date: Mon, 11 Sep 2000 23:33:03 +0100
> > can anyone of you send or tell me where to get a good description of
> > the (function of the) CAST-Cypher / CAST-Algorithm (256-bit version
> > pereferred). It would also be great if you coud send me or tell me
> > where to get an implementation (C++-source-code preferred) of said
> > cipher / algorithm.
> >
I have a C version of the CAST cipher submitted in AES round one on my
web site at:
http://www.gladman.uk.net/
It would be easy to put into C++
Brian Gladman
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 15:39:59 -0700
Sorry, I missed this.
>I was thinking that was possible,
> but maybe a known or chosen plaintext would be needed.
Known or chosen plaintext or ciphertext attacks can actually be easier
than "Guessing" or searching anything. You have to look at who has
access and who might be evil. Let's say group A is everybody who can
get a message encoded or decoded but don't necissarily have access to
the key and Group B are your potential adversaries. If anyone is in both
groups they got you.
The best way to get a known plaintext is to write it yourself and get
it encrypted. If the adversarys can't do it themselves, can they con one
of your group A folks into doing it?
Paul
------------------------------
Date: Mon, 11 Sep 2000 18:07:10 -0500
From: No User <[EMAIL PROTECTED]>
Subject: Re: RSA patent expiration party still on for the 20th
[EMAIL PROTECTED] (Rich Wales) wrote:
>"No User" wrote:
>
> > Keeping the invention internal and unproductive
> > for the term of the patent is not enough to claim
> > the experimental use defense;
>
>If this is true, what implications might it have on the use in the
>US of the following:
>
>==> RSA code which was written outside the US, and intended at the
> time only for use outside the US?
I would assume (though I'm far from sure about this) that a
person who imports the invention into the U.S. prior to the patent's
expiration is in the same position as someone who makes the invention
within the U.S. - they would be infringing unless they had a license
or could raise a valid experimental use defense.
>==> PGP 2.6.3ia or other software using Phil Zimmermann's MPILIB
> code, which was written in the US in the 1980's?
I don't think that the presence of MPILIB would affect the
availability of the experimental use defense. However, if you think
your "experiments" with the international versions of PGP are going to
yield commercial results after the patent expires, you may want to
consult a legal professional.
------------------------------
Date: 11 Sep 2000 23:20:17 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Request for Blind Signature API
> Would you tell me where Blind Signature API (in Java / C++) can be found or
> how to write a Blind Signature function?
Blind signatures are not used very widely, so there is probably no
standard API. Their main application is in anonymous electronic cash
and credentials, and only a few pieces of software have been created
which implement such concepts. You might do a web search for the
"lucre" project, which implements blind signatures. (Note, there are
actually two independent projects by this name, both of which implement
blind signatures, but in very different ways.)
The idea of a blind signature is that one party has a signing key K,
and the other party has the message to be signed, M. They execute a
protocol and the second party ends up with Sign(K,M), the signature on
M by K. The first party does not learn this value, nor the value of M,
or anything else that would allow him to link up M with Sign(K,M).
The design must be driven by the fact that this is a two party protocol.
Unlike ordinary signatures, which can be implemented in a single program,
blind signatures must be implemented by two programs which communicate
with each other. This means that the API must be more like SSL, SSH, or
other communication protocols than like a crypto library API. There will
need to be a mixture of computational and communication steps involved,
and state must be preserved over the course of the protocol.
Ideally, an API of this nature would be relatively "agnostic" about
the nature of the communications. The data could be transfered by a
direct Internet connection; by email; or by carrier pigeon if it came
down to that. The API would implement the transformations of the data
at each step, maintaining state as needed.
Broadly speaking, the steps on the client side might consist of (1)
initialization; (2) inputting M and getting it ready to be sent;
(3) processing whatever data is received from the signer in response;
(4) termination. On the server side we would have (1) initialization;
(2) processing the blinded M value received after step 2 from the client;
(3) termination. After each step we would take the output and send it
to the other side. At the end the client side ends up with the blind
signature and the server knows nothing about it.
You might take a look at GSSAPI, http://www.faqs.org/rfcs/rfc2743.html.
This is specific to traditional functionality like encryption and
signature, but the same general model could work for more general
protocols like blind signatures.
------------------------------
Date: 11 Sep 2000 23:20:45 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: RSA public exponent
> > When generating keys, we can "set" one exponent to a specific number
> > and let the algorithm find the other exponent. Both exponents must
> > be relatively prime to phi(N) (as stated elsehwere).
>
> Better stated: if your chosen exponent isn't relatively prime to
> \lambda(n) then the other exponent doesn't exist.
Keep in mind that phi(n) and lambda(n) are equivalent for this purpose,
because phi(n) and lambda(n) factor into the same primes (albeit possibly
with different exponents). Hence to be relatively prime to one is to
be relatively prime to the other.
If n is an RSA modulus, n = pq:
phi(n) = (p-1)(q-1)
lambda(n) = (p-1)(q-1)/gcd(p-1,q-1)
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 12 Sep 2000 00:16:52 +0200
In article <[EMAIL PROTECTED]>,
stanislav shalunov <[EMAIL PROTECTED]> wrote:
> mike burrell <[EMAIL PROTECTED]> writes:
>
>> IP addresses (with one exception that i can think of) are treated as
>> arrays of characters, not integers (not enough that anyone would do
>> any arithmetic on them anyway).
>
> Internally, IP numbers are almost always converted to binary mode.
> That's how you show them to your system's socket API.
>
> Arithmetic on them is used, too: bitwise operations for netmasks.
Sorry, but these operations are logical oprerations, not arithmetic
operations.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Date: Mon, 11 Sep 2000 18:28:12 -0500
From: No User <[EMAIL PROTECTED]>
Subject: Re: RSA patent expiration party still on for the 20th
[EMAIL PROTECTED] (those who know me have no need of my name)
wrote:
>>Furthermore, RSA applications that were developed before the 6th
>>(which includes applications that were legally developed outside the
>>United States, like PGP v2.6.3i) are not covered by this two-week
>>grace period at all; as I understand the law and RSASI's
>>announcement, (read the disclaimer above!), it is still illegal to
>>use them within the United States before the patent expires.
>
>even after the patent's expiration those programs will continue to be
>illegal since they were produced during the patent's period of
>enforcement, so far as i understand patent law, i.e., so little that
>you should probably just skip this article.
As I understand the law (again, I am not a lawyer), PGP v2.6.3i and
other foreign-developed RSA applications will be legal for Americans
to import and use after the 20th.
Basically, U.S. patent law says that you are an infringer if you
make, use, offer for sale, sell, or import an invention with a U.S.
patent within the U.S. during its term. Once the patent expires, it
is no longer possible to infringe, though you can still be sued for
past acts of infringement (up to 6 years after the act). Likewise, it
is impossible to infringe if you are outside of the United States and
its spacecraft.
Finally, those in America who have jsut been privately experimenting
with the international versions of PGP over the last 6 years are
probably o.k. too because of the "experimental use" defense that has
been discussed elsewhere in this thread.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CRC's as MAC's
Date: Tue, 12 Sep 2000 00:02:45 GMT
Dido Sevilla wrote:
> The target embedded system is a 16-bit 80186 family
> microcontroller.
That's a reasonably powerful processor.
[...]
> All of the MAC
> algorithms I've been able to find, HMAC-SHA1, HMAC-MD5,
> HMAC-RIPEMD, UMAC, and hash127 all seem to be optimized for
> 32-bit processors and are painfully slow on machines with
> word sizes smaller than that.
Yes, they're optimized for 32-bit processors, but with some
cleverness they run well on smaller machines. (My own
experience here is implementing SHA-1 on the tiny 8051.)
> My only criteria are that it be reasonably efficient on
> 16-bit x86 and reasonably safe against forgery for messages
> of length less than 2^40 bits in length. My efficiency
> criterion roughly means that operations are either
> byte-oriented or oriented towards 16-bit words as far as
> possible.
That doesn't make sense as a requirement. What's your
minimum acceptable speed? If we could beat the minimum by a
factor of two, how much better is that? At what point is
the time dominated by other factors so the value from
further speedup is minor?
> Most especially NO 32-BIT ROTATIONS! Almost all
> the MAC algorithms I found use that, which is inordinately
> expensive on my platform, not counting the prefetch cycle
> time and other things like that; it requires at least four
> cycles for each one bit rotation, meaning that for SHA-1,
> the 80 35-bit rotations take an aggregate total of 11200
> clock cycles, provided I can find a way to place all the
> results that need rotation in the meager number of
> registers the x86 provides, which is highly unlikely...
So do the thirty-bit left-rotate as a two-bit right rotate.
Now we're down to 80 7-bit rotations - five times faster.
Of course there's lots of other operations, but there are
also lots of other optimizations. (On the 8051 the fast way
to do the five-bit left-rotate is, strange as this may seem,
with three nine-bit right rotates.)
I recommend you don't give up on SHA-1 until you really look
at your requirements and what speed you can attain.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Subject: For the Gurus
Date: Mon, 11 Sep 2000 20:13:37 -0400
If I wanted to design a simple manual system that I felt was very
difficult to crack, what historical system would you recommend I start
with and why?
What limitations would you place upon the system in a practical
application?
In your experience, what system in practical use, as a pencil and paper
system, offers the most security for the greatest ease?
Kindly bear in mind I am talking about a practical application of a
pencil and paper system for a non-wizard. This system will be applied
in the real world.
Please don't bother with OTP's. Though I have not eliminated that
system, key communciation is at times a difficult proposition.
-m-
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 17:14:15 -0700
Andy C <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
[snip]
> Thank you for this explanation of how the algorithm can be reversed from a
> known plaintext block. This begs the question - how does one go about
> guessing a "known" plaintext in any reasonable amount of time? Just
trying
> to get the thought processes in my head.
Actually, that depends on the plaintext traffic you're trying to recover.
If it's random data, well, there's no good way. If it's ASCII/English text,
guessing " the" (and other common quadgraphs) at every possible block should
work. If it's (say) an IP packet, there should be enough redundancy in the
IP header for you to get a good guess (especially if you know/guess the
source/destination IP addresses).
One obvious thing to ask: if you were doing a brute force attack, how would
you recognize the plaintext?
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Getting Started, advice needed (FAQs , yes I read them)
Date: Mon, 11 Sep 2000 17:27:58 -0700
Paul Pires <[EMAIL PROTECTED]> wrote in message
news:cI%u5.61866$[EMAIL PROTECTED]...
>
> Scott Fluhrer <[EMAIL PROTECTED]> wrote in message
> news:8phpk5$plr$[EMAIL PROTECTED]...
> >
> > Paul Pires <[EMAIL PROTECTED]> wrote in message
> > news:U_Yu5.60123$[EMAIL PROTECTED]...
> > > Why would anyone brute force the key. It seems to me that if
> > > you can be made to encrypt some known material at the
> > > beginning of a file, I get your key using only a pencil and
> > > paper.
> > >
> > > first tempKey = theKey;
> > >
> > > > temp1 = data[counter] + tempKey;
> > > > temp1 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > > > temp1 = ((temp1 << 23) | (temp1 >> 9));
> > > > tempData[counter] = temp1;
> > > > tempKey = tempKey + temp1 - 26087;
> > >
> > > Let's refrase the first cycle:
> > >
> > > temp1 = plaintext + the honest to god key;
> > > temp2 = ((temp1 << 19) | (temp1 >>13)) - 26087;
> > > temp3 = ((temp1 << 23) | (temp1 >> 9));
> > Actually, this should be:
> > temp3 = ((temp2 << 23) | (temp2 >> 9));
> >
> > > ciphertext= temp3;
> > > tempKey = tempKey + temp1 - 26087;
> > Actually, this should be:
> > tempKey = tempKey + temp3 - 26087;
> > Neither of these affect your attack materially...
>
> Sorry for the typo's. I finally found an easy one to respond to
> and was rushing like mad to post it before the real guns saw it :-)
No problem -- I know the feeling. "I gotta get this break out before Wagner
sees the post, and stomps the system flat..."
> > Actually, this attack can be strengthened somewhat, in that it can be
> > applied to any block (and, it relies on a known plaintext block, rather
than
> > a chosen one as you appeared to have implied). Suppose you know/guess
the
> > value of plaintext block 10. Then, you use the above attack to derive
the
> > value of tempKey at the start of the encryption of block 10. Then,
looking
> > at the last two steps of the iteration for block 9:
> >
[snip]
>
> Yep, that works too.
Actually, thinking about the system some more (yes, I don't have a life...
why do you ask?), the system is essentially:
C = F( P+K )
K += C + Const
where:
P is the plaintext block
C is the ciphertext block
K is hidden state, initialized to be the key
Const is -26087
F is an unkeyed invertible 32 bit->32 bit function
Finv is the inverse of F
All addition/subtraction is done mod 2**32
then,
Finv(C) - P = K
Then, if we have two adjacent ciphertext blocks C1, C2, then
Finv(C1) - P1 = K1
Finv(C2) - P2 = K2
K2 = K1 + C1 + Const
or
P2 - P1 = Finv(C2) - Finv(C1) - C1 - Const
Everything on the right side is known to the attacker, and so he can deduce
the arithmetic differences between any two blocks. Depending on the
characteristics of the plaintext (eg. if there is a checksum of all the
blocks at the end of the plaintext), this may make recovering it real
easy...
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Intel's 1.13 MHZ chip
Date: Tue, 12 Sep 2000 00:39:38 GMT
On Mon, 11 Sep 2000 13:18:54 -0400, "Abyssmal_Unit_#3"
<[EMAIL PROTECTED]> wrote, in part:
>MECL (Motorola Emitter Coupled Logic) architecture has been available for close to 25
>years with capability to perform at 1 to 2 gig
>rates.
Note, though, that ECL has much higher power consumption than CMOS,
and supports much lower chip densities. (It's worse than bipolar,
because it gains its speed by not driving its transistors to
saturation.)
Also, the 1 GHz speed of a microprocessor is for a machine cycle,
which involves many elementary logic operations. The figure you quote
may be the speed of individual NAND gates.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Tue, 12 Sep 2000 00:51:16 +0000
"root@localhost " wrote:
>
> If I wanted to design a simple manual system that I felt was very
> difficult to crack, what historical system would you recommend I start
> with and why?
First you need to decide what you mean by "very difficult to crack",
and from whom are you trying to keep it secret. Depending on their
resources, you may be trying to make it more difficult for them to
crack it with ciphertext-only than to thrash you until you tell
them what you said in the message.
You might try a combination of a good substitution and a good
permutation -- say the "double Playfair" (actually a sort of
periodic two-square) used by the Germans in WW2 followed
with a double incomplete columnar transposition.
Alternatively, start with the cipher used by Rudolf Abel and described
(for example) in "Kahn on Codes".
> What limitations would you place upon the system in a practical
> application?
Depends on the details of your implementation and key protocols.
> In your experience, what system in practical use, as a pencil and paper
> system, offers the most security for the greatest ease?
Those are conflicting requirements -- are you looking for where
those curves cross, or what? The Rudolf Abel cipher, for example,
is way up in complexity and quite a ways up in security, depending
on key choice. Things that are really simple to encipher by hand
are often fairly simple to decrypt by hand or by computer.
> Kindly bear in mind I am talking about a practical application of a
> pencil and paper system for a non-wizard. This system will be applied
> in the real world.
Give 'em a wireless Palm Pilot, a Freedom account and a modern cipher --
probably these days hand ciphers aren't cost-effective for anything
important.
Alternatively, you might expound a little more on why you've limited
the solution space in the way you have. What's the application, and
what's the threat model?
--
Jim Gillogly
Hevensday, 21 Halimath S.R. 2000, 00:37
12.19.7.9.15, 4 Men 18 Mol, Sixth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: MAC
Date: 11 Sep 2000 17:58:14 -0700
kihdip <[EMAIL PROTECTED]> wrote:
> Do you know how secure these 3G/UMTS algorithms are compared to 3xDES or one
> of the AES candidates ??
3DES has received 25 years of intense scrutiny; KASUMI has received much less.
I think it is clear that 3DES would be a much more conservative choice, all
else being equal. But, KASUMI has a reasonable pedigree as a variant of a
published cipher (namely, MISTY).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ExCSS Source Code
Date: Tue, 12 Sep 2000 00:42:45 GMT
On Mon, 11 Sep 2000 11:47:56 -0700, "David C. Barber"
<[EMAIL PROTECTED]> wrote, in part:
>Excuse me but, if we can put 2 full movies onto a 650MB CD, why do we need
>DVD in the first place?
We couldn't. MPEG-4, with its improved compression, only now just
barely allows a movie to fit on a CD. Of course, there is CD-Video,
but that offered inadequate video quality.
Anyhow, DVD is very useful for its large data storage capacity, even
just for DVD-ROM. Also, for pure audio, the 16-bit precision and 44.1
kHz sample rate of the audio CD are felt in some quarters to be not
quite satisfactory for the most discriminating audiophile.
Myself, I can't quite afford to run out and buy a Goldmund
Reference...
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
******************************
