Cryptography-Digest Digest #293, Volume #11 Fri, 10 Mar 00 04:13:01 EST
Contents:
Re: An archiver with secure encryption ("Steve A. Wagner Jr.")
Re: PGP Decoy? (Andru Luvisi)
Re: SHA-1 and Patents confusion with Hitachi (Jerry Coffin)
Re: Cellular automata based public key cryptography ("Douglas A. Gwyn")
Re: Universal Language ("Douglas A. Gwyn")
www.wirelessencryption.com ("jgilbert")
Re: Birthday paradox ("Douglas A. Gwyn")
Re: www.wirelessencryption.com ("Douglas A. Gwyn")
Re: Linking Time-Stamping Servers (Ron Skoog)
Re: why xor?(look out,newbie question! :) ("Joseph Ashwood")
Re: Your Recommended Choice On Std Crypto Parts ("Joseph Ashwood")
Re: Linking Time-Stamping Servers (Terje Mathisen)
Re: Crypto Patents: Us, European and International. ("Lassi Hippel�inen")
Re: NIST, AES at RSA conference (D. J. Bernstein)
subscribe ("Andrzej Nowak")
----------------------------------------------------------------------------
From: "Steve A. Wagner Jr." <[EMAIL PROTECTED]>
Subject: Re: An archiver with secure encryption
Date: Fri, 10 Mar 2000 11:50:22 -0800
Why not just give the user 5 compression options like other archivers (and I
do).
Though keys are hashed to 448bits for blowfish, it's obviously only as secure
as the actual password itself. If by chance a user enters a good 96character
alphanumeric passphrase, then that 448bits would be put to good use.. Don't
quote me on the 96chars, its a guess off the top of my head. And I'm well
aware of ZLIB. That is what SAW uses, and it's noted in the documentation.
Tom St Denis wrote:
> Steve A. Wagner Jr. <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > *** The United States government may restrict download of this software.
> > ***
> >
> > Fully enabled Shareware -- http://mndrppr.home.mindspring.com/
> >
> > I hope you find it useful, and send me some comments either way.
> >
> > Algorithms: Triple-DES, TwoFish (256bit), BlowFish (448bit)
> >
> > Compression: Store, Zip4, Zip6, Zip9, and an added proprietary method
> > for large redundancies.
> >
>
> Why not just use deflate?
>
> http://www.cdrom.com/pub/infozip/zlib/
>
> As for the ciphers, why use 448 bit keys? Is this a symmetric system or
> does PK get used anywhere?
>
> Tom
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.scramdisk
Subject: Re: PGP Decoy?
Date: 09 Mar 2000 20:19:30 -0800
[EMAIL PROTECTED] writes:
[snip]
> But what about the following: The software provides a way to provide an
> arbitrary number of files upon encryption. But it also provides a way to
> fill up the cyphertext with random numbers that would grow the size of
> the file in such a way that there could equally have been encrypted
> several other files.
>
> Then, nobody can force you to give *all* private keys, because you can
> always say, that there's only one file encrypted and the rest is random
> data provided by the program (at best, automatically). If the public key
> encryption is cryptographically strong, it shouldn't be possible to
> distinguish the random data from real encrypted files, thus making it
> possible to claim that there's only one file encrypted in the cyphertext,
> and giving the key for the unsuspicious file of the two or more that
> actually have been encrypted.
>
> The disadvantage of this method is that you will up your disk with a lot
> of random junk. I guess the most secure would be to also encrypt the
> random chunk, so weaknesses of the encryption cannot be used as criterion
> at all.
[snip]
This also has the very serious problem that there isn't any way to
prove that you've given up all of your keys. If people are beating
you to get your keys out of you, there isn't any way you can ever
convince them you gave them all of your keys, so there isn't any way
you can get them to stop beating you.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: SHA-1 and Patents confusion with Hitachi
Date: Thu, 9 Mar 2000 21:45:26 -0700
In article <8a93nl$4ds$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Hitachi, Ltd., Intellectual Property Office
> http://grouper.ieee.org/groups/1363/letters/Hitachi.txt
>
> "
> If IEEE adopts a standard on the above RIPEMD-160, RIPEMD-128 and SHA-1
> hash functions, Hitachi Ltd. is willing to grant non-exclusive, non-
> transferable licenses on fair, reasonable and non-discriminatory terms
> and conditions under any of its patent rights, under which it has the
> free right to grant licenses and to the extent necessary to comply with
> this standard, to any party which has submitted or will submit an
> equivalent undertaking with respect to this standard.
> "
>
> Now, does this mean
> 1 ) Hitachi claims patents on SHA-1?
I don't think so, but if they do, it looks to me like they're
completely full of sh*&. The first patent cited specifically requires
that the amount of output be equal to the amount of input. The
second requires that the algorithm be reversible by applying the same
algorithm to the output data to produce the original input.
Neither of these is the case with a hashing algorithm: one of the
most basic ideas of a cryptographic hash is that it's difficult or
impossible to reverse it so you get either the original input, or any
other input that would produce the same output. The size of output
from a hash remains constant regardless of the size of input; the two
would be equal only when the size of input happened to be the same as
the size of the output the hash always produces.
It's _probably_ possible to use these hash algorithms to produce keys
for use in a cryptographic protocol similar or identical to those in
the Hitachi patents, but that's really a whole different question.
> 2 ) That royalties are due, for an algorithim made freely available by
> its authors?
IF a patent applies, the fact that somebody else makes the thing
available freely doesn't necessarily mean anything.
> 3 ) Is this patent actively enforced?
ard to guess -- this _looks_ like a fairly standard form letter.
Most committees require all member companies to agree to at least
something along this line, though the details vary. Some ask that
patent rights be available for free to other companies on the
committee, and at a fair and reasoanble rate to anybody else; others
just at a fair and reasonable rate to everybody.
> 4 ) What are these said dues we must pay to ceaser?
It's virtually impossible to say for sure. A fairly typical rate is
1%, but that's not guaranteed.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cellular automata based public key cryptography
Date: Fri, 10 Mar 2000 04:51:14 GMT
[EMAIL PROTECTED] wrote:
> Theoretically, CA could be made to do quantum computation (QC)
What "theory" is that?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Universal Language
Date: Fri, 10 Mar 2000 04:56:23 GMT
drickel wrote:
> People who thought in it would think faster the same way people
> who spoke it would speak faster (more words (ideas)/second).
Many people do much of their thinking in nonlinguistic modes.
(Verbalizing often occurs only near the end of a thought process.)
------------------------------
From: "jgilbert" <[EMAIL PROTECTED]>
Subject: www.wirelessencryption.com
Date: Fri, 10 Mar 2000 05:08:47 GMT
Anyone familiar with what these folks are up to?
http://www.wirelessencryption.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Birthday paradox
Date: Fri, 10 Mar 2000 05:12:02 GMT
Raphael Phan Chung Wei wrote:
> We come across the term birthday paradox when we go through
> literature on cryptanalysis. ... Now how do we
> apply that to the search for matches in block ciphers?
You don't apply it to doing the search, but to estimating how
much searching will be required. The rule of thumb is that you
have to try approximately the square root of the size of the
key space in order to get *one* match among the set of trials.
This applies, for example, to "meet-in-the-middle" attacks, so
for the concatenation of two separately keyed DES encryptions
(56 bits per key), a MITM attack needs to encrypt approximately
2^57 times (2 * 2^56, with 2^56 being the square root of the
total key space 2^56 * 2^56). This is the basis for the
(simplistic) claim sometimes heard that 2DES is no more secure
than 1DES.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: www.wirelessencryption.com
Date: Fri, 10 Mar 2000 05:18:31 GMT
jgilbert wrote:
> Anyone familiar with what these folks are up to?
> http://www.wirelessencryption.com
There is contact information there; why not contact them to find
out (and report back here)?
If "neural networks" do a better job of error correction than the
ECCs everybody else is using, on random data, that would be quite
a breakthrough, if not a miracle.
------------------------------
From: Ron Skoog <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Linking Time-Stamping Servers
Date: Thu, 09 Mar 2000 21:40:55 -0800
Mike Rosing wrote:
>
> Jean Marc Dieu wrote:
> >
> > Have anyone heard about ways/protocols to link several Time-Stamping
> > Servers?
> > By linking I mean two things:
> >
> > 1. Synchronize clocks (What are the options: NTP,... and there
> > effectiveness against an attack such as (Distributed) Denial of Service)
>
> Lock all servers to an external clock. Most countries have a time
> base standard which is broadcast by radio. By comparing the time
> base with the time from another server you get a much better idea
> of what the sync delays are. Drifts in any server can also be
> corrected by the server itself. Radio jamming will wipe out
> one server, but it would be hard to get them all without jamming the
> source. And in most countries, that would be noticed :-)
>
> Patience, persistence, truth,
> Dr. mike
The sources available in the US, ignoring network distributed time
because of the reference to DDoS, are (AFAIK) the Naval Observatory
radio broadcast time signal, the GPS and GLONASS (Russian version of
GPS) satellite time signals, and the phone company (TPC ;{). There
may also be a separate TV band time signal since my TV set uses a
local PBS channel to set it's clock.
Others should have access to the satellite time signals and any local
broadcast time signals (radio or TV bands.) There is also talk about
a EC version of GPS/GLONASS coming online (so they don't have to
depend upon a US DoD controlled system.)
Ron
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Thu, 9 Mar 2000 22:53:38 -0000
[snip XOR->hash->key]
> This should cause the PRNG to generate a different stream
every
> time, but does it introduce a new weakness?
It will be stronger than using the same key every time. But
it will be no stronger tham using the concatenation as the
input to the hash. There may be cases where using the XOR of
the key and IV will present the ability to break the method,
but these are likely to be excessively rare, and may not
even exist in any usable sense.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Thu, 9 Mar 2000 23:08:41 -0000
> Do you know where i can find, outside of subscribing to
IEEE, the spec
> for the MQV key exchange? Is there an independ document
describing the
> process..
I have a copy of the Aug 1998 paper if you'd like me to send
it to you, it's 211K.
> Is the MQV key exchange process independent of ECC / D&H
style problems.
I appears so.
> Is using an ECC, like described in p1363, going to have
potential
> patent $ issues. ( Number of patents on web site look
daunting )
To the best of my knowledge, ECC itself is not patented,
although many algorithms to do it efficiently are patented.
> I understand, I was actually indending to make sure that
the key
> agreement were as pesimistic as possible, to use the
safer/longer hash
> values.
MQV should be suitable for this.
> My thinking was to switch Hash function after successfull
negotiation.
> So to use SHA-1 during key exchange, and the first 2(n?)
packets of
> real data, then move to a faster MD4/5 for the bulk of the
data
> transfer?
IMO the security difference doesn't justify going with MD5
over SHA-1, and having only one hash function makes for a
smaller, simpler program
> Because sending One packet / wait reply, has large delays
anyway, the
> extra overhead in protecting it will not be noticed, but
sending
> _large_ volumes of data after it, the SHA-1 hash overhead
would begin
> to be noticeable.
It's not too likely to be noticable. On a pentium-II 300,
I'm getting 16MB/sec of SHA-1, but I get up to 36MB/sec of
MD5.
You shouldn't be disappointed with the security if you
follow your suggestions, ECC, Twofish, SHA-1, and MQV are
pretty much as strong as anything available.
Joe
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Linking Time-Stamping Servers
Date: Fri, 10 Mar 2000 09:03:57 +0100
Ron Skoog wrote:
>
> Mike Rosing wrote:
> >
> > Jean Marc Dieu wrote:
> > >
> > > Have anyone heard about ways/protocols to link several Time-Stamping
> > > Servers?
> > > By linking I mean two things:
> > >
> > > 1. Synchronize clocks (What are the options: NTP,... and there
> > > effectiveness against an attack such as (Distributed) Denial of Service)
> >
> > Lock all servers to an external clock. Most countries have a time
> > base standard which is broadcast by radio. By comparing the time
> > base with the time from another server you get a much better idea
> > of what the sync delays are. Drifts in any server can also be
> > corrected by the server itself. Radio jamming will wipe out
> > one server, but it would be hard to get them all without jamming the
> > source. And in most countries, that would be noticed :-)
> >
> The sources available in the US, ignoring network distributed time
> because of the reference to DDoS, are (AFAIK) the Naval Observatory
> radio broadcast time signal, the GPS and GLONASS (Russian version of
> GPS) satellite time signals, and the phone company (TPC ;{). There
> may also be a separate TV band time signal since my TV set uses a
> local PBS channel to set it's clock.
>
> Others should have access to the satellite time signals and any local
> broadcast time signals (radio or TV bands.) There is also talk about
> a EC version of GPS/GLONASS coming online (so they don't have to
> depend upon a US DoD controlled system.)
NTP is definitely the 'Right Way' to sync servers, with a suitable set
of local and (private) WAN attached reference clocks, plus peering
arrangements to other references, it is _extremely_ hard to persuade a
low-stratum clock to give significantly wrong time.
Even if you use both DDos and radio interference to suppress all
external clocks, an ensemble of standard workstations (even cheap old
Sparc's) will still use each servers best estimate of the current drift
rate to 'coast' along.
One number mentioned either in comp.protocols.time.ntp or in the NTP FAQ
was that a Sparc-station managed to stay within 3 ms of true UTC time
after beeing off-net for a week.
Anyway, a server which has been cut totally off the 'Net isn't much use
a time-stamping server anyway?
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: "Lassi Hippel�inen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: Crypto Patents: Us, European and International.
Date: Fri, 10 Mar 2000 08:17:03 GMT
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Terry Ritter) writes:
>
> >On 10 Mar 2000 00:09:31 GMT, in <8a9efr$9ud$[EMAIL PROTECTED]>, in
> >sci.crypt [EMAIL PROTECTED] wrote:
>
> >>1. A patent is not always necessary. If you make your findings public noone
> >>else will be able to patent any closely related algorithm.
>
> >This is, of course, only true if "you" are the first one to publish
> >the idea, or apply for the patent. "You" can give up your rights, but
> >you cannot give up the rights of others.
>
> No. Prior art invalidates all subsequent patent rights. Thus you, by
> making something public and thus prior art extinguish everyone else's
> right to patent that thing. Thus you can "give up the rights of others".
Still more nitpicking...
If someone else has a pending patent application on the idea, it will
not be invalidated by someone else's publication. The "submarine
patents" that surface long after an idea is put to free commercial use
have been a problem every now and then. By publishing your own invention
you still cannot be sure it is free.
There are national differences. In Europe, every patent application will
become public 18 months after it has been filed. In the USA it is
possible to delay publication by filing improvements to it.
There is a famous case in the auto industry, where the patent was issued
40 years (IIRC) after applying for it. The royalties were pretty big,
because everybody thought the technology was public by then, and were
using it extensively.
And then there is the first-to-invent vs. first-to-file debate, and
grace periods after publication, and ...
-- Lassi
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: NIST, AES at RSA conference
Date: 10 Mar 2000 08:38:19 GMT
Terry Ritter <[EMAIL PROTECTED]> wrote:
> There is ample reason to believe that using multiple different ciphers
> in sequence might hide weakness in a particular cipher:
Ever heard of Shannon? How about Feistel? How about ``rounds''?
You seem to think that there's some magical intermediate stage between
simple operations and complete encryption functions. You artificially
divide the design of encryption functions into the design of ``ciphers''
from simple operations and then the design of encryption functions from
ciphers. You artificially limit your notion of cryptanalysis to the
process of studying and breaking individual ``ciphers.''
In reality, there is no such stage. All encryption functions are built
from simple operations. Functions have to meet some cost requirements---
in particular, for most applications, they have to be fast---but they
don't have to follow any predetermined internal structure. Cryptanalysts
try to break the functions.
There is no reason to believe that your favorite encryption function is
stronger than simpler, faster functions with the same key length.
---Dan
------------------------------
From: "Andrzej Nowak" <[EMAIL PROTECTED]>
Subject: subscribe
Date: Fri, 10 Mar 2000 08:43:49 GMT
subscribe
------------------------------
** 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
******************************
