Cryptography-Digest Digest #612, Volume #13 Fri, 2 Feb 01 09:13:01 EST
Contents:
Re: CipherText patent still pending (Richard Heathfield)
$$$ Change your life $$$ ([EMAIL PROTECTED])
Re: CipherText patent still pending (Mok-Kong Shen)
Re: CipherText patent still pending (Mok-Kong Shen)
Re: New checksum algorithm (Mok-Kong Shen)
Re: New checksum algorithm (Robert Scott)
Re: How good is Diamond2 and Saphire ciphers? (Rex Stewart)
Re: Where is the encryption hardware? (Benjamin Goldberg)
Re: How good is Diamond2 and Saphire ciphers? (Benjamin Goldberg)
Re: New checksum algorithm (Sami J. M�kinen)
Re: How good is Diamond2 and Saphire ciphers? (Rex Stewart)
Re: New checksum algorithm (Sami J. M�kinen)
----------------------------------------------------------------------------
Date: Fri, 02 Feb 2001 11:58:37 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Bryan Olson wrote:
>
<snip>
>
> Good as those questions are, when I read yet another report
> of the development of a new symmetic cipher, the first
> question I ponder is not one those, or others listed in the
> FAQ.
>
> Is is: Why?
>
> Does it solve some problem that other ciphers don't? Can
> they prove something interesting about this cipher that is
> not true of others? Is there some reason anyone should care?
>
> Are people so mis-informed as to think that a symmetric cipher
> for which no one produces an effective attack is an interesting
> or novel result? Or that there might be commercial potential
> for one? Or that a good learning exercise for a student is to
> design a cipher?
None of the above.
We do it because it's fun.
Of course, that doesn't mean that it's fun for everyone else on
sci.crypt to read about it. Some of us learn that, eventually. We know
we're not going to write a competitor to Rijndael (all right, AES) or
Twofish, but that doesn't matter. The idea of making an omelette out of
our bits, and then turning that omelette back into an egg /only if/ the
right magic words are uttered, is intrinsically fascinating. Once we've
done that, it's only natural (if a little child-like) to want to show
other people - "Look what I did! Isn't it /cooool/?" And who do we want
to show our achievement to? Well, obviously it should be to people
who'll understand it. Equally obviously, that means sci.crypt. (Yes, the
FAQs, but sometimes we're a bit too excited to remember to read them.)
In the midst of our natural joy of discovery, we tend to forget that
sci.crypt understands what we have achieved only too well. I first
posted my "CDX" algorithm here over a year ago (if I recall correctly).
It was torn into tiny little pieces (quite gently, to be fair) by a
couple of people. Since then, I've toyed with it occasionally, fixed
some stuff, added some stuff... it's a lot quicker than it was, and a
lot more secure than before. But I no longer ask people here to
cryptanalyse it. That's too dispiriting. If truth be told, you see, I
don't really want anyone to break it. I just want to pretend it's
unbreakable. I don't pretend that to anyone else, of course. The only
customer I have in mind for my snake oil is - me.
My symmetric cipher was a lot of fun to write. It was less fun to fix
after sci.crypt thumped it. It'll be still less fun to fix next time
round, which is why there won't be a next time round. If I went that
route, by the time I'd fixed every problem sci.crypt found with the
algorithm, it would end up looking just like everyone else's algorithm.
And where's the fun in that?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: [EMAIL PROTECTED]
Subject: $$$ Change your life $$$
Date: Fri, 02 Feb 2001 12:09:29 GMT
You are one click away from financial freedom. This is legit. It
worked for me, I hope it can do the same for you.
http://www.geocities.com/khourey_9/money.html?980136756130
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 02 Feb 2001 13:24:17 +0100
Bryan Olson wrote:
>
[snip]
> Are people so mis-informed as to think that a symmetric cipher
> for which no one produces an effective attack is an interesting
> or novel result? Or that there might be commercial potential
> for one? Or that a good learning exercise for a student is to
> design a cipher?
I suppose that the answer is yes to the third question,
like one writes compositions in school classes. With AES,
we presumably never need to really bother outselves anytime
anymore with symmetric ciphers, neither in theory nor in
design, at least for the comming several decades, if not
centuries (until big quantum computers come out, of course).
The same applies apparently also to asymmetric ciphers.
Possibly steganography could be an exception in this respect.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Fri, 02 Feb 2001 13:24:23 +0100
"Prichard, Chuck" wrote:
>
[snip]
> CipherText is a non-blocking symmetric cipher that uses two
> data-dependent key shifts. It can be made to effectively be resistent to
> known plaintext attacks based on it having an expandable keystring and
> whitener mask. The applied key and mask can exceed message length so that
> no pattern is discernible throughout a message string. This feature has
> been implemented and tested satisfactorily.
>
> The algorithm is effective at Perl and Java implemented demonstrations
> involving whitening in 7-bit encoded HTTP transmissions without a special
> filter.
>
> The algorithm is effective at recursively ciphering many short strings in
> an efficient manner. (As demonstrated in the PTE implementation on my PWS
> where the lookup table of thirty entry names is ciphered as each page is
> returned.) Actual use may require using precomputed static lookups
> created for each user if wait times accrue to an unsatisfactory length.)
>
> To explain the algorithm briefly, it uses the checksum-like attribute of
> the variable-length, 32 byte domain, root key to articulate the rotation
> of a modified version of the root key. The modified key (this is one
> data-dependent shift) can vary in length from the root (effectively
> expanding the root) so that in double ciphering, the pattern of applied
> ciphers will not repeat for a message of 100 characters when using just a
> 10 character key. Before the first cipher of each pass a second
> data-dependent shift is applied based on the key attribute value.
>
> A 96 byte domain whitener mask is then applied with XOR logic. The
> whitener can be derived from a known whitener applying a mask key. This
> is in effect a third cipher that randomizes the message dramatically.
>
> The result can be a short, ciphered message of only a few characters with
> the integrity to resist known plaintext attacks, and to find applications
> in the default internet HTTP and elsewhere.
I am afraid that your explanation is (due to the style
and terminology) fairly unclear. Anyway, my humble knowledge
doesn't enable me to make much out of the above. BTW, does
your data-dependent shift conflict with Hitachi's rotation
patents?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New checksum algorithm
Date: Fri, 02 Feb 2001 13:24:28 +0100
"Sami J. M�kinen" wrote:
>
> I wrote earlier:
> >for ( i = 0; i < n; i++ )
> >{
> > tmp = buffer[i];
>
> One improvment with one more XOR. tmp = buffer[i] ^ sum;
> - Should be much better.
Dumb question: What are the general criteria for
evaluating methods of obtaining checksums? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Robert Scott)
Subject: Re: New checksum algorithm
Reply-To: [EMAIL PROTECTED]
Date: Fri, 02 Feb 2001 12:36:19 GMT
On Thu, 01 Feb 2001 17:33:01 GMT, [EMAIL PROTECTED] (Sami J. M�kinen) wrote:
>I decided to design my first checksum algorithm (for non-crypto purpose),
>
>uint32 *buffer;
>uint32 i, tmp;
>
>sum = 1;
>
>for ( i = 0; i < n; i++ )
>{
> tmp = buffer[i];
> tmp = (uint32) (sum >> 29) + tmp;
> tmp = (uint32) (sum >> 17) + tmp;
> sum = (uint32) (sum << 3) ^ tmp;
>}
>
>return sum;
>
In what way is your checksum better (for non-crypto apps)
than the old-fashioned:
for ( i = 0; i < n; i++ )
{
sum = sum + buffer[i];
}
return sum;
..which would be even faster yet?
Robert Scott
Ypsilanti, Michigan
(Respond through newsgroups, not by direct e-mail.)
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Fri, 02 Feb 2001 12:46:23 GMT
In article
<[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Rex Stewart <[EMAIL PROTECTED]> writes:
> > Diamond2 is a classical substitution-permutation cypher
> > which although very strong, is not very fast. The cypher
> > was designed with strength in mind, but not much concern
> > for speed. In fact one of the positive aspects of this
> > cypher is the slowness of key setup - which takes several
> > million processor cycles. This increases the cost of
> > brute forcing the key (known as key strengthening).
>
> This is not a strength of any cipher. It is far more effective to use
> longer keys or otherwise add key entropy than to slow down the key
> schedule; where more entropy is not available (for example when
> handling passphrases), it's much better to use a separate routine for
> converting the passphrase to the key.
>
> Also, IIRC, this is key stretching, and key strengthening is throwing
> in a little extra random information into the key, forcing a little
> brute force attack on this unknown information at decrypt time.
> Though it has the same purpose as key stretching it is a different
> technique. See http://www.counterpane.com/low-entropy.html
Again, I am not a true cryptographer, but I have looked at both
stretching and strengthening (including the paper you mention),
and consider it a judgement call which to go with (and, IIRC,
the paper also considered it a judgement call - even though
the author agreed with you).
>
> > It has some similarities to RC4 but with an extra twist that
> > it feeds information from both the plaintext and the cyphertext
> > streams into the system. This allows it to be used repeatedly
> > with a single key, unlike standard stream cyphers.
>
> Not so; if the plaintext has the same prefix, the ciphertext will
> to. The correct way to provide this property is to use an IV, like
> CipherSaber.
You appearently have not used Sapphire. Starting with the
first changed byte, the rest of the ciphertext will be
different. While CipherSabre's technique may be superior,
this does *allow* reuse of a key without *destroying* the
security of that key. OTOH, I you mean the ciphertext up
to the first changed byte will be the same, I concur.
I realize in some situations this would be bad (even
disasterous) the problem is manageable if know ahead
of time.
>
> > While feeding back information from either plaintext OR
> > cyphertext streams is considered a dangerous practice - he
> > used both, which complicates attacks somewhat, and I don't
> > think anyone has come up with any useful attacks.
>
> It's still undesirable; if you avoid feedback then chosen-plaintext
> attacks are no more powerful than known-plaintext.
>
> You can use any secure stream cipher to construct a KG-style
> stream cipher by encrypting the stream of all zeroes. If
> this mode is insecure, the stream cipher is insecure.
Encrypting all zeros with Sapphire2 will not provide any
useful information about the internal state. (As far as
anyone can tell.
>
> > As for whether these cyphers are good for the future - it
> > depends on what you intend to use them for. No one (as
> > far as I know) is creating applications using these cyphers.
> > (The only aplications I know for Sapphire2 are ATBASH
> > and --- hmmm, drawing a blank right now, but I know there
> > were two others) OTOH - in the (eight or nine?) years since
> > they were presented to the cryptographic community, no one
> > has found any useful attacks based on either the cyphers
> > or the componets used to biuld them.
>
> TBH I see no reason to believe that a great deal of work has gone into
> attacking these ciphers; at the time, Blowfish or vanilla RC4 would be
> a clear better choice, and today there's no reason not to use
> Rijndael.
On this I agee completely, but that was not the question, and
considering the origin of the message, I was considering the
possibility there might be seperate reason for needing this
information (availablity, compatibility, or already in use
for some time).
> --
> __
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
>
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Where is the encryption hardware?
Date: Fri, 02 Feb 2001 13:15:12 GMT
wtshaw wrote:
>
> In article <[EMAIL PROTECTED]>,
> remove.nospam.in.address.to.reply wrote:
>
> > With all of the obvious benefits of strong cryptography in
> > preventing eavesdropping/identification and providing
> > tamper-resistant communications, I have but one question: why are
> > there no consumer communications products with real encrypted
> > transmission capabilities?
> >
> > As anyone knows, any monkey with a scanner and a little patience can
> > intercept most un-encrypted civilian communications. Since
> > civilians make up the bulk of the "consumer" market, why are
> > telecommunications devices such as network interface cards, faxes
> > and cellular phones not equipped with encryption hardware? Ed
>
> Simple question with a simple answer: The non-civilian part of out
> society knows that encryption can no longer be treated as transparent,
> convincing everyone that it is a waste of time. But, given that there
> is some really good theory at work in the crypto field, only crippled
> crypto has been allowed. How to put a governor, so to speak, on the
> technology is at the crux of their acceptance of useful crypto.
Although doing secure key exchange might not be transparent, the
symmetric part of encrypting transmitted data surely is. What prevents
cell phone makers from giving an option for the key to be in the clear,
and then encrypt the rest of the message? You'd have a selector switch
for "secure conversation" or "insecure conversation" and the "secure"
option would perform the annoying, slow, key exchange, and the
"insecure" option would still encrypt, but would send the key in the
clear. Since symmetric encryption is transparent, someone using a
connection that is "insecure" would see no noticable difference between
that and one which is completely unencrypted.
Why have an encrypted message with the key sent in the clear, you ask?
Simple: because if foils the monkey-with-the-scanner. Only by
intercepting the *start* of the conversation, and actually seeing the
key, can the listener decrypt the conversation. One of the important
functions of a scanner is just that-- "scan" through frequencies, and
find which ones are in use. If it doesn't see that a conversation is
happening until after it's started, [and if it can't see backwards in
time], it can't get the key.
Plus, of course, you would have the option of using a secure key
exchange / secure authentification -- although I expect that it wouldn't
get used in many/most cases. But if you can have *some* security, even
if it's trivially breakable for a professional, you'd go for it,
wouldn't you? Especially if it came with the option to turn on the
"strong" security features.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Fri, 02 Feb 2001 13:22:00 GMT
Rex Stewart wrote:
>
> In article
> <[EMAIL PROTECTED]>,
> Paul Crowley <[EMAIL PROTECTED]> wrote:
> > Rex Stewart <[EMAIL PROTECTED]> writes:
[snip]
> > > It has some similarities to RC4 but with an extra twist that
> > > it feeds information from both the plaintext and the cyphertext
> > > streams into the system. This allows it to be used repeatedly
> > > with a single key, unlike standard stream cyphers.
> >
> > Not so; if the plaintext has the same prefix, the ciphertext will
> > to. The correct way to provide this property is to use an IV, like
> > CipherSaber.
>
> You appearently have not used Sapphire. Starting with the
> first changed byte, the rest of the ciphertext will be
> different. While CipherSabre's technique may be superior,
> this does *allow* reuse of a key without *destroying* the
> security of that key. OTOH, I you mean the ciphertext up
> to the first changed byte will be the same, I concur.
> I realize in some situations this would be bad (even
> disasterous) the problem is manageable if know ahead
> of time.
Actually, it sounds like you could, with Sapphire, prepend the IV to the
message, and encrypt as normal. CipherSabre seperates the IV from the
message text, concatenates it with the secret key, and uses that as the
RC4 key. With Sapphire, there seems to be no reason to treat the IV
differently from the rest of the message.
--
A solution in hand is worth two in the book.
Who cares about birds and bushes?
------------------------------
Subject: Re: New checksum algorithm
From: [EMAIL PROTECTED] (Sami J. M�kinen)
Date: Fri, 02 Feb 2001 13:23:13 GMT
<[EMAIL PROTECTED]>:
>>I decided to design my first checksum algorithm (for non-crypto purpose),
>In what way is your checksum better (for non-crypto apps)
>than the old-fashioned:
>for ( i = 0; i < n; i++ )
>{
> sum = sum + buffer[i];
>}
>return sum;
>..which would be even faster yet?
1,1,2 = 2,1,1 = 2,2 and 4, all of those have the same checksum, or
are just being ironic?
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Fri, 02 Feb 2001 13:32:55 GMT
In article, Bryan Olson <[EMAIL PROTECTED]> wrote:
> Rex Stewart wrote:
> [...]
> > Sapphire2 (do not confuse with the original version, which
> > was shown to have a weakness) is a stream cypher which is
> > designed to be both fast, and moderately strong.
>
> I believe it was my attack on Sapphire that motivated the
> change to Sapphire II. I showed how to extract some
> information on the internal state using adaptive chosen
> plaintext with re-origination (that is, each chosen plaintext
> gets to start from the same initial state). I don't know just
> how far this could have been taken. I had already spent quite
> some time on it when Johnson changed the design, and then
> there was no longer any interest in the original Sapphire.
That is indeed the attach showing the weakness in the original
sapphire. I could have sworn he gave a different name, although
there could have been more than one person who saw the weakness,
since even I could see it (in hindsight).
>
> The changes introduced Sapphire II defeated the specific
> attack, and I determined that I'd have to start over to
> attack Sapphire II. I thought, and still think, that there's
> an ocean of analysis to do on adaptive re-origination against
> stream ciphers with feedback of small inputs.
The changes were specifically to thwart any re-origination
attacks (at least as I understand it - see disclaimer below).
There may indeed be an ocean of analysis yet to be
done on this subject.
>
> > I am not a professional cryptographer by any stretch of the
> > imagination, but I did a pretty thourough examination of this
> > cypher before I decided to use it.
>
> Do you know if anyone else attacked Sapphire? Johnson's paper
> presenting Sapphire II just says it was strengthened against
> an adaptive chosen plaintext attack.
Since I use Sapphire2 myself, I have watched for 5 years
specifically for any signs and have seen none. I have played
around with ideas, but have found none even useful enough
to mention.
>
> > It has some similarities to RC4 but with an extra twist that
> > it feeds information from both the plaintext and the cyphertext
> > streams into the system. This allows it to be used repeatedly
> > with a single key, unlike standard stream cyphers.
> >
> > While feeding back information from either plaintext OR
> > cyphertext streams is considered a dangerous practice - he
> > used both, which complicates attacks somewhat, and I don't
> > think anyone has come up with any useful attacks.
>
> I don't think anyone has really gone at it. The design with
> various bytes indexing others makes its workings highly
> confusing, but that only implies intellectual toil in finding
> attacks; it doesn't imply that those found will be
> intractable. Given the amount of time it took me to get a
> feel for the behavior of Sapphire, I doubt Johnson had a
> deep understanding of Sapphire II when he proposed it.
You are correct about it being somewhat confusing, but
considering he designed it before RC4 was revealed leads
me to believe he understands the inner workings plenty
well. OTOH, I am not to certain how much faith he would
still have in the design - eight(?) years is a long time
in the cryptographic field.
>
> I'd recommend that anyone using Sapphire II generate a unique
> random (or strong pseudo-random) session key per message, just
> as one would using RC4. Don't us it as a hash function. The
> adaptive attack with re-origination proved more powerful than
> expected against the original Sapphire, and Johnson produced
> the change too quickly for comfort. There's no significant
> new theory to Sapphire II that explains why it will be strong
> where Sapphire was flawed.
As I understood it, the attack on Sapphire was based on knowing
the values of the internal variables (other than the card deck)
ahead of time. The change makes them key dependant, and some of
them have a key dependant movement. I agree that using it as
an unkeyed hash could be risky, however, since then the internal
states would be known.
>
> --Bryan
>
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
------------------------------
Subject: Re: New checksum algorithm
From: [EMAIL PROTECTED] (Sami J. M�kinen)
Date: Fri, 02 Feb 2001 13:37:54 GMT
[EMAIL PROTECTED] (Sami J. M�kinen) wrote in
>>for ( i = 0; i < n; i++ )
>>{
>> sum = sum + buffer[i];
>>}
>>return sum;
>>..which would be even faster yet?
Okay, no need to explain. Of course, this is just with the different
operation, but the same thing really.
Now I feel even more stupid.
Regards,
Sami
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
