Cryptography-Digest Digest #220, Volume #10 Sat, 11 Sep 99 10:13:02 EDT
Contents:
Re: Looking for Completely-Free Strong Algorithms (Bill Unruh)
Re: Stream cipher from a hash function (Bill Unruh)
Re: Stream cipher from a hash function (Bill Unruh)
Re: "Posting Anonymously is the Sign of a Coward" (Charlie Comsec)
Re: Stream cipher from a hash function (Enterrottacher Andreas)
Re: Yet another chapter from the Handbook of Applied Cryptography (Jean-Jacques
Quisquater)
Re: GnuPG 1.0 released (D. J. Bernstein)
Re: Looking for Completely-Free Strong Algorithms (Paul Crowley)
Re: Difference between Encryption and scrambling..? ("rosi")
cable encryption ("Maxking Interfaces Limited")
Re: Double encryption is patented (mabey) (Mok-Kong Shen)
Re: some information theory ("rosi")
Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out (Matt Ruff / Lisa Gold)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: 11 Sep 1999 04:59:20 GMT
In <[EMAIL PROTECTED]> Paul Koning <[EMAIL PROTECTED]> writes:
>I don't think RC4 is unencumbered.
RSADSI has an encryption program which they called RC$, invented by
Rivest. This program, used in things like Lotus Notes, was a trade
secret of RSADSI. About 3 years ago an encryption program was published
on the net, which was claimed to be equivalent to RC4. Tests showed that
the output of encrypting test vectors with this algorithm gave teh same
result as the encyption in Lotus Notes.
RSADSI never admitted this published version was the same as RC4. Ron
rivest had a pointer on his web page to this published version.
A trade secret ceases to protected under trade secret law when it is no
longer secret. The name is however a trademark of The non-existant
company RSADSI.
This published version is therefor often called Arc-four (I believe it
is). This published version IS unencumbered. Whether it has anything to
do with RC4 is up to you to decide.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Stream cipher from a hash function
Date: 11 Sep 1999 05:04:33 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>hand, are not export restricted. Is it possible to turn a hash function
>into a stream cipher?
Yes. Trivial. See Applied Cryptography by Schneier, also the Bernstein
snuffle which I believe was just such a cypher ( and was ruled by the US
govt as unexportable).
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Stream cipher from a hash function
Date: 11 Sep 1999 05:10:34 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>I see, so it is suseptable to a known plaintext attack. Is there any way to
>strengthen this method? (This is just something I'm playing around with, not
>something I expect to be totally secure by the way.)
ALL cyphers as susceptible to known plaintext attacks. This will depend
on the key size, which is the only protection. This cypher is no more
susceptible.
>> Three: If it is discovered that collisions can be produced in SHA-1 there
>> would be serious problems(you wouldn't need the actual key, just one that
>> collided with it).
We KNOW collisions exist. However finding those collisions is assumed to
be extremely difficulty for any modern hash.
------------------------------
Date: 11 Sep 1999 05:16:09 -0000
From: Charlie Comsec <[EMAIL PROTECTED]>
Crossposted-To:
alt.fan.gburnore,alt.usenet.kooks,alt.privacy.anon-server,alt.privacy,alt.cypherpunks
Subject: Re: "Posting Anonymously is the Sign of a Coward"
Barrett Richardson <[EMAIL PROTECTED]> wrote:
> On 9 Sep 1999, Charlie Comsec wrote:
>
> > Barrett Richardson <[EMAIL PROTECTED]> wrote:
> >
> > > I don't argue that the concept of "anonymity" is bad. I
> > > argue that in it's current implementation in usenet it
> > > is likely to become a casualty of it's own shortcomings.
> > > It needs to evolve into something that can be abused
> > > less openly.
> >
> > Please feel free to provide suggestions as to how you'd like to see
> > "anonymity" change. Can you do it and still have it be *TRUE*
> > anonymity, and not the usual snake oil where identity is "escrowed"
> > by some supposedly "trustworthy" third party? That, BTW, is NOT
> > true anonymity.
>
> On the technical side of things, I would like to have my server
> generate RSA or elliptic curve key pairs and use the public key
> as a "usenet ID" of sorts for a user. When a user authenticates
> to the server the associated public/private key pairs get assigned
> to the user's session. Generate an MD5 hash of the message contents
> and encrypt it with the private key. Attach the "usenet ID" (just
> the public key) and the MD5 hash to the bottom of the message.
> An elliptic curve key would be less obtrusive for this purpose
> as it is smaller. The MD5 hash and "usenet ID" can be used
> to validate the message. Messages are archived and made available
> on the server. Posting history by abusive users can then be identified
> and verified to be theirs. "Designer abuse" will be (somewhat) more
> identifiable by the usenet community as the posting history for
> a "usenet ID" is available. Usenet IDs are not reused when accounts
> are cancelled. Have a unique From: address so usenet participants
> that killfile annoying or abusive users don't killfile your
> entire userbase. The usual steps to secure information in the
> message header is employed.
This sounds like a major overhaul of the usenet/NNTP RFCs.
However, how does it address the concern about anonymity, especially
where anonymous usenet posts start out as anonymous *E-MAIL*
messages routed to a mail-to-news gateway where they are converted
into usenet posts? If you implemented this at the gateway news
server, for example, the only ID on an anonymous post would be that
of the remailer used to send the message to the gateway.
The other problem is that it still does not facilitate a complete
posting history on any REAL PERSON because there is no way to ensure
that the person is only using one ID to post with.
Also, you said that "Messages are archived and made available
on the server". Given the current popularity of concealing posts
using the X-No-Archive header, do you now propose to make archiving
mandatory?
--
Charlie Comsec <[EMAIL PROTECTED]>
------------------------------
From: Enterrottacher Andreas <[EMAIL PROTECTED]>
Subject: Re: Stream cipher from a hash function
Date: Sat, 11 Sep 1999 09:03:26 +0200
[EMAIL PROTECTED] schrieb:
>
> Ok, lets assume that crypto is 100% export restricted, and only lies
> within the US (heh, a BIG assumption).
The idear of the export restrictions is that there are no programmers
outside the US or it would not be allowed to export information about
ciphers.
In this case we would not be able to build a stream cipher from SHA-1 :)
> Hash functions, on the other
> hand, are not export restricted. Is it possible to turn a hash function
> into a stream cipher?
>
> My idea falls along the lines of:
> SHA-1(password) = 1st output of stream cipher
> SHA-1(password + counter) = 2nd output of stream cipher
> SHA-1(password + counter2) = 3rd output of stream cipher
> ...
>
> I was curious, (1) what would you use to make the output non linear (IE,
> how would you change the counter variable above),
It would be enough to concatenate password and the counter (the integer
number describing the block).
Since SHA-1 uses chaining variables you could replace one or two of the
chaining variables by the counter.
If it is not neccessary to ba eble to work with every single block
independent of the others you could replace the chaining variables with
the last ciphertext block (CFB mode).
If it is not neccessary to be able to get one block without decrypting
the
previous one you could replace the chaining variables with the last
output
of SHA-1 (OFB mode).
BTW: You could as well build block-ciphers using SHA-1 :)
> and (2) what would the
> security of this cipher be? (This assuming the hash function is not
> broken.)
In this case the cipher would be secure.
>
> Just curious.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: Jean-Jacques Quisquater <[EMAIL PROTECTED]>
Subject: Re: Yet another chapter from the Handbook of Applied Cryptography
Date: Sat, 11 Sep 1999 11:25:23 +0200
Thanks, Alfred you did a nice job,
Jean-Jacques,
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: misc.legal.computing
Subject: Re: GnuPG 1.0 released
Date: 11 Sep 1999 08:26:12 GMT
This has nothing to do with sci.crypt. Continue the discussion in
misc.legal.computing.
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> I spent some educational time on the Welch patent with the sort of
> outside patent attorneys you would expect a Fortune 500 to hire.
Why did you waste the time?
Miller and Wegman found ``LZW'' before Welch did. IBM applied for its
patent (4,814,746) before Sperry did (4,558,302).
Translate the patents into English and you will see that there is
nothing new in the Sperry patent. The only way that Unisys can make
money off this patent is by convincing gullible people to pay them.
---Dan
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: 11 Sep 1999 11:14:54 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> [response inline]
Ideal. Thanks. I've only commented where I've something to say - I
haven't ignored the other sections...
> > * fast (I assume - how important is this?)
>
> Not overly, but it is a consideration. Mostly I'm looking to build a
> sizable list of good, royalty-free ciphers (see above). Speed would
> only be a consideration for a few customers, for all others they
> wouldn't notice a 50% cut in overall speed.
Ciphers differ by well over 50% in how fast they can encrypt large
streams, but I guess even the slowest modern cipher will be faster
than any other part of your infrastructure (data generation,
compression, downstream bandwidth etc). So the performance of the
cipher will probably make more difference to your CPU load than the
responsiveness seen by customers - and even there, not too much.
> The most time critical stream needs to be able to handle 1KB in
> under 1/2 second, but this is only done a few hundred times a day
> (at most). These figures are for what we expect to be a Pentium-2
> 300 to be the normal minimum system.
For a 1KB message, the main cost in encrypting it will be key
scheduling, but even a very slow key schedule like Blowfish will take
a tiny fraction of 1/2 second on a Pentium-2 300.
> > How long do the streams tend to be?
>
> In one session there are several different streams, ranging from one <1KB to
> one that I've seen at slightly over 1GB, the average though can be expected
> at about 1MB
OK, are all the different streams in the session protected by the same
shared secret?
> > Do you mind if it's a native stream cipher (like
> > RC4) or a block cipher (eg Blowfish) in a chaining mode?
>
> I tend to trust chained ciphers more (longer tradition to understand them
> fully), but I wouldn't mind a proven stream cipher.
Native stream ciphers are *much* faster than block ciphers in chaining
modes, but it sounds like you don't need performance that much.
Furthermore, if many streams are protected by one secret, then with a
block cipher you can do the key scheduling just once, and then use
different IVs for each stream.
> > Do you carehow much memory the cipher uses in its normal operation?
>
> Encryption I'd like to come in at under 6MB and decryption under 2MB, not a
> big issue, security is the primary issue
Nothing uses anything like this much. I can't think of a cipher that
uses more that 4-5k.
> >Does it make a difference if that memory stays the same for all keys (like
> > Rijndael) or has to be re-written for a new key (like Twofish)?
>
> Due to our product all the information would be kept seperated regardless of
> key (at least for the time being) so it's not an issue
I don't think I explained myself very well. Part of the Twofish key
schedule involves filling four 1k tables with key-dependent values;
these are looked up in each round of the cipher. Rijndael also uses
four 1k tables, but these tables are the same regardless of key. It
sounds like that's not a big issue for you either.
Basically, it seems like practically any unencumbered cipher will do,
but block ciphers would be preferred, which is fair enough. Here's my
shortlist:
* Triple-DES: very conservative choice, not terribly fast, decent key
scheduling speed, ugly. Not one to even contemplate trying to
implement yourself: pick up one of the free implementations.
* Blowfish: been around a while now, well known, not really a scratch
in it. Very slow key schedule, but I doubt that would hurt too much.
The biggest problem with both of these is the small block size:
there's a small probability that the cipher might receive the same
input twice, in which case it will produce the same output, leaking
information. The obvious way around this is to use a cipher with a
128-bit block. I don't know of any very conservative choices here; I
think the AES candidates are now the best-studied 128-bit block
ciphers out there. Of the five final round candidates, two (MARS and
RC6) are patent-encumbered. Serpent is sort of neat, but not terribly
fast for what it does. That suggests using Twofish or Rijndael;
they're both very good at everything, Twofish seems to have the larger
security margin, and Rijndael is much easier to understand.
hope this helps,
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Difference between Encryption and scrambling..?
Date: Sat, 11 Sep 1999 08:06:22 -0400
Joseph Ashwood wrote in message ...
>I am unconviced by any of the other arguments, so let me pose my own. As
[snip]
'Some prefer'. Some gave the def as so. As long as you define it well and
use it consistently, IMO, no problem. (We are not graduates from University
of Lonely Defs). As to where it is used, it must fare the same treatment. If
it
is not well defined or is not used consistently, you know how to treat it.
>
>I instead would like to call Scrambling a super-set of encryption. As an
^^^^^^^^^
Not a coincidence. The use of 'scrambling' is 'certainly' not as uniform
as
encryption. It is perhaps used in a wider context and maybe sometimes
vague. If you (I really mean we) call any transformation (one-way or not,
extremely easy or not to reverse) scrambling, good fit. Now the fun part. If
we insist calling something encryption, I may have a hard time calling
anything encryption. (Sorry, I have no intention of developing in this
direction.)
[snip]
>
>I also think that the best "definition" of cryptography was given by a
>friend of mine: "Cryptography is the art of f^&*ing s!#t up so no one else
>can unf^&* it"
>It may be a bit vulgar but I think it's pretty accurate.
^^^^^^^^
I tend to believe that if you (I really mean we) formalize it, this will
be
pretty accurate. And in a sense, it is. The only addition to this is that
there
is better %^&%^* and worse #$^*. :)
------------------------------
From: "Maxking Interfaces Limited" <[EMAIL PROTECTED]>
Subject: cable encryption
Date: Sat, 11 Sep 1999 12:36:30 +0100
Reply-To: "Maxking Interfaces Limited" <[EMAIL PROTECTED]>
Can anyone give the details of the cable signal encryption used here in
England.
Is the signal encrypted ?
If so what type of encryption is it ?
What is the diffrence between soft and hard encryption ?
Is the cable signal just a signal that you add a key to to open all channels
?
I am just interested for educational use only, why is it illegal here in the
UK to sell a cable chip (quick board) but ok in the USA ?
Can you please email the information at [EMAIL PROTECTED]
Thanks in advance.
Regards Maxking Interfaces Limited
Please include last email in your reply.
we get a lot of emails a day, we can't remember everything.
Main web Site: http://www.maxking.com
Email: [EMAIL PROTECTED]
Office numbers: (044) 1302 872094
Office fax: (044) 1302 820885
This email message, including its attachments, is private, is intended for
the recipient herein named and may contain material which is confidential
and privileged.
No person or persons other than the named recipient may read, copy, rely on,
redirect, save or alter the message or any part of it or any attachments to
it in any way.
Maxking Interfaces Limited does not accept any legal responsibility
whatsoever for the content of this message.
Any views or opinions expressed are solely those of the author and do not
represent the views of Maxking Interfaces Limited unless otherwise
specifically stated.
ICQ number: 16259686
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Double encryption is patented (mabey)
Date: Sat, 11 Sep 1999 15:09:46 +0200
John Savard wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>
> >(Length preserving is the
> >main point of the patent, isn't it?)
>
> It lets you do without a "good source of randomness", which is a hard
> thing to obtain on a PC.
What does the patent do to get rid of the problem of difficulty of
having GOOD source of randomness on PC? I don't yet see that the
patent has contributed anything to the problem of obtaining good
random bits at all. If anything, isn't an XOR of the blocks and an
encryption (the Y in my post) serve the same purpose just as well?
(Please explain with a bit detail. Thanks.)
M. K. Shen
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Sat, 11 Sep 1999 08:37:41 -0400
Dear Anti-Spam,
This is only my impression. You are not really wrong, IMO. The (shall we
call
it) disagreement seems to be the slightly different angles of looking at
things.
Let me take a somewhat simplistic approach and say a few words concerning
'security'. In a nut shell, SHA for example, is via XOR, rotate, etc. Any
one of
those in isolation hardly give us any comfort.
What this discussion seem to highlight are a few, IMO, interesting
things. One
of the major points (which we should not lose sight of) is that encryption
(or any
we so call) should have the goal of all or nothing. This is an ideal
situation that
we strive for (to have achieved is another matter). A measurable way is
'one-way'.
Plainly (know all knows this, put here just that it is contiguous), one side
is
poly and the other hopefully expo.
If, on the practical side, anything we do, rounds for example, make the
explosion for the other side take place, it is it. Does not matter in what
manner
or with what simple operations, arranged in whatever fashion. If to know one
bit of the key or of the plaintext (talking under whatever model we
particularly
choose) is 'equivalent' to knowing everything associated with the key and
the
plaintext, we have achieved our goal.
Then the description of the problem. Basically, if the description
'length' only
changes poly with transformations, it kind of indicates, IMO, that the
transformations are not effective. However, if the description fairly
quickly
gets out of hand, e.g. deciding if x is in a language L, it may tell us
something.
(It is also import that what x is, boundaries, etc.)
Once again, I do not think you are wrong and disregard what I said if it
does
not make sense (which is likely so). Thank you and everybody very much for
participating in the discussion.
--- (My Signature)
------------------------------
From: Matt Ruff / Lisa Gold <[EMAIL PROTECTED]>
Crossposted-To: rec.arts.sf.written,alt.cyberpunk
Subject: Re: Neal Stephenson's Cryptonomicon: Crypto Cop-Out
Date: Sat, 11 Sep 1999 09:43:44 -0400
I think you are making a mistake in assuming that Stephenson necessarily
agrees with the beliefs and arguments of his protagonists. In fact, he's
stated publicly that it's an artist's job *not* to take political
stands, because they interfere with the craft of telling a good story.
So just because Avi thinks that the HEAP justifies the creation of a
data haven, don't assume that it actually does justify it, or that
Stephenson thinks it does -- he's simply telling you what *Avi* thinks,
and trusting you to make up your own mind about whether you agree (if
you even care to speculate about it).
Re: plausibility, my own question about a data haven is whether most
programmers would really be in favor of it, since it would seem to make
software piracy unstoppable. But probably the "coolness" of the Crypt
would attract enough tech people to get it off the ground.
-- M. Ruff
------------------------------
** 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
******************************
