Cryptography-Digest Digest #221, Volume #9 Wed, 10 Mar 99 23:13:04 EST
Contents:
Re: Really Nonlinear Cipher Idea (Jayant Shukla)
Re: RC4 in PGP (Jim Gillogly)
Finite Field with Hard Division? (Anonymous)
Re: Scramdisk newbie (brandon)
Re: Does RC4 have the same problems as OTP? (Jim Gillogly)
Re: Does RC4 have the same problems as OTP? (Jim Gillogly)
CipherSaber question ([EMAIL PROTECTED])
CipherSaber question ([EMAIL PROTECTED])
Re: Does RC4 have the same problems as OTP? (Lloyd Miller)
Re: Really Nonlinear Cipher Idea (Sundial Services)
Re: Really Nonlinear Cipher Idea (Boris Kazak)
Re: My Book "The Unknowable" ("james d. hunter")
AES2 papers now available at NIST (David Crick)
Re: CipherSaber question (Jim Gillogly)
Re: Another extension to CipherSaber (Paul Rubin)
RC4 in PGP ([EMAIL PROTECTED])
Re: Really Nonlinear Cipher Idea (Boris Kazak)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: Really Nonlinear Cipher Idea
Date: 10 Mar 1999 23:13:21 GMT
Boris Kazak <[EMAIL PROTECTED]> writes:
> Combining various ciphers, on the other hand, should be data-dependent,
>so that each plaintext would be encrypted along its own unique path.
and how will you know how to decrypt the cipher-text if
the unique path depends on the plain-text? There is a reason why
all ciphers have fixed operation sequence.
> Thus in addition to the variability of the key you are also using the
>variability of the plaintext, making the analyst's work accordingly
>more difficult.
at the cost of making your own work impossible!
~Jayant
p.s.: don't suggest that cipher-text include the unique path to
help during decryption. ;-)
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: RC4 in PGP
Date: Wed, 10 Mar 1999 16:11:52 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Just a question if RC4 is really simple and easy, why is it not in PGP
> (likewise for RC5/6). Or is it the patent thing?
Different versions of PGP support different ciphers. You can use
RC4 in your own OpenPGP-compliant program by defining it as a Private
or Experimental cipher (ID 100-110). With good enough reasons, you
might be able to harangue the OpenPGP mailing list into accepting it
as one of the standard ciphers, as has (almost?) been done recently
in the assignment of Twofish to ID 10. The ciphers available in PGP
have accreted and changed gradually over the years. The first version
used the cipher Bass-o-Matic, which is -- to put it politely --
deprecated these days. Next came IDEA, which (with the public key
version of RSA) came with intellectual property baggage. Now, with
the advent of RFC 2440, you can choose from a handful of other
pre-defined symmetric algorithms, all block ciphers. There are enough
free choices that there's no particular incentive to put encumbered
ones into the standard. RC6 will be assigned ID 7-9 (with different
keylengths) if it wins the AES bun-fight.
> BTW, what are the actual restrictions on RC4/5/6? RSA didn't reply! So is
> the patent only valid in the states?
Give 'em time! Have you ever known an attorney to give you an
answer in less than a few days?
--
Jim Gillogly
18 Rethe S.R. 1999, 23:56
12.19.6.0.3, 11 Akbal 16 Kayab, Third Lord of Night
------------------------------
Date: Thu, 11 Mar 1999 01:20:57 +0100 (CET)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Finite Field with Hard Division?
Crossposted-To: sci.math
Is there a finite field where addition and multiplication
are easy, but there is no known algorithm for finding
multiplicative inverses in polynomial time?
Is there a trapdoor form of this, where division is hard
if you don't know the secret (e.g. the factors of some
large composite), but easy if you do know the secret?
------------------------------
Date: 11 Mar 1999 00:34:32 -0000
From: brandon <[EMAIL PROTECTED]>
Subject: Re: Scramdisk newbie
=====BEGIN PGP SIGNED MESSAGE=====
Thanks Aman for a very lucid explanation, but especially for the time you took.
Coming from a product development background in a well-known consumer
electronics company, I often find that even basic terminology and concepts are
either half-understood, or totally misunderstood...with hilarious consequences.
The fact that a good explanation (like your one) is so hard to come by, is both
a cause and symptom of this problem.
I think there is a risk that an inexperienced user of Scramdisk who follows the
instructions for 'Creating An Encrypted Partition' could end up unintentionally
reformatting his hard-drive. Because the confirmation window advises that data
and programs will be lost in the 'disk partition' (which of course is correct),
but the user mightn't realise that the selected disk partition is his entire
drive (if that is what he's selected because he doesn't know any better).
Anyway, as I said, your explanation was very clear, and therefore I think it
would be a good idea to pop something like this into the manual.
So thanks again, especially for the program.
Regards
Brandon
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Thu Mar 11 00:34:24 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBNucPl05NDhYLYPHNAQEaOgf+Kvf6iji7mzLECZy+tAiQydAH9fJpGB7n
/xrZDHel3LFSwAbFR+cFZYIfidi3aScUfsW9NVFDkSfByx/awu2cZCUTwpqyy9dB
Zay4Zx4xYYIi2unQ8QWHeehw58DxL0+JERaF3F/uCvA6ELEF1Vi0b/DzNQivrWWb
1hBqacCfDdLdKr2X1MtEra3h+a6bEroxDt40FwfrIVhm3YM/kx3DXgPZsQlzE78n
DWvJnkx0XuoQw4483D27dzgAETRFpOL6DmtFt8XEomTnMDWsX5kAwWM/JwqVctOo
F3OKI1KSMGRnWzl6wBBM3JiLwVkgjD9bUPwQi2khHhrESn5SGb72sw==
=WjKc
=====END PGP SIGNATURE=====
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Does RC4 have the same problems as OTP?
Date: Wed, 10 Mar 1999 16:40:10 -0800
Reply-To: [EMAIL PROTECTED]
Lloyd Miller wrote:
> It seems the situations where 40 bits might be enough is where you
> choose the salt systematically (even sequentially) to avoid
> duplicates. For random salts you need twice as many bits to avoid
> collisions. Would sequential salts expose related key problems tho?
> One might still be able to perform a transformation on the sequential
> salt to mask the relationship and still avoid collisions.
Given sufficient care, this kind of thing works. Unlike the random salt
case, you would need to take a great deal of care if there are two or
more nodes in your network: either each needs their own encryption key,
or you need to have some central authority kick in and force a key
change when two of their sequential ranges gets close (and of course if
you go through all 2^40 salts). You also need to be careful in error
cases. And yes, if the cipher you're using has any sensitivity to
related keys, using this method without suitable hashing would give a
lovely wedge to the enemy cryptanalyst.
Seems like having a predictable salt might also open you up to certain
spoofing or replay attacks, though no good ones spring to mind at the
moment.
How much trouble and analysis are you willing to do to save a few
bytes per packet of bandwidth and a few bytes of your randomness
pool?
--
Jim Gillogly
19 Rethe S.R. 1999, 00:28
12.19.6.0.3, 11 Akbal 16 Kayab, Third Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Does RC4 have the same problems as OTP?
Date: Wed, 10 Mar 1999 16:42:50 -0800
Reply-To: [EMAIL PROTECTED]
Michael Sierchio wrote [regarding RC4 and ESP]:
> Using SKIP on a 100-BASE-T net, I get about 80% of unencrypted throughput
> using RC4-128, and about 70% using DES-CBC, IDEA, SAFER-128-SK, etc.
> The difference is greater on big, fat streams, like video or audio.
Very nice! Using beefy hardware for the encryption? Hand-bummed ASM?
--
Jim Gillogly
19 Rethe S.R. 1999, 00:41
12.19.6.0.4, 12 Kan 17 Kayab, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED]
Subject: CipherSaber question
Date: Thu, 11 Mar 1999 02:14:33 GMT
What gains re: strength or difficulty in deciphering would be
made by taking a text enciphered with Arnold Reinhold's Ciphersaber
and enciphering again (same program) with a different key?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: CipherSaber question
Date: Thu, 11 Mar 1999 02:14:32 GMT
What gains re: strength or difficulty in deciphering would be
made by taking a text enciphered with Arnold Reinhold's Ciphersaber
and enciphering again (same program) with a different key?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Lloyd Miller)
Subject: Re: Does RC4 have the same problems as OTP?
Date: Thu, 11 Mar 1999 00:04:38 GMT
It seems the situations where 40 bits might be enough is where you
choose the salt systematically (even sequentially) to avoid
duplicates. For random salts you need twice as many bits to avoid
collisions. Would sequential salts expose related key problems tho?
One might still be able to perform a transformation on the sequential
salt to mask the relationship and still avoid collisions.
Jim Gillogly ([EMAIL PROTECTED]) wrote:
: Kent Briggs wrote:
: > 160 bits sounds like massive overkill for salt. Unless you are planning
: > on sending more than a trillion messages encrypted with the same key,
: > 40 bits will probably do in most situations.
: Eek! That means with 1.2 million messages there's a 50% chance you've
: picked the same salt twice. That "trillion" ignores the birthday
: paradox. For many applications (e.g. IP messages in a router) you
: could run up that kind of traffic (1.2 million) in a hurry. I picked
: 160 so that the square root of it would be substantially bigger than
: you want to store for a birthday attack. I grant that for modern
: systems 128 bits would be enough, and even 64 bits would be a severe
: nuisance to archive enough for a birthday search, but 40 bits is too
: close to the hairy edge for my taste. I prefer a little more headroom
: on my systems, especially since it's not much more expensive to gather
: 160 bits than 40.
--
Lloyd Miller, Calgary
[EMAIL PROTECTED]
Terminal Insomniac
------------------------------
Date: Wed, 10 Mar 1999 19:41:21 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Really Nonlinear Cipher Idea
Jayant Shukla wrote:
> > Thus in addition to the variability of the key you are also using the
> >variability of the plaintext, making the analyst's work accordingly
> >more difficult.
>
> at the cost of making your own work impossible!
Also consider the pos%ibility that a slight transmission error somewhere
in your data, like the "blip" in the fourth word of this sentence, could
render your plaintext unrecoverable by its intended recipient. Garbles
do occur. They can also be deliberately introduced.
Cryptosystems have to serve more than the simple need for baffling
security.
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Really Nonlinear Cipher Idea
Date: 11 Mar 1999 02:37:36 GMT
Reply-To: [EMAIL PROTECTED]
Jayant Shukla wrote:
>
> Boris Kazak <[EMAIL PROTECTED]> writes:
> > Combining various ciphers, on the other hand, should be data-dependent,
> >so that each plaintext would be encrypted along its own unique path.
> ..................
> at the cost of making your own work impossible!
>
> ~Jayant
>
> p.s.: don't suggest that cipher-text include the unique path to
> help during decryption. ;-)
==================
And why not? CAST and Blowfish work exactly like this. I took the
liberty to make the "drunken" versions of FEAL-8 and MMB, they work
fine in this mode. It all boils down to setting up a big array of
S-boxes and then executing the data-determined table lookups.
The final XOR-ing for "whitening" hides the traces.
Respectfully BNK
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics,sci.logic
Subject: Re: My Book "The Unknowable"
Date: Tue, 02 Mar 1999 11:35:34 -0500
Reply-To: [EMAIL PROTECTED]
R. Knauer wrote:
>
> On Tue, 02 Mar 1999 10:08:12 -0500, "james d. hunter"
> <[EMAIL PROTECTED]> wrote:
>
> > What most people 'know' generally goes under a heading
> > of personal information. Its 'secrecy' is important
> > mostly from a legalistic, proprietary rights, & decorum
> > point-of-view rather than 'earth shattering news'
> > point-of-view.
>
> Are you saying that you do not accept the reality of objective truth?
>
> If so, that means you reject Realism as a worldview, which in turn
> means you reject Western natural science.
No. I didn't say that I didn't accept the reality of
objective truth. It is -because- that I accept the
reality of objective truth that what individual's know
does not make the earth stop turning, no matter
what they think "randomness" means.
---
Jim
------------------------------
Date: Tue, 02 Mar 1999 18:29:52 +0000
From: David Crick <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: AES2 papers now available at NIST
All 28 papers can now be downloaded in PDF format from:
http://csrc.nist.gov/encryption/aes/round1/conf2/aes2conf.htm#papers
Combined they total 4.25 MB
My thanks to NIST on their sensible decision to make them available
prior to the conference and indeed the end of the Round 1 comment
period.
David.
--
+---------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC '96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| Brundle Quotes Page: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Key: (RSA) 0x22D5C7A9 00252D3E4FDECAB3 F9842264F64303EC |
+---------------------------------------------------------------------+
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: CipherSaber question
Date: Wed, 10 Mar 1999 19:00:57 -0800
[EMAIL PROTECTED] wrote:
> What gains re: strength or difficulty in deciphering would be
> made by taking a text enciphered with Arnold Reinhold's Ciphersaber
> and enciphering again (same program) with a different key?
Since we don't have a good way to break RC4 with a well-chosen
keyphrase, the answer is:
strength: just as strong.
difficulty in deciphering: it would be twice as annoying for
the legitimate decryptor.
If you ignore the instructions at http://ciphersaber.gurus.com
and pick terrible keyphrases, the strength would be the sum of
the key lengths... but why not just pick good keys at first?
--
Jim Gillogly
19 Rethe S.R. 1999, 02:54
12.19.6.0.4, 12 Kan 17 Kayab, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Another extension to CipherSaber
Date: Thu, 11 Mar 1999 03:24:15 GMT
In article <7c6s7g$i3k$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>>I agree that running the cipher for a
>> while is similar to re-running the key setup, though not the same.
>> Re-running the key setup with the same original key uses the key closer
>> to the final output, which may leak info about it.
>
>I find that argument a bit weak. In standard RC4, why not stop adding in the
>key after all the key bytes have been used once? Would that make it stronger?
Standard RC4 does stop adding in the key a while before output starts
actually getting used.
>I think both methods are valid. The one big virtue of discarding bytes is
>that one can claim one is using standard RC4. I need a stronger reason than
>that to change.
Standard rc4 has withstood at least some cryptanalysis. Nonstandard rc4
basically hasn't. It's breaking with a standard that needs a strong reason.
Do you have a strong reason to not follow normal practice?
I continue to feel uncomfortable with CS1's key setup (passphrase plus
salt, especially a short salt). I want to reopen the request to increase
the salt to 20 bytes. I'm not so concerned about birthday collisions
as about possible related key attacks. With a long passphrase and a short
salt, the salt can affect a fairly small portion of the initial S-box.
Again, discarding some output or repeating the key setup a few times
will help with this. So CS2 might be ok with 10 bytes of salt.
>> Also, I can't comprehend why anyone thinks re-running the key
>> initialization is simpler. Both are trivial. You already have to be
>> able to do both the key setup and output generation; so throwing away
>> N bytes of output (usually N=256) is no more complicated than running
>> the setup N times.
>
>I don't want to quibble, but what is trivial for an experienced programmer is
>another hurdle for a novice.
I find this completely bizarre. I'm not saying that discarding output
is 1.01 times as difficult as repeating the key setup and then disagreeing
with you about whether the extra .01 is significant or not. I'm saying
it's 1.0000 times as difficult: exactly the same whether the programmer
is novice or expert. Maybe the instructions need to be modified if
novice programmers are getting confused about what it means to discard
some bytes.
>I do plan to add something to the page about hex as the standard for ascii
>armor.
I agree with this.
------------------------------
From: [EMAIL PROTECTED]
Subject: RC4 in PGP
Date: Wed, 10 Mar 1999 23:24:33 GMT
Just a question if RC4 is really simple and easy, why is it not in PGP
(likewise for RC5/6). Or is it the patent thing?
BTW, what are the actual restrictions on RC4/5/6? RSA didn't reply! So is
the patent only valid in the states?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Really Nonlinear Cipher Idea
Date: 11 Mar 1999 03:38:57 GMT
Reply-To: [EMAIL PROTECTED]
Sundial Services wrote:
>
> Also consider the pos%ibility that a slight transmission error somewhere
> in your data, like the "blip" in the fourth word of this sentence, could
> render your plaintext unrecoverable by its intended recipient. Garbles
> do occur. They can also be deliberately introduced.
>
> Cryptosystems have to serve more than the simple need for baffling
> security.
===================
Any cipher which has the "avalanche" property is vulnerable in this
sense. And I do not suggest making the data-dependent choices across
several blocks. Each block will be encrypted independently from the
other, so the "blip" will affect only this block.
Although there are posters who advocate *all-or-nothing* encryption,
I am not a fan of it. I know very well, how the communication errors
happen, and I fully understand the validity of your concerns.
To put it more precisely, each block of the plaintext will be encrypted
along its own unique path, and the ciphertext block will provide
information
about the reverse path for decryption.
Best wishes BNK
------------------------------
** 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
******************************
