Cryptography-Digest Digest #259, Volume #12 Thu, 20 Jul 00 14:13:01 EDT
Contents:
Re: TAGGED INFORMATION ("Mikal 606")
Re: New stream cipher ("Trevor L. Jackson, III")
Re: Good free stream cipher ? (Paul Koning)
Re: how strong is my own encryption? (Paul Koning)
Re: RC4 free for noncommercial ? (stanislav shalunov)
Re: how strong is my own encryption? (Mark Wooding)
need help with commercial encryption software please ("diana")
commercial encryption software help? ("diana")
Re: Compression & Encryption in FISHYLAND (Sander Vesik)
commercial encryption software help>? ("diana")
commercial encryption software help?? ("diana")
Re: strength of encryption (Bill Unruh)
Re: VCR+ code generator ("TheBahxMan")
Re: RC4 free for noncommercial ? (Bill Unruh)
Re: RC4 free for noncommercial ? (Bill Unruh)
Re: RC4 free for noncommercial ? ([EMAIL PROTECTED])
Re: TAGGED INFORMATION ("Joseph Ashwood")
Hashing hash algorithms: a waste of time (lcs Mixmaster Remailer)
Re: Bit Shuffling (John Myre)
----------------------------------------------------------------------------
From: "Mikal 606" <[EMAIL PROTECTED]>
Subject: Re: TAGGED INFORMATION
Date: Thu, 20 Jul 2000 10:12:47 -0700
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:OinRVOh8$GA.282@cpmsnbbsa09...
> > What if the recipient knows but doesnt give it away?
> > Or you find the information removed, what are your thought
> processes at that
> > point?
> Umm, at that point it's still called steganography. If the
> (unintended) recipient knows, then it's failed
> steganography, if the information is removed it is removed
> steganography, but both are steganography regardless.
> Joe
>
>
"and this additional info can not be removed
if the recipient does not know about that."
Um, presumably there is more to it than that.The original poster was talking
about " sending around " information.
::sigh::
Leo
------------------------------
Date: Thu, 20 Jul 2000 10:58:45 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
[EMAIL PROTECTED] wrote:
> The key is used to generate infinite byte sequence of key stream using
> finite group of the order 65536.
How is it that you generate an infinite sequence from a finite resource?
Think the sequence will ever repeat? If it repeats does that make it a
repeating pad instead of a One Time pad?
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Good free stream cipher ?
Date: Thu, 20 Jul 2000 10:22:31 -0400
Runu Knips wrote:
>
> Paul Koning wrote:
> > Runu Knips wrote:
> > > I'm looking for a good & free stream cipher algorithm.
> > How about any good block cipher in counter mode, or CFB mode?
> > Or are you looking for something different for some
> > reason?
>
> Well, acutally I could use that as well, but AFAIK real
> stream ciphers tend to be faster.
That sounds right. Then again, how fast does it have to be?
Do you want to use hardware, or software?
3DES can run at several Mb/s in software, most other block
ciphers are quite a lot faster.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: how strong is my own encryption?
Date: Thu, 20 Jul 2000 10:34:19 -0400
Martin wrote:
>
> Okay. Thanks for the link.
> While I'm here, can someone please post a list of good cryptography books?
For history, up to about the 1960s: The Codebreakers, by David Kahn.
(Note that the paperback is a waste of paper.)
For a very thorough survey of modern crypto, with modest technical
detail: Applied Cryptography, by Bruce Schneier.
For a lot more theory: Handbook of Applied Cryptography, by Menezes,
van Oorschot, and Vanstone.
FWIW, Dr. Dobbs Journal publishes a CD-ROM that contains the last
two along with a bunch more, including several classic military
references by William F. Friedman. And the price is pretty
good, though I still prefer paper books most of the time...
paul
------------------------------
From: stanislav shalunov <[EMAIL PROTECTED]>
Subject: Re: RC4 free for noncommercial ?
Date: 20 Jul 2000 11:40:13 -0400
Runu Knips <[EMAIL PROTECTED]> writes:
> My crypto book states that 'RC4 requires a license fee for
> commercial use'.
The politically correct way to resolve this issue of stolen trade
secret is to call your function arc4 or arcfour. You can then use it
in any applications, just don't mention the word "RC4".
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: how strong is my own encryption?
Date: 20 Jul 2000 15:48:29 GMT
Paul Koning <[EMAIL PROTECTED]> wrote:
> For history, up to about the 1960s: The Codebreakers, by David Kahn.
> (Note that the paperback is a waste of paper.)
>
> For a very thorough survey of modern crypto, with modest technical
> detail: Applied Cryptography, by Bruce Schneier.
>
> For a lot more theory: Handbook of Applied Cryptography, by Menezes,
> van Oorschot, and Vanstone.
Three good recommendations. Note that the last of these is available in
PostScript and PDF format from http://www.cacr.math.uwaterloo.ca/hac/.
The authors pushed the publishers until they were allowed to release the
whole thing free of charge. Then again, I've no regrets about paying
full price for my paper version.
-- [mdw]
------------------------------
From: "diana" <[EMAIL PROTECTED]>
Subject: need help with commercial encryption software please
Date: Fri, 21 Jul 2000 11:50:24 -0400
Reply-To: "diana" <[EMAIL PROTECTED]>
I'm wondering if anyone here would mind talking to me (either on the phone
or by email) about trends in encryption software technology and the
commercial encryption business. I'm writing an article on same (will tell
you the details privately) and need to talk to some folks familiar with the
different vendors.
Thanks so much
diana
------------------------------
From: "diana" <[EMAIL PROTECTED]>
Subject: commercial encryption software help?
Date: Fri, 21 Jul 2000 11:51:26 -0400
Reply-To: "diana" <[EMAIL PROTECTED]>
I'm wondering if anyone here would mind talking to me (either on the phone
or by email) about trends in encryption software technology and the
commercial encryption business. I'm writing an article on same (will tell
you the details privately) and need to talk to some folks familiar with the
different vendors.
Thanks so much
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Date: 20 Jul 2000 15:56:09 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> On 9 Jul 2000 23:18:43 -0700, [EMAIL PROTECTED] (Kurt Shoens)
> wrote, in part:
>>Agreed that there's no proof of security against known
>>plaintext attacks. If you're really concerned about avoiding
>>known plaintext, you can always avail yourself of the various
>>chaining modes, which will do a better job of camouflaging the
>>plaintext.
> The traditional block cipher chaining modes do nothing to increase the
> fundamental security of the underlying block cipher; nor do they
> protect against a true known-plaintext attack, where the entire text
> of a message is known with certainty, although by "camouflaging the
> plaintext" they might make a _probable word_ attack more difficult.
So use a non-traditional chaining mode. For example:
X(0)=E(k, IV)
X(n)=E(k, X(n-1))
C(n)=E(k, P(n) xor X(n))
P(n)=D(k, C(n)) xor X(n)
> John Savard (teneerf <-)
> http://home.ecn.ab.ca/~jsavard/crypto.htm
--
Sander
FLW: "I can banish that demon"
------------------------------
From: "diana" <[EMAIL PROTECTED]>
Subject: commercial encryption software help>?
Date: Fri, 21 Jul 2000 11:56:39 -0400
I'm wondering if anyone here would mind talking to me (either on the phone
or by email) about trends in encryption software technology and the
commercial encryption business. I'm writing an article on same (will tell
you the details privately) and need to talk to some folks familiar with the
different vendors.
Thanks so much
------------------------------
From: "diana" <[EMAIL PROTECTED]>
Subject: commercial encryption software help??
Date: Fri, 21 Jul 2000 12:32:26 -0400
I'm wondering if anyone here would mind talking to me (either on the phone
or by email) about trends in encryption software technology and the
commercial encryption business. I'm writing an article on same (will tell
you the details privately) and need to talk to some folks familiar with the
different vendors.
Thanks so much
diana
please take out the nospam in my mailing address!
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: strength of encryption
Date: 20 Jul 2000 17:01:22 GMT
In <[EMAIL PROTECTED]> wes goodwin <[EMAIL PROTECTED]> writes:
>I have made an encryption program that is almost fully C compliant.
>The only thing that prevents this is the use of unistd.h.
>On to my question. I've seen all of the talk about the 'strength' of
>encryption,
>ie 168-bit encryption. What does the measure refer to and how can the
>measure
>be calculated. I would like to know how strong my program is.
The strength of an encryption program is determined by many many things.
The length of the key is only one of them. IF the only way ofbreaking
the encryption is by trying every key and seeing which one works, then
the length of the key is a measure of the strength. Almost all
encryption routines, especially ones cooked up by amateurs, can be
broken by other means and are thus much much weaker than their key
length would indicate. Thee is no way of measuring the strength. It is
determined by having a bunch of people try to break it for a long time
and failing. Thus, your apparent ignorance of what "strength of
encryption" means suggestes that you do not have much experience in the
field. The chances of your encryption scheme having only exhaustive
search as a way of breaking it are thus slim.
------------------------------
From: "TheBahxMan" <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.video.vcr
Subject: Re: VCR+ code generator
Date: Thu, 20 Jul 2000 11:04:47 -0600
Although this is the first time in my memory I have ever seen a sci.crypt
crosspost. alt.religion.wicca, but not sci.crypt
--
Reaching out from my cardboard castle, bringing joy to the children of the
world, I am the man in the bahx and this has been something I have spewed...
Thank You for not laughing...
"Brash" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> "Kile Mornay" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> >
> > >Benji,
> > >Just quick note. Sci.crypt is not the place to ask about this stuff.
> >
> > Actually, sci.crypt is the perfect place to ask. The VCR+ scheme is very
> > much a cryptography issue.
>
> And seeing as how every topic ever imaginable somehow seems to get
> crossposted to alt.2600, it's perfectly fine to post here.
>
> Hope you are willing to weed through all the sarcastic replies, though.
;-)
>
> Brash
> --
> 0h y0rdshch!
>
> > --
> > "Kile Mornay" is actually 4103 789256 <[EMAIL PROTECTED]>.
> > 0123 456789 <- Use this key to decode my email address and name.
> > Play Five by Five Poker at http://www.5X5poker.com.
>
>
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With Servers In California, Texas And Virginia - The Worlds Uncensored News Source
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4 free for noncommercial ?
Date: 20 Jul 2000 17:09:27 GMT
In <[EMAIL PROTECTED]> Runu Knips <[EMAIL PROTECTED]> writes:
>Runu Knips wrote:
>> I'm looking for a good & free stream cipher algorithm.
>> Does anybody have a suggestion ?
>My crypto book states that 'RC4 requires a license fee
>for commercial use'. Does that mean it is free for
>non-commercial use ?
It means that RC4 requires a license . HOwever, the public crypto
system, which sometimes goes under the name of RC4, since it seems to
encrypt everything in exactly the same way as RC4 does, but has never
been stated by RSADSI or Rivest(but see his web page) to be the same as
RC4, is completely free for use in any situation. RC4 is also a
trademark of RSADSI ( or whoever bought them out) and so the usual name
given to this free public version is ARC4 ( pronounced are-cee-four).
RSADSI claims RC4 is a trade secret, and if ARC4 is RC4 then that secret
is no longer secret, so they will not admit that ARC4 is RC4. They have
also never stated it is not.
So, try ARC4 instead (or the numerous public code versions of things
illegally called RC4 which are actually ARC4, and may or may not be the
same as the secret RC4)
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4 free for noncommercial ?
Date: 20 Jul 2000 17:14:10 GMT
In <[EMAIL PROTECTED]> stanislav shalunov <[EMAIL PROTECTED]>
writes:
>Runu Knips <[EMAIL PROTECTED]> writes:
>> My crypto book states that 'RC4 requires a license fee for
>> commercial use'.
>The politically correct way to resolve this issue of stolen trade
>secret is to call your function arc4 or arcfour. You can then use it
Stolen? What evidence do you have that it is or was stolen? There are
many perfectly legal ways of obtaining and revealing trade secrets.
And a trade secret, once revealed, no matter how, is not a trade secret.
Thus RSADSI's refusal to state whether arcfour is the same as RC4.
However, the letter combination RC4 is also apparently a trademark of
RSADSI (or whoever bought them out), so you may get into trouble if you
use that combination of letters in a crypto context.
>in any applications, just don't mention the word "RC4".
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC4 free for noncommercial ?
Date: Thu, 20 Jul 2000 18:34:33 +0100
RC4 requires no license, atleast not legally - it was an RSA trade
secret and hence if they're let out there's little they can do.
Of course, the name 'RC4' may have legal restrictions, but that would be
a restriction on the name of the algorithm and not the algorithm itself.
-Jared M
Runu Knips wrote:
> Runu Knips wrote:
> > I'm looking for a good & free stream cipher algorithm.
> > Does anybody have a suggestion ?
>
> My crypto book states that 'RC4 requires a license fee
> for commercial use'. Does that mean it is free for
> non-commercial use ?
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: TAGGED INFORMATION
Date: Thu, 20 Jul 2000 10:41:47 -0700
> "and this additional info can not be removed
> if the recipient does not know about that."
>
> Um, presumably there is more to it than that.The original poster was
talking
> about " sending around " information.
> ::sigh::
Why should there be more to it, if you don't know that the bottom bit of the
wav file contains data, there's little you can do to detect it. From there
you could spray paint the wav file on the side of a building if you want,
only someone who knows that stego is involved will get the information,
how's that for sending information around.
Joe
------------------------------
Date: 20 Jul 2000 18:00:32 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Hashing hash algorithms: a waste of time
When computing a signature, does it add security to include the sig and
hash algorithm in the data which is hashed?
Some writers seem to suggest that it does. For example, in the XML
Digital Signatures working group,
http://www.ietf.org/internet-drafts/draft-ietf-xmldsig-core-03.txt says:
The SignatureMethod is the algorithm used to convert the canonicalized
SignedInfo into the SignatureValue. It is a combination of a digest
algorithm and a key dependent algorithm and possibly other algorithms
such as padding, for example RSA-SHA1 or HMAC-SHA1. The algorithm
names are signed to resist attacks based on substituting a weaker
algorithm.
The idea is that some data is signed, and included in the data is a
description of the signature algorithm itself (public key and hash
algorithm, for PK sigs). This, it is said, resists attacks based on
substituting a weaker algorithms.
The alternative would be to specify the signature and hash algorithm
*outside* the signed portion. Of course the verifier needs to know
these algorithms to verify the signature, but the question is whether
it adds security to include this information in what is hashed.
Consider attacks based on substituting weaker algortihms. For example,
DSS always uses SHA1. Suppose someone proposes an alternative form of
DSS that uses a different hash but still the same signing algorithm,
DSA. Suppose further that this hash eventually is found to be weak.
Call it JUNKHASH.
Now, using DSA + JUNKHASH allows one to forge signatures, because it
is easy to create a fake message M_fake which, hashed with JUNKHASH,
creates the same hash as a legitimate message M_real hashed with SHA1.
The attacker takes an existing legitimate DSS signature on M_real,
and substitutes M_fake, saying to use hash algorithm JUNKHASH. The DSA
signature value is left alone, and the new signature will verify correctly
since the hash is the same.
This is the basic idea of the attack. Now, the question is, does
including the algorithm specification (DSS vs DSA+JUNKHASH) in the
material that is hashed make the attack harder to execute?
To some limited extent, the answer is probably yes. In order to create
M_fake the attacker is going to need some freedom of action. He will have
to adjust some parts of the message in order to make the hash come out
to what he wants. Including the alg spec in the hashed data forces him
to leave that part of the message as "DSA+JUNKHASH". He can't play with
this, he must leave it that way or else the message can't be verified.
So his freedom of action is reduced somewhat, and he can only make
alterations to other parts of the message in order to achieve his goal.
But really, this is a very minor restriction. And in fact it could be
met equally well by putting a fixed string in the algorithm specification
field, like "THIS SPACE INTENTIONALLY LEFT BLANK". If the spec required
that such a field exist, the attacker's flexibility and freedom to adjust
the message would be just as constrained as if he were forced to put
his algorithm there.
Including the algorithm spec in the hashed data really does not play
a significant role in adding security. In particular it does not in
any way force the attacker to use the same algorithm specification, or
prevent him from changing it to the specification of the weak algorithm.
And given that the algorithm is weak, making him include the algorithm
spec in the hash is not likely to add significantly to the difficulty
of the attack.
As a general principal, it does not strengthen protocols against algorithm
substitution attacks to include the algorithm specification as an INPUT
to the potentially weakened stage. It must go outside that channel in
order to add security. We see this in PKCS-1, where the hash algorithm
spec is input to the RSA signature stage. It does not go through the
hash algorithm itself; the designers presumably recognized that that
would be weak. It bypasses the hash stage, and feeds directly into the
signature stage. This adds strength. The present proposal, although
it bears some resemblance to that, fails because it sends the alg spec
through the very stage it purports to protect.
Of course, it may turn out that requiring the algorithm spec in that place
does happen to make the attacker's job more difficult, due to the specific
nature of the weakness he is exploiting. But on the other hand, it could
conceivably make his job easier, if the exploit happened to work well
with the particular encoding of the alg spec in the specified location.
Overall, it doesn't seem appropriate to conclude that requiring the
algorithm specification to be included in the hashed data will add
resistance to attacks based on substituting a weaker algorithm. In the
interests of including only cryptographically justified security features,
it would be more appropriate to move the algorithm specification out of
the hashed data region.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Thu, 20 Jul 2000 12:00:53 -0600
Paul Pires wrote:
>
> John Myre <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Paul Pires wrote:
> > >
> > > The "Bandwidth" of the US PTO is putrid. If it was filed in mid 98, I
> > > wouldn't expect to see anything until late 2000 IF it flew perfectly
> with no
> > > pesky office actions to deal with.
> >
> > I'd call that "response time" rather than "bandwidth".
>
> Opinions vary :-)
Ah, gee, do I have to do this?
...
bandwidth : information per time
So the amount of time a single patent takes is not bandwidth.
Bandwidth is how many patents are finished each (week).
Queueing theory has more to say on the relationships involved.
Of course, language is a living thing. Opinions do vary, and the
definition of a word is subject to opinion. Even in this group,
I suspect that not many are interested in picky details like this.
Perhaps "bandwidth" will soon no longer mean anything definite.
Sorry I brought it up.
JM
------------------------------
** 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
******************************
