Cryptography-Digest Digest #54, Volume #14 Sun, 1 Apr 01 11:13:00 EDT
Contents:
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Advice on storing private keys (those who know me have no need of my name)
Re: AES VS. DES ("Brian Gladman")
Re: Perl public key encryption (those who know me have no need of my name)
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K Kohler?)
(those who know me have no need of my name)
Re: Symmetric cipher security of GnuPG 1.0.4 (Florian Weimer)
RSA (Yechuri)
Re: RSA ("Sam Simpson")
Re: AES VS. DES ("Tom St Denis")
Re: AES VS. DES (SCOTT19U.ZIP_GUY)
Re: Symmetric cipher security of GnuPG 1.0.4 (SCOTT19U.ZIP_GUY)
Re: AES VS. DES (DJohn37050)
----------------------------------------------------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sun, 01 Apr 2001 10:16:12 GMT
In article <[EMAIL PROTECTED]>, Terry Ritter wrote:
>
>Bryan Olson wrote:
>>RC4 and the proposed
>>modification do not encrypt by substitution of the data
>>characters; that's what makes Ritter's patent inapplicable.
>
>I can only discuss the issue theoretically: I can't speak to either
>RC4 or the current proposal.
Well, you could if you looked at them.
>However, the Dynamic Substitution claims do not require encryption by
>substitution.
All the claims on encryption methods require two data
sources, the first of which is transformed by substitution
to form the output or substitute values.
[...]
>>I'm not sure it's been stated, so I'll note an obvious
>>defect in the proposed scheme: If we grant the attacker
>>multiple known plaintexts from the same starting state, he
>>can easily discover the state.
>
>In general, any stream cipher must avoid re-using a previous state.
How about CBC-mode Rijndael? Rijndael is of course a block
cipher, but CBC-mode Rijndael is a stream cipher. I'll let
you choose any texts you like, including the IV so you can
re-start from the same state as often as you like. What can
you recover?
With RC4, state-reset will repeat the PRNG sequence, but
will not reveal the state (under any known attack). With
the modified system, state-rest exposes the state, and thus
the attacker can determine the sequence even beyond the
length of the chosen texts.
--Bryan
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Subject: Re: Advice on storing private keys
Date: Sun, 01 Apr 2001 10:24:30 -0000
[dang, quite a bit of backlog. sorry for the delay.]
<[EMAIL PROTECTED]> divulged:
>don't think I will send digital signatures and certs over packet
>radio until I get a ruling from the FCC.
sounds sensible. i would suggest actively pursuing it with them, so
that you get an actual decision. unfortunately it won't help anyone
outside the usa. postcards don't have this problem, i.e., nothing
tremendous had to be negotiated beforehand to prevent it's failure for
some (perhaps large) fraction of the (world-wide) amateur population.
don't forget to remind them that signatures are not the same as
encryption, and they are based on public standards. and that encoding
is no different (in kind) than the signalling used by packet modems, it
does not exclude anyone, because it is also specified by standards and
can be "read" by anyone.
>When I have dealt with standard certs before, I found them to be
>very error prone.
really? i would be very surprised. x.509 certificates are used
millions of times every day for ssl connections, e.g., e-commerce
mostly.
> 1. Open source. For it work logbook authors have to put it
> into their programs and most are too cheap to pay for it.
openssl can provide all the x.509 related functions you are likely to
need, and it is very open (bsd-based license). see
<url:http://www.openssl.org> for more information.
if you need to run a ca you might want to look at the openca project,
which is also very open (bsd license). see
<url:http://www.sourceforge.com/projects/openca> for more information.
gnupg can provide everthing you need for a "web of trust" based model,
and is fairly open (gpl). see <url:http://www.gnupg.org> for more
information.
your items 2, 3, 4, and 6 are present and very easy to use in either
openssl or gnupg. openca is not as mature, but still very usable.
the requirement that it process a batch of signatures is doable, but
they have to be compared against something, so you'll have to integrate
whatever mechanism you choose and that might mean a little code.
> 5. The signature with cert should be able to be stored as ascii
> in a field of a single line record. The record doesn't have a length
> restriction.
typically they are multi-line, but there's no requirement that it be
that format, that i'm aware of. i quickly tested gnupg, e.g.,
$ gpg -bau testkey <x | tee x.sig | sed '1,/^$/d;/^-/d' | xargs >x.lin
$ cat x.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjrG+esACgkQ7A21VUcos05dsQCfS90oGCChJmTbwXtB+aDnUpsy
tyUAn1K4dBuFOpkkQKBL9NyvMShc1Axy
=YVSo
-----END PGP SIGNATURE-----
$ cat x.lin
iEYEABECAAYFAjrG+esACgkQ7A21VUcos05dsQCfS90oGCChJmTbwXtB+aDnUpsy
tyUAn1K4dBuFOpkkQKBL9NyvMShc1Axy =YVSo
$ gpg --verify x.sig x
gpg: Signature made Sun Apr 1 09:50:35 2001 GMT using DSA key ID 4728B34E
gpg: Good signature from "testkey"
# i have to manufacture the head and tail line of a signature block for gpg
$ ( echo "-----BEGIN PGP SIGNATURE-----"
echo ""
cat x.lin
echo "-----END PGP SIGNATURE-----" ) \
| gpg --verify - x
gpg: Signature made Sun Apr 1 09:50:35 2001 GMT using DSA key ID 4728B34E
gpg: Good signature from "testkey"
> 7. Must be trusted/secure
they're secure, as long as your structure is secure. if you need a
hierarchal model then x.509 is the way to go, whereas if a "web of
trust" model would be better then openpgp is more appropriate.
>I am also fighting a battle of time.
both openssl and gnupg are ready now, and only require that you decide
on the trust model you need/want and begin using the tools.
e.g., you could create an openpgp dsa-only key for yourself and submit
it to one of the usual public keyservers. at that point you can send
signed e-mail (qsl's) to anyone, and they'd have proof that you signed
it since they could obtain your key from one of the keyservers, or
perhaps receivers only need to validate a single key by having all qsl's
sent through a clearinghouse ...
$ gpg --batch --gen-key --send-keys --keyserver wwwkeys.pgp.net <<-eof
Key-Type: DSA
Key-Length: 1024
Name-Real: your name - yourcallsign
Name-Email: [EMAIL PROTECTED]
Name-Comment: for trustedqsl signatures only
Expire-Date: 1y
eof
then for each qsl you want to send you sign something fairly specific,
send it, to the trustedqsl clearing house perhaps. perhaps like so:
$ echo "yourcallsign qsl xxxxx on 11.780 khz
between 2001-01-01 18:18 and 2001-01-01 18:35 (gmt)" \
| gpg -sau yourcallsign --clearsign \
| mail -s "yourcallsign qsl xxxxx - 11.780khz 2001-01-01 18:18"
[EMAIL PROTECTED] #or whatever
then the trusted qsl clearinghouse would verify your signature, perhaps
insisting that it have a local copy that they have signed or perhaps
just trusting the keyserver model. then it would sign and forward the
e-mail to the other station.
then when xxxxx receives it only the signature for the clearinghouse has
to be verified. perhaps your original signature remains present, so
that it's a chain.
it might be that the e-mail would be more structured, that's for you to
decide, this is just a quickie example.
many e-mail programs (mua's) already have pgp or gpg integration, so the
qsl can be verified without any additional, ham only, effort. some
mua's have provisions for s/mime, which would handle x.509 signed e-mail
directly.
--
okay, have a sig then
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Sun, 1 Apr 2001 11:59:59 +0100
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello,
> It's the 2nd time I post this message. I would like to know what are the
> difference between AES and its precursor DES. What are the advantage
> of AES vs DES.
The main advantages of AES over DES are that: (a) it offers a larger block
size - 128 bits in place of 64; (b) it offers longer key lengths of 128, 192
and 256 bits in place of 56 bits, and (c) it is more efficient, typically
2-3 times faster in software. The major disadvantage is that it is new and
may hence have as yet undiscovered (or undisclosed) weaknesses.
DES is still a very good cipher that has not been broken but increases in
processing capability since it was introduced now mean that it is vulnerable
to key search attacks - testing each of the 2^56 possible keys in turn and
seeing which of these give an ouptut with a pattern of some kind (for
example ascii characters).
If you accept that AES is a good cipher - one whose effective key lengths
are the same as its stated key lengths - then the minimum key length of 128
bits means that key search attacks are not currently feasible and not likely
to become so in the forseeable future. In consequence patterns in plaintext
are not the real problem for AES that they are for DES. And if you are
really paranoid you can use 256 bit keys.
As far as we know, AES is an unbroken cipher. But it is relatively new and
it is hence possible that it has weaknesses that have either not been
discovered or are not yet known to the public. You need to consider whether
such possibilities pose unacceptable potential risks.
You will, for example, hear suggestions that NSA can break AES and you will
need to make up your own mind whether such ideas have any credibility and,
if you think they do, whether or not this really matters to you.
The most important question to ask yourself here is: "why would the US - the
nation with the most advanced information based economy in the world - put
this economy (and hence its national security) at risk by encouraging the
use of a broken cipher in the protection of its national information assets
and its national information infrastructure?"
A rational look at (a) the history of DES; (b) the way the AES standard has
been developed, and (c) an objective consideration of the consequences for
the US if NSA were to knowingly advocate a FIPS standard cipher that they
knew to be broken; shoud allow you to judge the possible algorithm based
risks involved in using AES.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: comp.lang.perl.misc
Subject: Re: Perl public key encryption
Date: Sun, 01 Apr 2001 10:55:31 -0000
[dang, quite a bit of backlog. sorry for the delay.]
<kv8w6.53062$[EMAIL PROTECTED]> divulged:
>"those who know me have no need of my name" <[EMAIL PROTECTED]>
>wrote in message news:[EMAIL PROTECTED]...
>> [note: this is really a security rather than a cryptography issue]
>Noted. Sorry if this went to the wrong group.
no worries. i mainly mention it because while many sci.crypt readers
are also interested in this kind of security lots of people interested
in this kind of security aren't the types to read what is essentially a
math group.
[re: program tampering]
>True. Any suggestions as to how this could be prevented?
no, sorry. it's a complex problem. something that might be done,
provided the isp allows it, would be for a cron job to calculate a
series of signatures for the scripts and forward them to you via e-mail.
you check those signatures, and if there is any change you have a fit.
or you might have a cron job on your system that periodically fetches
the scripts from the web server and compares them to local copies.
those things are so full of secondary holes they are almost not worth
doing, but there isn't much else that can be done.
if you don't trust the isp's security (and i'm not saying you should or
shouldn't) why would you use them to host your e-commerce? yet, if you
do trust them you might find yourself in hot water, and them with a
liability clause that will (try to) keep them safe.
>Sadly, as I mentioned in my first post, my first choice ISP has stated that
>they will not allow the use of PGP on their webservers 'as it requires root
>access'. This sounds like a load of nonsense to me, so I'm looking at other
>ISP's who do provide PGP.
i missed that. sorry.
they are fools, it (pgp) requires no such thing. gpg is best installed
suid-root, so that it can perform page locking, but it is not necessary.
(in fact you might be able to compile gpg for their platform and upload
it somewhere within your private space to make it available to your
script. note: it should not be available to web clients directly,
i.e., not in /cgi-bin/.)
yes, you might use crypt::rsa to encrypt the files directly, but there
are some caveats which are a pain to deal with. (pgp/gpg do all that
work for you, using rsa only to encrypt a random session key to be used
by a block cipher for the encryption of the data.)
given that you have an isp that is this lame it might be better to ask
what encryption modules are already installed, since they might not want
to install anything else, and might prevent you from installing your
own.
>> umm. use https: to transfer the files.
>
>Yes, but isn't this rather tedious if there are lots of files to download?
nope.
zip everything, send the zip. that's only one possibility.
everything stored should be encrypted as a matter of course. since the
source data was delivered via ssl, or should have been, that leg is
good. before you store the data you should encrypt it to a public key
whose private key is not present on the isp's system.
--
okay, have a sig then
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.drugs.pot,rec.radio.swap,rec.running,rec.sport.skating.ice.figure
Subject: Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K
Kohler?)
Date: Sun, 01 Apr 2001 11:24:52 -0000
<[EMAIL PROTECTED]> divulged:
>How often would you use scripted mathematical formulae in news group
>postings? Creating a web page and linking to it would probably be a
>more useful solution.
in sci.crypt it might happen quite often, though it's usual for latex to
be used. since mathml is nearly unreadable i don't see why anyone would
want it, especially since it would mean that html (and other shite)
would have to be processed as well.
i would _much_ rather see latex than mathml -- you tell me:
latex ... x = \frac{-b\pm\sqrt{b^2 - 4ac}}{2a}
mathml ...
<mrow>
<mi>x</mi>
<mo>=</mo>
<mfrac>
<mrow>
<mrow>
<mo>-</mo>
<mi>b</mi>
</mrow>
<mo>±</mo>
<msqrt>
<mrow>
<msup>
<mi>b</mi>
<mn>2</mn>
</msup>
<mo>-</mo>
<mrow>
<mn>4</mn>
<mo>⁢</mo>
<mi>a</mi>
<mo>⁢</mo>
<mi>c</mi>
</mrow>
</mrow>
</msqrt>
</mrow>
<mrow>
<mn>2</mn>
<mo>⁢</mo>
<mi>a</mi>
</mrow>
</mfrac>
</mrow>
--
okay, have a sig then
------------------------------
From: Florian Weimer <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Symmetric cipher security of GnuPG 1.0.4
Date: 01 Apr 2001 12:54:56 +0200
jtnews <[EMAIL PROTECTED]> writes:
> Does anyone know if there any limit
> on passphrase length in GnuPG 1.0.4?
AFAIK, there isn't one.
> Is there a limit on the effectiveness
> of very long passphrases due to the
> implementation of the cipher algorithm?
It doesn't make sense to have more entropy in the passphrase than the
cipher algorithm can use with its key length (but too much entropy
isn't harmful anyway). Obviously, there's no generic way to translate
an entropy constraint to passphrase length limit.
------------------------------
From: [EMAIL PROTECTED] (Yechuri)
Date: 01 Apr 2001 12:55:49 GMT
Subject: RSA
Is RSA really free to use ?
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Sun, 1 Apr 2001 14:10:34 +0100
The patent was due to expire last year, but was released into the public
domain on the 6th of Septmeber, 2000. See:
http://www.rsasecurity.com/news/pr/000906-1.html
Either way you look at it, it's now free to use.
--
Regards,
Sam
http://www.scramdisk.clara.net/
Yechuri <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Is RSA really free to use ?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Sun, 01 Apr 2001 13:48:48 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Latyr Jean-Luc FAYE) wrote in
> <[EMAIL PROTECTED]>:
>
> >Hello,
> >It's the 2nd time I post this message.
> >I would like to know what are the difference between AES and its
> >precursor DES. What are the advantage of AES vs DES.
> >The first time, I got a nice answer of someone on the NG with a link to
> >his page about AES and I learnt lot of stuff.
> >But I lost the link. In fact I ma just hoping that anybody having a
> >website on AES or knowing a personnal website on AES will give me links.
> >May be I will find the one I lost.
> >Regards
> >
> >---
> >Latyr Jean-Luc FAYE
> >http://faye.cjb.net
> >
> >
> >
>
> DES is the old US standard its known to be weak in that its not to
> hard to break.
>
> AES is the new standard which the US government wants you to use.
> Telling you its totally safe. If might be safe as part of a larger
> package. But by itself I would bet the NSA can break it or they
> would not let it out. Since it will be in common use.
>
> http://csrc.nist.gov/encryption/aes/
>
>
> The best implimentation from a secruity point of view at this time
> that I know of is Matt's BICOM I have a pointer at my site.
> you could use his then run it through scott16u or scott19u as
> a second pass for more security. Trust me mine is not like AES
> or DES.
"More security"? Do you have any research to back up your claims?
BTW: Just FYI not every poster here is a bloody Yankee. So why are you
guys only paranoid against the US govt?
That and AES was designed by Belgium cryptographers wasn't it? ....
lalalallaalla.
Tom
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES VS. DES
Date: 1 Apr 2001 14:34:58 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<FNDx6.3648$Ph.156193@stones>:
>
>The most important question to ask yourself here is: "why would the US -
>the nation with the most advanced information based economy in the world
>- put this economy (and hence its national security) at risk by
>encouraging the use of a broken cipher in the protection of its national
>information assets and its national information infrastructure?"
Like any nation that thinks its on top. Its leaders do stupid things
and history is littered with the corpses of dead nations. True america
was the home of the brave and indavidualism. But has those in power begain
to fear those whose its there job to protect. At some point governemts
becomes more concerned with protecting itself from its on people. Look
at the UK. If a year before Mad Cow disease hit it. No one would
belive it. Since one would falsely assume that the governemt cared
about its own people and would try to prevent it from happening.
But those in poor want to hear on good things and to be patted on
the back so the truth is filtered and colored until something gets
bit in the ass.
>
>A rational look at (a) the history of DES; (b) the way the AES standard
>has been developed, and (c) an objective consideration of the
>consequences for the US if NSA were to knowingly advocate a FIPS
>standard cipher that they knew to be broken; shoud allow you to judge
>the possible algorithm based risks involved in using AES.
>
A rational look at history suggests otherwise. Look as recently
a few short years ago articles about modified swiss crypto machines
at the request of the NSA. Don't forget Echlon. Also since the
cipher was on paper at least designed outside the US. The NSA is
in a win win situation. If a easy break is found in public they
can say they did not design it. It would also make them look far
less capabile than they are. Which is the image you want to project
to keep your enemies thinking your weaker than you are.
Look at the AES competation itself. It really a closed club. Sure
I have posted comments on the hopes that at least one should use
bijective padding but have yet to hear a response that was quite
a while back. I think they want weak crypto and will make sure hooks
stay in to keep it weak.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.nbci.com/ecil/index.htm
Scott LATEST UPDATED sources for scott*u.zip
http://radiusnet.net/crypto/archive/scott/
Scott famous Compression Page
http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
A final thought from President Bill: "The road to tyranny,
we must never forget, begins with the destruction of the truth."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: gnu.misc.discuss
Subject: Re: Symmetric cipher security of GnuPG 1.0.4
Date: 1 Apr 2001 14:42:31 GMT
[EMAIL PROTECTED] (Florian Weimer) wrote in <[EMAIL PROTECTED]>:
>jtnews <[EMAIL PROTECTED]> writes:
>
>> Does anyone know if there any limit
>> on passphrase length in GnuPG 1.0.4?
>
>AFAIK, there isn't one.
>
>> Is there a limit on the effectiveness
>> of very long passphrases due to the
>> implementation of the cipher algorithm?
>
>It doesn't make sense to have more entropy in the passphrase than the
>cipher algorithm can use with its key length (but too much entropy
>isn't harmful anyway). Obviously, there's no generic way to translate
>an entropy constraint to passphrase length limit.
>
Does anyone know if there will ever me a mode in GnuPG that
would allow for a simple fully bijective compression and encryption
for messages not using a public key. So that at least the blocks of
data can be a true "bijective compression encryption" meaning any
key would lead to a decrypted decompressed file such that when
recompressed and encrypted you get the same data. At least in
the nonpublic key mode. So that it would be harder to attack.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.nbci.com/ecil/index.htm
Scott LATEST UPDATED sources for scott*u.zip
http://radiusnet.net/crypto/archive/scott/
Scott famous Compression Page
http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
A final thought from President Bill: "The road to tyranny,
we must never forget, begins with the destruction of the truth."
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 01 Apr 2001 15:07:18 GMT
Subject: Re: AES VS. DES
Brian Gladman's thoughts on this are very sane.
Don Johnson
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
