Cryptography-Digest Digest #221, Volume #10 Sat, 11 Sep 99 14:13:03 EDT
Contents:
Re: "Posting Anonymously is the Sign of a Coward" (SCOTT19U.ZIP_GUY)
Re: Stream cipher from a hash function (SCOTT19U.ZIP_GUY)
Re: Looking for Completely-Free Strong Algorithms (Kent Briggs)
Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest thing!!!
(RSAEuro General)
Re: Looking for Completely-Free Strong Algorithms (SCOTT19U.ZIP_GUY)
diffie-hellmann in PeekBoo (Tom St Denis)
Re: Looking for Completely-Free Strong Algorithms (Tom St Denis)
Re: General encryption question (Arthur Dardia)
Re: cable encryption (Arthur Dardia)
Re: some information theory (Anti-Spam)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
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"
Date: Sat, 11 Sep 1999 15:41:17 GMT
In article <[EMAIL PROTECTED]>, Charlie Comsec
<[EMAIL PROTECTED]> wrote:
>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.
I think the people should be allowed to post with complete anonymity.
Some times people have been fearful to post out of retailiation. I for
one have had several DEATH THREATS so there is good reason for
people to have some security that anonymity can provide.
Also as many of the ISP porviders come and go in this business
even if one wants to have a posting history linked to his ID it is impossible
since you change ID's each time you have to hunt for a new ISP provider.
It must be easy thought to cahnge ID's becasue some times people post
with my ID and it is not me all the time. Also I have found messages that say
I wrote a java applet and recomend people to use it. I never would do that
and if you visit my site I warn people about such stuff and the user if he
is not bright enough to turn those virus collecting features off he does not
get to see my whole web page. I do the opposite of the brain dead MS
sites that require advanced features turned on when the dam sites contain
nothing that could not have been done in HTML.
>
>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?
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Stream cipher from a hash function
Date: Sat, 11 Sep 1999 15:53:26 GMT
In article <7rcnt0$db9$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bill Unruh)
wrote:
>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).
>
I thought the lastest court rulings should that it could be exported. What
has anything heepened since that ruling. Can't he export it now?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Sat, 11 Sep 1999 15:07:43 GMT
Bill Unruh wrote:
> 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.
In addition to that, when export controls where under ITAR, the State
Department provided a serialized RC4 test vector with a sample key and
plaintext. The export applicant had to provide the resulting ciphertext to
show they had a correct implementation. Using the RC4 spec provided in
Schneier's "Applied Cryptography", I successfully went through this process
several times and thus there is no doubt that the now-published spec is
accurate.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED] (RSAEuro General)
Crossposted-To:
microsoft.public.win32.programmer.networks,microsoft.public.win32.programmer,comp.os.ms-windows.programmer.win32
Subject: Re: Win Crypto libs, was: Help with CryptoAPI: can not do the simplest
thing!!!
Date: Sat, 11 Sep 1999 14:24:36 GMT
On Tue, 07 Sep 1999 21:40:18 -0400, Taavo Raykoff <[EMAIL PROTECTED]>
wrote:
>Okay, given that, does anyone have any suggestions for a library of
>basic crypto routines that will run on windows? I need DES, RC2, SHA,
>and HMAC.
>
The commercial release of RSAEuro provides all the above algorithms.
RSAEuro Team
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Sat, 11 Sep 1999 15:47:54 GMT
In article <[EMAIL PROTECTED]>, Paul Crowley
<[EMAIL PROTECTED]> wrote:
>"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.
Then you need to be educated. If you can make scott16u or scott19u
work in less than 10k I would love to hear from you.
>
>> >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,
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: diffie-hellmann in PeekBoo
Date: Sat, 11 Sep 1999 15:18:48 GMT
I am adding DH to Peekboo to allow better key generation. I need two things
a) as much technical and implementation data I can find on DH
and
b) Ideas for SIMPLE (for the user) and compact rngs. I am thinking of
running SHA-1 in counter mode with some seed...
The DH part will be a dialog but built into PeekBoo.
Thanks,
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Looking for Completely-Free Strong Algorithms
Date: Sat, 11 Sep 1999 16:01:33 GMT
In article <7rdq38$2b92$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >> 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.
> Then you need to be educated. If you can make scott16u or scott19u
> work in less than 10k I would love to hear from you.
How about scottu8?
Tom
--
damn windows... new PGP key!!!
http://people.goplay.com/tomstdenis/key.pgp
(this time I have a backup of the secret key)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: General encryption question
Date: Sat, 11 Sep 1999 12:14:38 -0400
Reply-To: [EMAIL PROTECTED]
Andrew wrote:
>
> Is it possible to decrypt and
> execute a file/application
> without at any time leaving it
> in a decrypted state on the
> hard drive?
>
> Andrew
In order for the encryption program to work, the file/application must exist on
a hard drive, in your brain, on a floppy, or whereever. An exact copy must be
somewhere where it can be inputed via keyboard or via the program's ability to
open a file and copy it's contents. It can then encrypt it. If you type the
file in, the data will not exist on the hard drive. If you use a floppy, then
it's neither on the hard drive, nor in your brain, which saves you the trouble
of having to memorize a very long file. However, PGP has a disk utility which
completely cleans the hard drive of all remaining "residue." If the file is on
your hard drive, encrypt it, "delete" it, and then run PGP's utility to remove
all existing traces of it's plaintext.
Art Dardia
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: cable encryption
Date: Sat, 11 Sep 1999 12:09:07 -0400
Reply-To: [EMAIL PROTECTED]
A while ago when I first became interested in distributed computing, I searched
for many projects. I came across KeyBlitz. "The KeyBlitz Project - or KeyBlitz
for short - is an attempt to organize a very large-scale brute-force attack on
the encryption keys used in the EuroCrypt pay-TV scrambling system. In other
words, it is an attempt to get free TV! If we are successful, it means that
people all over Europe will be able to watch scrambled TV channels without
actually paying for a subscription. This is the overall long term goal of the
project." However, I say this now: COSM is going to rock.
KeyBlitz URL: http://www.thoic.com/keyblitz/
Note though, that the project has been temporarily stopped; however, I'm sure
you can email them for more information.
Art Dardia
Maxking Interfaces Limited wrote:
>
> 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: Anti-Spam <[EMAIL PROTECTED]>
Subject: Re: some information theory
Date: Sat, 11 Sep 1999 10:20:44 -0700
rosi wrote:
>
> 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)
We are thinking along the same lines, IMO. I wonder if it is possible
to prove (show) the problem of determining the symbols as encoded in an
adaptive compression with :
(first) the total compressed data/file available, and with NO a priori
knowledge of the number and "kind" of symbols, is equivalent to a P
problem, an NP problem, an EXP problem, etc.
(second) the total compressed data/file available, and with a priori
knowledge of the number and "kind" of symbols, is equivalent toP
problem, an NP problem, EXP problem, etc.
(third) only partial compressed data/file available ( a subset of the
total), and with NO a priori knowledge of the number and "kind" of
symbols, is equivalent to a P problem, an NP problem, EXP problem, etc.
(fourth) only partial compressed data/file available ( a subset of the
total), and with NO a priori knowledge of the number and "kind" of
symbols, is equivalent to P problem, an NP problem, EXP problem, etc.
Note this proposed analysis deals only with statistical coding and not
dictionary coding. I have seen a proof (not rigourous but can be made
so) that dictionary coding is equivalent by transformation to a
statistical coding, so the answers to those 4 questions may apply to
dictionary coding. (Proof's in "Text Compression, section 9.1.2, by
Timothy C. Bell, John G. Cleary and Jan H. Witten, c. 1995, ISBN
0-13-911991-4)
Quantifying the contribution of a maximal entropy encoding of the
plaintext to the "difficulty' of cryptanalysis is a nice thing to know.
All of our cryptosystems are only as good as the collective interaction
of each stage. I find much in the literature and on the Web explaining
the cryptanalytic difficulty in attacking public key and symmetric key
ciphers, and in attacking protocols, but little on the quantified
contribution of plaintext compression to cryptanalytic difficulty. We
all sense it is a "good thing" to do, but how good? Some compression
algorithms increase cryptanalytic difficulty more than others. We see
that in the limiting case of adaptive huffman coding - the static
huffman code - we have an equivalence to a substitution encipherment of
the original plaintext in the compressed plaintext. Here I postulate a
equivalence to polyalphabetic encipherment of the plaintext in adaptive
huffman coded compressed plaintext - it's most probably not an "exact"
equivalence but may be something close to it.
My conjecture is that non-maximal entropy encoding of the plaintext
reduces the size of chosen plaintexts or known plaintexts required for
linear and differential cryptanalysis of block cipher algorithms.
(Sounds obvious, yes I agree.) The maximum number of chosen plaintexts
and known plaintexts are required for linear and differential
cryptanalysis of block cipher algorithms when the coding of the
plaintext is a maximal entropy encoding. The reduction in number of
plaintexts required for cryptanalysis may be (hunch only) a non-linear
function of the "degree" of deviation from maximal entropy encoding of
the plaintext prior to encryption. Maybe a "small" increase in coding
redundancy in the plaintext leads to a "big" decrease in the amount of
such coded plaintext required to successfully differentially or
linerally cryptanalysize (sp?) the block cipher to recover a key. This
is a non-obvious conjecture.
So, Can this be quantified? These are such nice problems.
That's what I thinking about.
[EMAIL PROTECTED]
P.S. it's a weekend - I can post during the day. Yeah. :) )
------------------------------
** 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
******************************
