Cryptography-Digest Digest #59
Cryptography-Digest Digest #59, Volume #14Mon, 2 Apr 01 02:13:01 EDT Contents: Avoiding bogus encryption products: Snake Oil FAQ (C Matthew Curtin) From: C Matthew Curtin <[EMAIL PROTECTED]> Crossposted-To: alt.security,comp.security.misc,comp.infosystems,comp.answers,sci.answers,alt.answers,news.answers Subject: Avoiding bogus encryption products: Snake Oil FAQ Date: 2 Apr 2001 05:39:02 GMT URL: http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Version: 1.9 Archive-name: cryptography-faq/snake-oil Posting-Frequency: monthly Snake Oil Warning Signs: Encryption Software to Avoid Copyright © 1996-1998 Matt Curtin <[EMAIL PROTECTED]> April 10, 1998 Contents * Contents * Introduction * Basic Concepts o Symmetric vs. Asymmetric Cryptography o Secrecy vs. Integrity: What are you trying to protect? o Key Sizes o Keys vs. Passphrases o Implementation Environment * Snake Oil Warning Signs o ``Trust Us, We Know What We're Doing'' o Technobabble o Secret Algorithms o Revolutionary Breakthroughs o Experienced Security Experts, Rave Reviews, and Other Useless Certificates o Unbreakability o One-Time-Pads o Algorithm or product X is insecure o Recoverable Keys o Exportable from the USA o ``Military Grade'' * Other Considerations * Glossary * Index * References Administrativia Distribution Distribution of this document is unlimited. We're specifically trying to reach people who are not experts in cryptography or security but find themselves making decisions about what sorts of crypto (if any) to use, both for their organizations and for themselves. The Snake Oil FAQ is posted monthly to sci.crypt, alt.security, comp.security, comp.answers, and comp.infosystems. It is available in PostScript and PDF form (ideal for printing) via the web at http://www.interhack.net/people/cmcurtin/snake-oil-faq.ps http://www.interhack.net/people/cmcurtin/snake-oil-faq.pdf and HTML at http://www.interhack.net/people/cmcurtin/snake-oil-faq.html Disclaimer All contributors' employers will no doubt disown any statements herein. We're not speaking for anyone but ourselves. This is a compilation of common habits of snake oil vendors. It cannot be the sole method of rating a security product, since there can be exceptions to most of these rules. From time to time, a reputable vendor will produce something that is actually quite good, but will promote it with braindead marketing techniques. But if you're looking at something that exhibits several warning signs, you're probably dealing with snake oil. Every effort has been made to produce an accurate and useful document, but the information herein is completely without warranty. This is a work-in-progress; feedback is greatly appreciated. If you find any errors or otherwise wish to contribute, please contact the document keeper, Matt Curtin <[EMAIL PROTECTED]> Document History With the rise in the number of crypto products came a rise in the number of ineffective or outright bogus products. After some discussion about this on the cypherpunks list, Robert Rothenburg <[EMAIL PROTECTED]> wrote the first iteration of the Snake Oil FAQ. Matt Curtin took the early text and munged it into its current state with the help of the listed contributors (and probably some others whose names have inadvertently missed. Sorry in advance, if this is the case.) Contributors The following folks have contributed to this FAQ. Jeremey Barrett <[EMAIL PROTECTED]> Steven M. Bellovin <[EMAIL PROTECTED]> Matt Blaze <[EMAIL PROTECTED]> Bo Dvmstedt <[EMAIL PROTECTED]> Gary Ellison <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Larry Kilgallen <[EMAIL PROTECTED]> Dutra Lacerda <[EMAIL PROTECTED]> Felix Lee <[EMAIL PROTECTED]> Colin Plumb <[EMAIL PROTECTED]> Jim Ray <[EMAIL PROTECTED]> Terry Ritter <[EMAIL PROTECTED]> Robert Rothenburg <[EMAIL PROTECTED]> Adam Shostack <[EMAIL PROTECTED]> Rick Smith <[EMAIL PROTECTED]> Randall Williams <[EMAIL PROTECTED]> Introduction Good cryptography is an excellent and necessary tool for almost anyone. Many good cryptographic products are available commercially, as shareware, or free. However, there are also extremely bad cryptographic products which not only fail to provide security, but also contribute to the many misconceptions and misunderstandings surrounding cryptography and security. Why ``snake oil''? The term is used in many fields to denote something sold without consideration of its quality or its ability to fulfill its vendor's claims. This term originally applied to elixirs sold in traveling medicine shows. The salesmen would claim their elixir would cure
Cryptography-Digest Digest #58
Cryptography-Digest Digest #58, Volume #14Mon, 2 Apr 01 02:13:01 EDT
Contents:
AES ("Tom St Denis")
Re: Problematic Patent (Terry Ritter)
Re: efficient rabin signature? (Benjamin Goldberg)
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: AES
Date: Sun, 1 Apr 2001 23:56:37 -0400
When will AES become a final standard?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Problematic Patent
Date: Mon, 02 Apr 2001 05:35:46 GMT
On 1 Apr 2001 20:34:37 -, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Rich Wales) wrote:
>Sam Simpson wrote:
>
>> Or, to turn your comment on it's head: any use of this
>> scheme previous to 4th Jan 00 would act as prior art?
>
>Well, the application for patent 6,165,072 was filed on 4 January
>2000. However, the patent holders made very similar claims in an
>earlier US patent (6,030,288), filed 2 September 1997 [see claim
>13 in this earlier patent]. So I suppose use of this scheme would
>have to precede that earlier date in order to qualify as prior art.
Note that the phrase "prior art" is a "term of art" in patent law:
"Prior art" does not necessarily refer to an earlier *use* of the
invention, but instead, earlier *publication*. We might think of it
as what the average worker in the field could have known from public
sources. Normally, "a publication" is expected to be available in
public libraries.
Finding a use of an invention buried in some early software probably
would not be considered "prior art" in the patent sense, unless that
software somehow disclosed to the public how to make the invention.
Disclosure to the public of how to make the invention is what this is
all about.
The ideal "prior art" is an earlier patent, or a magazine article, or
a paper given at some scientific meeting and published in the
proceedings, or a book, all of which have nice firm publication dates.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: efficient rabin signature?
Date: Mon, 02 Apr 2001 05:37:29 GMT
Tom St Denis wrote:
>
> This has most likely been proposed before... but here is an idea I was
> just thinking of..
>
> The secret key is which are two large primes (congruent to 3 mod
> 4) such that N=pq is a blum integer. To sign a message you perform
> the following.
>
> 1. K = (hash of message) * 65536
> 2. if J(N, K) = 1 then solve for the principal square root of K and
> store it in M and goto step 4
> 3. If J(N, K) = -1 then increment the lower 16 bits of K and goto 2
> 3. Output M
Is J the Jacobi symbol? If so, is J(N, K)==0 possible, and if so, what
happens when then? Nevermind, it only occurs if K is a factor of N.
In psuedo-C code, the above algorithm is:
for( K = H(message)<<16 ; J(N, K) != 1; ++K );
signature = modsqrt(K, p, q)[0];
>
> To verify you simply do
> 1. K = M^2 mod N
> 2. Divide K by 65536
> 3. Compare K against the hash of the message.
verified = ((signature*signature % N) >> 16) == H(message)
>
> Obviously some modifications can be made for example storing the lower
> 16 bits along with M such that they can be compared. Also modifying
> the upper bits of K as (if) required.
AFAIKS, there does not seem to be any harm in modifying the lower bits
of the hash directly. Reserving 16 bits seems silly. Here's my version
of the scheme:
Signing:
for( K = H(message), M = 0 ; J(N, K) != 1; ++K, ++M );
signature = { modsqrt(K, p, q)[0], M };
Verification:
K = signature[0] * signature[0] % N;
M = signature[1];
while( M > 0 ) { // This loop is a test for a subliminal channel in M.
--K, --M;
if( J(N, K) == 1 ) {
verified = false;
return;
}
}
verified == (K-M) == H(message);
Note: modsqrt(K, p, q) returns a vector containing all the sqrts of K
mod pq, with the principle sqrt as the first element. Why not just
write principlesqrt(K, p, q)? 'cause its more letters :) Obviously it
has to get the parameters p and q, not pq, since it can't work without
them.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
--
** 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
**
Cryptography-Digest Digest #57
Cryptography-Digest Digest #57, Volume #14Sun, 1 Apr 01 23:13:00 EDT
Contents:
Re: Data dependent arcfour via sbox feedback (Gregory G Rose)
Re: Problematic Patent (Gregory G Rose)
Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
primitive polynomial search program (Sean)
Re: AES VS. DES ("Paul Pires")
Re: Idea - (LONG) (Nicol So)
Re: What happens when RSA keys don't use primes? (David A Molnar)
Re: NEWS READER CRASHING (Nicol So)
Re: New stream cipher (David A Molnar)
Re: Deny Anon Remailers access to this newsgroup (David A Molnar)
Re: NEWS READER CRASHING (Darren New)
Re: New stream cipher (Paul Rubin)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Problematic Patent ("boobaloo")
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Data dependent arcfour via sbox feedback
Date: 1 Apr 2001 15:45:16 -0700
In article ,
Bryan Olson <"nospam"@"nonsuch.org"> wrote:
>How about CBC-mode Rijndael? Rijndael is of course a block
>cipher, but CBC-mode Rijndael is a stream cipher. I'll let
I think you meant CFB (Ciphertext Feedback Mode)
or OFB (Output Feedback Mode). CBC (Cipher Block
Chaining) is nothing like a stream cipher.
CFB is plaintext-aware, OFB is not.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
--
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Problematic Patent
Date: 1 Apr 2001 15:52:45 -0700
There's a method by Rivest and Shamir (IIRC) that
was published way back, for a mutual
authentication method done by sending a hash then
following through with the data later. I think
it's called "interlock authentication"...
something like that. It's in Schneier's AC2, but
I'm not in a position to look it up at the moment.
good luck,
Greg.
In article ,
boobaloo <[EMAIL PROTECTED]> wrote:
<
http://164.195.100.11/netahtml/srchnum.htm)
<
>>
<
<51. Apparatus for creating and verifying secret data transactions over a
http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data dependent arcfour via sbox feedback
Date: Mon, 02 Apr 2001 00:57:57 +0200
Gregory G Rose wrote:
>
> Bryan Olson <"nospam"@"nonsuch.org"> wrote:
> >How about CBC-mode Rijndael? Rijndael is of course a block
> >cipher, but CBC-mode Rijndael is a stream cipher. I'll let
>
> I think you meant CFB (Ciphertext Feedback Mode)
> or OFB (Output Feedback Mode). CBC (Cipher Block
> Chaining) is nothing like a stream cipher.
>
> CFB is plaintext-aware, OFB is not.
Is the classical auto-key encryption a stream cipher?
If yes, then CBC of a block cipher could be similarly
considered to be a stream cipher (one has more bits in
a block than in a character of auto-key encryption of
the historical version, of course), I suppose. It appears
therefore that one shouldn't make an overly strict
distinction between block and stream ciphers.
M. K. Shen
--
From: Sean <[EMAIL PROTECTED]>
Subject: primitive polynomial search program
Date: Sun, 01 Apr 2001 23:38:59 GMT
I've written a C language primitive polynomial search program which finds
primitive polynomials of degree n, modulo p for any prime p such that
p^n <= 2^62.
It's fairly fast, taking less than a few seconds in most cases on a Pentium
class PC. The algorithm is based on the method of Alanen and Knuth in the
journal Sankyha.
Source code is available under the GNU Public License with detailed
documentation at http://seanerikoconnor.freeservers.com
under Professional Interests, Primitive Polynomial Generation.
Alternate location is http://seanerikoconnor.freeyellow.com
--
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Sun, 1 Apr 2001 16:39:26 -0700
James Wyatt <[EMAIL PROTECTED]> wrote in message
news:LZJx6.538925$[EMAIL PROTECTED]...
> I read somewhere that it would take longer than the Earth has existed to use
> a brute force attack on AES. That is assuming one processor running around 1
> gHz. I have no doubt that the NSA has methods to break this algorithm
They are not godlike. They may waste time and money, but probably not
by design. What you are saying is that:
The designers of AES were in cahoots with the NSA.
or
The NSA found a way to break AES that has escaped the public analysis.
or
The NSA has godlike powers beyond the ken of mere mortals.
Keep it simple. They might have a break on AES but probably not.
They are probably not working actively on one but merely letting
thier analis
Cryptography-Digest Digest #56
Cryptography-Digest Digest #56, Volume #14Sun, 1 Apr 01 18:13:00 EDT
Contents:
Re: Problematic Patent (Rich Wales)
Re: Idea - (LONG) ("Douglas A. Gwyn")
Re: Problematic Patent ("Sam Simpson")
Re: NEWS READER CRASHING (SCOTT19U.ZIP_GUY)
Re: texts on factoring? ("M.S. Bob")
Re: Idea - (LONG) (Mok-Kong Shen)
Re: AES VS. DES (SCOTT19U.ZIP_GUY)
Re: NEWS READER CRASHING (Mok-Kong Shen)
Re: AES VS. DES ("Tom St Denis")
Re: Problematic Patent (Rich Wales)
Re: AES VS. DES (Mok-Kong Shen)
Re: texts on factoring? (Paul Rubin)
Re: Idea - (LONG) (Nicol So)
Re: Problematic Patent (Mok-Kong Shen)
Re: texts on factoring? ("Tom St Denis")
Re: Idea - (LONG) (Nicol So)
Re: Idea - (LONG) (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: Problematic Patent
Date: 1 Apr 2001 19:28:34 -
"boobaloo" wrote:
> A patent has been recently issued that appears absurdly
> broad . . . US patent 6165072 (enter number here:
> http://164.195.100.11/netahtml/srchnum.htm)
> Claim 51 would seem to cover any situation in which one
> sends encrypted data and then later sends the plaintext.
Actually, it sounds like it covers a situation in which one computes
and sends a checksum / fingerprint / signature / message digest of a
file, followed by the file itself. (Note that the patent describes
the transform as "irreversible".)
For example, if I post to a newsgroup (or on a Web page) saying that a
particular file is at such-and-so place on the net, and here's its MD5
fingerprint so you can verify that your downloaded copy of the file is
intact, then I've apparently infringed on this patent claim. (!)
An almost identical situation would be a CD-ROM with pieces of software
plus their MD5 checksums -- so the installation process can verify that
each piece of the distribution was read correctly from the CD. FreeBSD
releases have employed this technique for years, and I'm sure there are
many other examples. This isn't absolutely the same as what is claimed
in the patent (both the data and the checksum are sent simultaneously,
and sending someone a CD-ROM isn't exactly the same as sending data via
a network), but the differences seem trivial in my opinion.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/pgp/
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Idea - (LONG)
Date: Sun, 01 Apr 2001 19:55:56 GMT
Mok-Kong Shen wrote:
> The r bits (as key) is assumed to be from a perfect source.
The plaintext source. Standard terminology.
--
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Problematic Patent
Date: Sun, 1 Apr 2001 20:54:35 +0100
Rich Wales <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "boobaloo" wrote:
>
> > A patent has been recently issued that appears absurdly
> > broad . . . US patent 6165072 (enter number here:
> > http://164.195.100.11/netahtml/srchnum.htm)
> > Claim 51 would seem to cover any situation in which one
> > sends encrypted data and then later sends the plaintext.
>
> Actually, it sounds like it covers a situation in which one computes
> and sends a checksum / fingerprint / signature / message digest of a
> file, followed by the file itself. (Note that the patent describes
> the transform as "irreversible".)
>
> For example, if I post to a newsgroup (or on a Web page) saying that a
> particular file is at such-and-so place on the net, and here's its MD5
> fingerprint so you can verify that your downloaded copy of the file is
> intact, then I've apparently infringed on this patent claim. (!)
Or, to turn your comment on it's head: any use of this scheme previous to
4th Jan 00 would act as prior art?
--
Regards,
Sam
http://www.scramdisk.clara.net/
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEWS READER CRASHING
Date: 1 Apr 2001 20:05:10 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in <3AC7728A.CF775BAB@t-
online.de>:
>
>
>John Savard wrote:
>>
>> [EMAIL PROTECTED] wrote:
>>
>> > I have noticed that sometimes I get a message that flat crashes
>> >my newsreader. I found it best to just not look at such messages
>> >a second time becasue it is repeatable. I use Xnews read for now
>> >but today I opened a message up and the next thing I new my browser
>> >opened and was sending mail. I killed the connection but has this
>> >happened to any one else. The post that caused the mail was in
>> >another news group but it kind of surprised me.
>>
>> There was a malicious JavaScript posting in several newsgroups -
>> including this one. Some newsreaders, like Free Agent, don't try to
>> execute content from postings you view.
>
>Note though that certain web pages that one access or links
>therefrom involve jav
Cryptography-Digest Digest #55
Cryptography-Digest Digest #55, Volume #14Sun, 1 Apr 01 15:13:01 EDT
Contents:
Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST OR
SEND - TIA! (Nemo psj)
Certicom's ECCp-109 (Chris Monico)
Re: AES VS. DES ("James Wyatt")
Problematic Patent ("boobaloo")
Re: conferences? ("M.S. Bob")
Re: AES VS. DES ("Tom St Denis")
Re: AES VS. DES (SCOTT19U.ZIP_GUY)
Re: AES VS. DES (SCOTT19U.ZIP_GUY)
Re: NEWS READER CRASHING (Mok-Kong Shen)
Re: conferences? ("Tom St Denis")
Re: AES VS. DES ("Tom St Denis")
Re: Idea - (LONG) (Mok-Kong Shen)
Re: Malicious Javascript in Brent Kohler post (was: Re: Who is Brent K (Mok-Kong
Shen)
Re: AES VS. DES (Mok-Kong Shen)
From: [EMAIL PROTECTED] (Nemo psj)
Date: 01 Apr 2001 15:13:09 GMT
Subject: Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST
OR SEND - TIA!
I'm not the one who wanted to get a copy of that book. You idiots need to look
at the name of the posters before you get all hot temperd. I was agreing with
you guys. All I can say is Wow it takes some special people to do something so
dumb.
Get your facts straight.
--
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Certicom's ECCp-109
Date: Sun, 01 Apr 2001 17:04:40 GMT
Hello all,
I'm preparing to launch a distributed effort to solve Certicom's
ECCp-109 elliptic curve DLP challenge, and I just wanted to ask around
to make sure nobody is already undertaking this challenge. I've
already asked Rob Harley and he's not doing this one; I had made the
assumption that he would know if anyone else was doing it, but perhaps
this is a bad assumption, so I thought I'd ask here as well. So, does
anyone know of a group that's working on this challenge?
If so, please drop me an email as I haven't been religously reading
my newsgroups lately.
Cheers,
Chris
[EMAIL PROTECTED]
--
From: "James Wyatt" <[EMAIL PROTECTED]>
Subject: Re: AES VS. DES
Date: Sun, 01 Apr 2001 17:56:59 GMT
I read somewhere that it would take longer than the Earth has existed to use
a brute force attack on AES. That is assuming one processor running around 1
gHz. I have no doubt that the NSA has methods to break this algorithm, but
unless they've got the only working quantum computer, they can't possibly
use brute force.
Jim
"Brian Gladman" <[EMAIL PROTECTED]> wrote in message
news:FNDx6.3648$Ph.156193@stones...
> "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 know
Cryptography-Digest Digest #54
Cryptography-Digest Digest #54, Volume #14Sun, 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 -
[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
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
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 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.lin
$ cat x.sig
-BEGIN PGP
Cryptography-Digest Digest #53
Cryptography-Digest Digest #53, Volume #14Sun, 1 Apr 01 05:13:00 EDT
Contents:
NEWS READER CRASHING (SCOTT19U.ZIP_GUY)
Re: conferences? (Benjamin Goldberg)
Re: conferences? ("Tom St Denis")
Re: NEWS READER CRASHING (John Savard)
Re: What is ideal substitution cipher? (John Savard)
Re: Learning to write encryption algorithms. (John Savard)
Re: What is ideal substitution cipher? (newbie)
Re: simple stream cipher (hehehe) (Benjamin Goldberg)
Re: simple stream cipher (hehehe) ("Tom St Denis")
efficient rabin signature? ("Tom St Denis")
Re: Idea - (LONG) ("Douglas A. Gwyn")
Re: What is ideal substitution cipher? ("Douglas A. Gwyn")
Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST OR
SEND - TIA! (Nemo psj)
Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST OR
SEND - TIA! ("Tom St Denis")
Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST OR
SEND - TIA! (Ben Cantrick)
Re: DOES ANYONE HAVE "THE CODE BOOK" BY SIMON SINGH IN PDF FORMAT? PLZ POST OR
SEND - TIA! ("Tom St Denis")
Re: What do we mean when we say a cipher is broken? (Paul Crowley)
Re: What do we mean when we say a cipher is broken? ("Tom St Denis")
AES VS. DES ("Latyr Jean-Luc FAYE")
encryption method used in MSPassport? (Matthew)
Re: AES VS. DES (SCOTT19U.ZIP_GUY)
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: NEWS READER CRASHING
Date: 1 Apr 2001 00:24:09 GMT
I have noticed that sometimes I get a message that flat crashes
my newsreader. I found it best to just not look at such messages
a second time becasue it is repeatable. I use Xnews read for now
but today I opened a message up and the next thing I new my browser
opened and was sending mail. I killed the connection but has this
happened to any one else. The post that caused the mail was in
another news group but it kind of surprised me.
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: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: Sun, 01 Apr 2001 00:46:52 GMT
Tom St Denis wrote:
[snip]
> The cipher is better in the encryption direction since the matrix
> [2 1] .. [1 1] is simple to implement... a multiplication of 2 is
> basically computed via
>
> if (x & 0x80)
> return (x << 1) ^ 0x69;
> else
> return x <<1;
>
> (C notation). I can even precompute this easily...
Which is faster, the above, or
return ((x&0x80) ? 0x69 : 0) ^ (x<<1);
I suspect that the latter might be faster, by virtue of using a
conditional assign, rather than a conditional branch.
Of course, a smart compiler might be able to optimize the first to the
second.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
--
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: conferences?
Date: Sun, 01 Apr 2001 00:56:34 GMT
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> [snip]
> > The cipher is better in the encryption direction since the matrix
> > [2 1] .. [1 1] is simple to implement... a multiplication of 2 is
> > basically computed via
> >
> > if (x & 0x80)
> > return (x << 1) ^ 0x69;
> > else
> > return x <<1;
> >
> > (C notation). I can even precompute this easily...
>
> Which is faster, the above, or
> return ((x&0x80) ? 0x69 : 0) ^ (x<<1);
>
> I suspect that the latter might be faster, by virtue of using a
> conditional assign, rather than a conditional branch.
>
> Of course, a smart compiler might be able to optimize the first to the
> second.
Yours is probably faster, but that wasn't my point. I wanted to make the
code simple and easy to work with.
Tom
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEWS READER CRASHING
Date: Sun, 01 Apr 2001 00:59:33 GMT
On 1 Apr 2001 00:24:09 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
> I have noticed that sometimes I get a message that flat crashes
>my newsreader. I found it best to just not look at such messages
>a second time becasue it is repeatable. I use Xnews read for now
>but today I opened a message up and the next thing I new my browser
>opened and was sending mail. I killed the connection but has this
>happened to any one else. The post that caused the mail was in
>another n
