Cryptography-Digest Digest #55, Volume #9 Mon, 8 Feb 99 16:13:04 EST
Contents:
Re: 2048-bit block cipher ("Wm. Toldt")
Re: Foiling 56-bit export limitations: example with 70-bit DES ([EMAIL PROTECTED])
Re: Java random ("Else")
Re: Transforming RC4 into a one-way hash function ("hapticz")
2048-bit block cipher ([EMAIL PROTECTED])
Re: MAC generation (Uri Blumenthal)
Crypto-library ([EMAIL PROTECTED])
Re: Transforming RC4 into a one-way hash function (Dale Woodford)
Re: Metaphysics Of Randomness ("Tony T. Warnock")
Re: RNG Product Feature Poll (R. Knauer)
Re: Simple newbie challenge -- variable length codes (wtshaw)
Re: How to get gov't approval for crypto (wtshaw)
Re: Rational points on a curve (Jayant Shukla)
Re: What is left to invent? (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
----------------------------------------------------------------------------
From: "Wm. Toldt" <[EMAIL PROTECTED]>
Subject: Re: 2048-bit block cipher
Date: Mon, 08 Feb 1999 08:55:41 -1000
[EMAIL PROTECTED] wrote:
>
> //sorry for the misleading in announce about 65536-block cipher
> 2048-bit block cipher
>
> The size of the block is 2048 bits or 256 bytes.
> Inserted key is transformed to 256 bytes( effective key)
> using current encryption.
>
> There are two interpretations of the key. One of them
> is mentioned above in 16-bit chained encryption a sequence
> of automorphisms of a group. The second is the sequence
> of transpositions of bytes in block. Each byte of the key
> represents a simple transposition of bytes as follows:
> index of key byte is the index of the first byte in block and the
> context of the key byte is the index of the second byte in block.
> During encryption of the block the key is scanned from the
> beginning to the end and during decryption reverse.
>
> Encryption follows in two steps:
>
> 1. A block is encrypted using 16-bit Alex chained algorithm.
> This approach gives suitable dispersion of bytes in
> the block.
>
> 2. A transposition of all 256 bytes in block is made using
> 256 byte key.
>
> This algorithm is implemented and has performance apr.764 Kb/sec.
>
> The freeware executable, updated
> algorithm description are available for download at
>
> www.online.de/home/aernst
>
> Please follow the link for 'Alex16x2048.zip' in download area.
>
> Regards
> Alex
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
It is trivial to break your algorithm. If you want to know how, just ask.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Mon, 08 Feb 1999 17:25:12 GMT
In article <79j465$4ej$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
[snip]
> Ok -- actually, much more effective, 2^56 times more effective for DES.
I think it's closer to 2^(M-1) times more effective.
[snip]
> > If Mike knows
>
> STOP 1: No, not possible.
>
> How does Mike know? How can he be sure that the DES key AND the message are
> repeated if the unknown_key is different? Note: what DES key, what message?
> The only thing Mike can see are two entirely DIFFERENT byte strings C1 and C2
> -- and, what could he rationally deduce from two entirely different and
> random-looking strings?
When analyzing a cipher system, it is common practice to harden it against
impractical attacks (e.g., chosen-plaintext). Furthermore, you said that
M-DES could be implemented by adding the M-layer to any DES implementation,
in which case, you cannot control whether or not they might send the same
message twice with the same DES key, and you can't know if, or how, Mike
might know if this had happened.
[snip]
> STOP 2: No, nigh-impossible.
>
> ;-) Note that I was a bit "perverse" in my reply to you -- since I have been
> repeating this point but without being able to convey it, so I tried a more
> graphical way. Note that my previous text (that you quoted above) says
> specifically: "-- of course, using the protocol given in
> http://www.mcg.org.br/unicity.htm" ... thus, what does the M-DES protocol
> say? Surely this question must be asked, since you cannot say M-DES has a
> weakness if you provide Bob and Alice with a de-faced M-DES -- so, the given
> M-DES rules MUST be followed. At the given URL, it is written:
You can't force them to use your protocol if you implement the M- as a package
that will work with other people's DES.
[snip]
> >if you a) use a block cipher for the post-encryption,
>
> There is a subtle point here, which I believe was not properly stressed. Can
> you trust that block cipher? Can you guarantee it has no back-doors? The
> answer is of course NO in both cases.
You may have a point. There's also the "meet in the middle" attack to
consider.
> However, can you trust an XOR to be an XOR? Can you guarantee it has no
> back-doors? Clearly, YES in both cases.
No. I don't know how you chose your table of 2^M publically known "unknown
keys."
You are arguing that if I 1) publish a table of 16384 "random looking" 64-bit
blocks, 2) choose one of the blocks by generating 14 random bits, and 3) XOR
the block I chose with each block of a message I want to send, then this is
more secure than encrypting my message with RC5 and a 14-bit key. I'm not
sure I buy it.
[snip]
> > Each case is different, but if you propose to export a cryptosystem that
does
> > DES encryption with a 56-bit key, and then post-encrypts with an M-bit key
> > (with M not equal to zero), you WILL NOT get mass-market approval. It's
> > called "multiple encryption."
>
> No, it is NOT -- because the key in not known to anyone. It should not even
> be called "encryption" -- it is just encoding or scrambling. The sender is
> just destroying his ciphertext and not telling anyone how to recover it --
> both Alice and the attacker are gropping in the dark. However, Alice has the
> right to know the 56-bit key -- that much is allowed. And, that much is
> enough ;-)
You are free tp try that argument in an export classification request. My
opinion is that it is doomed to fail. You are essentially arguing out of
both sides of your mouth: "left-side") only 56 bits of secret key are
exchanged, "right-side") an attacker must brute-force a full seventy bits to
decode the message. Based on experience, I believe that the government will
pay attention only to the "right-side" of your mouth, and deny you
mass-market status.
[snip]
> No, I was just (off-topic) commenting that current US export rules are being
> "relaxed" (their terms) to agree with the US-proposed WA. And, the WA is much
> more clear in this regard (I believe you agree with this part) and easily
> classifies M-DES as export-free since there are only 56-bits of secret-key in
> the protocol.
I haven't been able to confirm your reading of the WA. As far as I can see,
it limits exports of products with greater than 56-bit keys. I guess the
some countries _could_ read it as not limiting M-DES, but I don't know if any
would, in practise.
[snip]
> The unknown-key is not a secret-key because its knowledge is not necessary
> before that exact protocol begins -- this sufficient to desqualify it as
> encryption for export purposes. In fact, the unknown-key is part of the
> message and anyone is entitled to keep received messages private unless a
> legal warrant is properly issued. And, I guess I must wait until eternity`s
> end to see a regulation that will try to define what people ignore (ie,
> cannot know).
Like I said, I don't know how this argument would fly in other countries, but
I strongly suspect it would fail in the U.S.
> > For example, you could get export approval for software that encrypts
> > a file with 56-bit DES, places it in an accessible location on the web, and
> > securely transmits the DES key to Alice. Now, if Alice retrieves the file
> > during an SSL session, the multiple encryption is not the fault of any of
the
> > software packages used, so the fact that this can happen does not, by
itself,
> > make any of them un-exportable.
> >
>
> This is a good example -- but the file was NOT safe en route to that web
> location.
You could put it there during an SSL session, too.
[snip]
> First, as I said, anything-key can be exported from where I am, so I can make
> M-DES into a full application and offer worldwide download -- note also that
> even though M-DES is not in public-domain (see the notice in the MCG site) it
> is certainly publicly-known. Thus, this entire question of "how to export
> M-DES" is theoretical at best.
Yes, but it's the main question you're trying to address, isn't it?
Otherwise, you could just use 70-bit RC5, or a 70-bit variant of 3-DES, etc.
In fact, what do you think of doing 3DES EDE with K1 and K3 both being the
DES key that you and Alice agreed on, and K2 being a 56-bit DES key selected
from a publically-known table of 2^M randomly generated "good" DES keys?
> However, if everyone worldwide would right now forget all that I and everyone
> else already wrote on this (so that I could not claim it is publicly known), I
> would not write any books on it (a la PGP) and if I would start making it
> available only from the US, still I could just offer a software for packet
> scrambling with an unknown-key before transmission. And, a software for packet
> blind-recovery on reception. Which could turn ANY DES software into M-DES.
Do you mean to implement M-bit unknown-key link-encryptors? Because of the
holes in the notion of multiple-encryption, it may be possible to set up a
56-bit VPN, and then act like you didn't know it was there and exchange 56-bit
encrypted messages (encrypted by your mail-handling software) over the VPN
(encrypted again by the VPN).
You'd have to be careful if you mean to have the 56-bit mail-handling package
actually call the M-bit post-encryptor, because this is likely to be
considered multiple-encryption and/or crypto-with-a-hole.
[snip]
> I suggest we discuss it when the full protocol is presented. The example
> given and the case for 70-bits were just to exercize the issues. Far better
> protocols are possible -- and, yes, what you say of using more than one DES
> is also an alternative discussed in the paper. The idea of forcing one to use
> information from all blocks has also its merits and Tony has suggested a
> Global-XOR function for that -- but it cannot work with streaming data and is
> easily stopped in a DoS attack that strips out just one block. Thus, there
> are more to it than this 70-bit M=DES exercize intends to handle.
Good points.
--
Peter
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Else" <[EMAIL PROTECTED]>
Subject: Re: Java random
Date: Mon, 8 Feb 1999 21:28:22 +0300
>Well, ok, this surprises me, but without knowing more about your
>situation I can't make concrete suggestions about SSL vendors.
If you look at the domain I am posting from, you won't be that surprized.
>Well, SSL normally runs at the native level, where it has access to
>better sources of entropy. Whether it does a good job with them is
>another matter (Netscape 1.0 had a famous bug relating to this).
That's what I meant.
>Btw2, here's a thought that might be bogus. A gaussian distribution
>often means that the variable is the sum of a bunch of other random
>variables that are not gaussian. I wonder if counting for shorter
>intervals might
Interesting thought. You know, it just might be that - counter runs "in
chunks" - gets a time slice and increments like mad, then yields.
------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Re: Transforming RC4 into a one-way hash function
Date: Mon, 8 Feb 1999 14:19:32 -0500
thats generally the use of hash procedures, to provide a "one-way"
encryption of info. other hash methods will/can offer better/lesser
"scrambling", but if you are not involved in some delicate or restricted
information situation where the absolute anonymity is the highest priority,
then your method should be effective.
passing the cookie data thru the net should be a trivial exchange with no
need for subsequent use of secure methods. as long as there is no
concurrent use/exchange of other identifiable information associated with
the cookie data exchange, then the relative safeguards you have provided
will be of use.
& as long as your data base remains current against the users email
addresses, it should be adequate for your use.
--
best regards
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: 2048-bit block cipher
Date: Mon, 08 Feb 1999 09:28:26 GMT
//sorry for the misleading in announce about 65536-block cipher
2048-bit block cipher
The size of the block is 2048 bits or 256 bytes.
Inserted key is transformed to 256 bytes( effective key)
using current encryption.
There are two interpretations of the key. One of them
is mentioned above in 16-bit chained encryption a sequence
of automorphisms of a group. The second is the sequence
of transpositions of bytes in block. Each byte of the key
represents a simple transposition of bytes as follows:
index of key byte is the index of the first byte in block and the
context of the key byte is the index of the second byte in block.
During encryption of the block the key is scanned from the
beginning to the end and during decryption reverse.
Encryption follows in two steps:
1. A block is encrypted using 16-bit Alex chained algorithm.
This approach gives suitable dispersion of bytes in
the block.
2. A transposition of all 256 bytes in block is made using
256 byte key.
This algorithm is implemented and has performance apr.764 Kb/sec.
The freeware executable, updated
algorithm description are available for download at
www.online.de/home/aernst
Please follow the link for 'Alex16x2048.zip' in download area.
Regards
Alex
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Uri Blumenthal <[EMAIL PROTECTED]>
Subject: Re: MAC generation
Date: Mon, 08 Feb 1999 14:44:53 -0500
Richard Parker wrote:
> You might want to take a look at the research of Bellare, Canetti,
> and Krawczyk. They've done a number of papers on using keyed hash
> functions to do message authentication. Try the following URL:
>
> <http://www.research.ibm.com/security/keyed-md5.html>
>
> They recommend the following construction:
> H(K XOR opad, H(K XOR ipad, text))
Absolutely. This construct is called HMAC and is mandated in
all the new IETF-blessed protocols using MAC. Also, it is
strongly recommended to use SHA-1 (rather than MD5),
even though there is no known attack on HMAC-MD5.
------------------------------
From: [EMAIL PROTECTED]
Subject: Crypto-library
Date: 08 Feb 1999 19:33:50 +0100
I am looking for a public key crypto library that can
be commercially used, i.e. non-GPL or commercial libraries
Has anybody experiences with the following libraries:
RSAEuro (http://www.repertech.com/RSAEuro/)
(offers a non-enduser based licence)
Cryptix (http://www.cryptix.org/)
SSLeay (http://www.psy.uq.oz.au/~ftp/Crypto/ssleay)
PGP Software Development Kit
(enduser based licence)
SECUDE Software Development Kit
(enduser based licence)
Thank you for any hints,
Juergen
--
Dipl. Inf. Juergen Weber
* Remove the .nospam to get my Email-Address *
------------------------------
From: Dale Woodford <?@?.com>
Subject: Re: Transforming RC4 into a one-way hash function
Date: Mon, 08 Feb 1999 11:24:52 -0800
Michael Kjorling wrote:
> If I encrypt a string with RC4 and a random key (both length and content),
> then XOR the output bytes together so I get a string of, let's say, 16 bytes
> out of the ciphertext, and then stores this value; will it be secure?<snip>
> Thus, "f0ea62c3b1a7e3abb9e5ace0c73ae38d" stored in the cookie would,
> perhaps, map to my email address ([EMAIL PROTECTED]).
>
> Would this work? Is it secure against attacks? I simply wants it to be
> computionally infeasible to derive the e-mail address from the nonsense stored
> in the cookie....
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Mon, 08 Feb 1999 08:43:55 -0700
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
> On Fri, 05 Feb 1999 15:35:58 -0700, "Tony T. Warnock"
> <[EMAIL PROTECTED]> wrote:
>
> >> Maybe you need to tell Greg Chaitin something he doesn't know.
>
> >No, I'm telling you something you don't know.
>
> So what you are saying is that Chaitin is wrong when he claims that
> Champernowne's number is not normal except in base 10.
>
> I guess I need to be more discriminating.
>
No
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: RNG Product Feature Poll
Date: Mon, 08 Feb 1999 17:38:59 GMT
Reply-To: [EMAIL PROTECTED]
On 8 Feb 1999 09:23:44 -0500, [EMAIL PROTECTED] (Herman Rubin)
wrote:
>The decay rate, even if there is no subatomic interference, still
>changes. After an atom decays, there is one less atom.
That depends on what you are calling the "decay rate". If it is the
half life then it never changes, even if there is only one nucleus
left. It is an intrinsic property of the isotope, related to the width
in energy of the excited state from which the decay occurs.
Radioactive decay follows a first order rate process:
dN/dt = - k N,
where N(t) is the instantaneous population of undecayed nuclei, and k
is a constant. The solution to that differential equation is N(t) =
N(0) exp[-kt], where N(0) is the population at t=0.
The constant k is the probability that any given nucleus will decay in
the time interval t -> t + dt. Since the decay process is completely
indeterminant ("random"), that means that k is a constant which does
not depend on the time, t. Furthermore, the half life of the isotope
is related to k.
The energy spectrum of the gamma rays produced by the decay process,
(as measured by the Mossbauer effect, for example) is a Lorentzian
line shape, which is exactly what you expect from the Fourier
transform of the exponential in time.
So you could work this the other way starting with the Lorentzian that
comes from second order perturbation theory, and do the Fourier
transform to get the exponential in time, with k = const.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple newbie challenge -- variable length codes
Date: Mon, 08 Feb 1999 13:22:22 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
> wtshaw ([EMAIL PROTECTED]) wrote:
> : It would be better to use a higher base than two, to make the scheme
> : practical. The next higher being base three, consider a couple of old
> : ciphers that are relative to your question:
>
> That's only true if you're using pencil and paper. In general, the smaller
> the size of the base, the more secure this cipher will be, because the
> patterns will be better concealed.
>
Not necessarily, if, as suggested, combinations of letters are given their
own special codes, it matters not what number system is used. The pattern
is actually easier to hide if you have several ways of indicating the
beginning and ending of strings, or have them absolutely defined. Higher
bases give you more options in fewer characters
Some sort of running frame reset should be included, I simply use the
plain zero to do it as an example with base three.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How to get gov't approval for crypto
Date: Mon, 08 Feb 1999 13:38:33 -0600
In article <79ikb1$dvf$[EMAIL PROTECTED]>, "Tim Mavers" <[EMAIL PROTECTED]> wrote:
> I have been working on an Internet chat program that uses encryption (via
> PKI) to provide secure communications. It is not ready to be released yet,
> but hopefully soon. I have been following some threads here about the gov't
> restrictions and was wondering how someone (just an individual programmer)
> goes about getting gov't approval to distribute a program with encryption.
The government is like a fickle woman, who decides how she will behave
according to her immediate needs rather than considering yours. This is
not aimed at the people given the job of enforcing stupid policies and
regulations, pardon me Claire. After the reshuffle to Commerce, I have
not called to see who answers the phone.
>
> The program currently uses the legal 56 bit crypto (when I say legal, I am
> going from what I have read, I have never been formally given any documents
> that say either way what is legal and what isn't).
Same comment as above.
>
> Does the NSA or commerce dept have to approve it? Let's say I want to up
> the cypher strength? How do I go about releasing it? Or even can I? When
> I say release, I would to have it readily available for downloading in some
> form.
Special web sites have been used to distribute domestically, but always
seem to leak in one or more ways. Like any lengthy file, some space
saving compressed form is best. Good luck if you wish to make a
controlled site.
>
> It sounds as if the gov't is very strict on the export limitations of
> crypto. Do I need to seek advice from a lawyer? I really don't know what
> the definition of "legal" code is. It seems kind of strange that an
> individual programmer has to go through so much.
Same comment as earlier paragraph.
>
> It's almost as if it's against the law to write certain types of code.
Not specifically as to crypto, but some in government would like that too,
as well as anything else that might limit your ability to frustrate their
efforts to do as they damned will please with your rights.
>
> Can anyone help or point in the direction I need to go?
>
Keep writing and talking about it. Unless you have a developed product,
looking for improvements, etc., you can do nothing with it anyway. Don't
let your programming effrts be discouragedl And, we keep pressing for a
window to be able to distribute what we want, something that might
temporarily open and close; it is better to have to goods to distribute
if the window is found sufficiently open at some point.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Rational points on a curve
Date: 8 Feb 1999 19:51:58 GMT
[EMAIL PROTECTED] writes:
>This is a genus 0 curve . Solving it by classical methods is trivial.
>Hint: solve your equation for x. Look at the discriminant. For a
>rational solution the discriminant must be a square. This will yield
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This statement is incorrect. For example, if:
x^2 - 2914 x - 363455 = y^2
The discriminant is not a square! But if x = -120 you get
y = +-25. Voila! Integer solutions.
I think you under estimated the difficulty of the problem.
Anyway, I found the solution. Take a look at the web site:
http://members.tripod.com/~alpertron/METHODS.HTM
regards,
Jayant
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Mon, 08 Feb 1999 20:47:06 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Feb 1999 19:28:05 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>>OTP remains provably secure.
>I would say that the only "provably secure" OTP is one for which we
>have a provably random source.
>But there *is* *no* PROVABLY random source.
>So there *is* *no* PROVABLY secure OTP.
>The PROVABLY secure OTP is a goal, a dream, a theory -- which can only
>PROVABLY protect theoretical data.
What if I generated a pad by flipping a perfectly symmetric coin - one
machined to high precision with the same amount of scant markings on
each face to indicate 1 or 0? Wouldn't the sequence I generated with
that coin be proveably random?
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Mon, 08 Feb 1999 20:54:11 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Feb 1999 19:28:59 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>This may be combining two concerns: first to acquire the uniqueness
>which exists in expression, and second to prevent the identification
>of the presumably known source text. The second we can achieve by
>throwing away information, and the first is best achieved by using the
>larger character representation, and not just the lsb's.
I do not understand what you have just said wrt the LSB's. Why would
using larger character representations be preferably to using LSBs?
>Of course, a bad generator
>which we cannot detect appears to be a good generator, and we will
>reject it 1 percent of the time, just like any other good generator.
That was exactly my point with regard to bad generators.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
** 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
******************************
