Cryptography-Digest Digest #608, Volume #13 Fri, 2 Feb 01 00:13:00 EST
Contents:
Re: Integer Functions in Encryption Algorithmy ([EMAIL PROTECTED])
Re: Integer Functions in Encryption Algorithmy ([EMAIL PROTECTED])
Re: fast signing ("Joseph Ashwood")
Re: fast signing (Paul Rubin)
Re: fast signing (Paul Rubin)
Re: Durstenfeld Transpositions & ARC4 ([EMAIL PROTECTED])
RE: Blowfish ("Liam McGann")
Re: Blowfish (Paul Rubin)
Re: Recommendations on simplest way to add client/server encryption (Eric Lee Green)
Re: How good is Diamond2 and Saphire ciphers? (Bryan Olson)
RE: Blowfish (Splaat23)
CipherText patent still pending ("Prichard, Chuck")
Where is the encryption hardware? ([EMAIL PROTECTED])
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: Durstenfeld Transpositions & ARC4 ("Scott Fluhrer")
Re: CipherText patent still pending ("Scott Fluhrer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Integer Functions in Encryption Algorithmy
Date: Fri, 02 Feb 2001 00:55:35 GMT
In article <95d06o$om3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have a free downloadable JAVA encryption/decryption application at
> the URL listed below:
>
> [EMAIL PROTECTED]/Dougpage/PageA/moddes.htm
>
> It is a modified DES algorithm and makes a fine stand alone encryption
> tool. It works best on OS/2. Windows has a Java compatability
problem.
>
> The byte parity relation was removed because it is a front-door kind
of
> logical correlation.
>
> The s-box bit replacement part of the algorithm was altered to a
simple
> bit rotation process because the original form was a back-door kind of
> functional impression apon the input bit set.
>
> Douglas Eagleson
> [EMAIL PROTECTED]
>
> Sent via Deja.com
> http://www.deja.com/
Try:
llef.tripod.com/Dougpage/PageA/moddes.htm
Doug
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Integer Functions in Encryption Algorithmy
Date: Fri, 02 Feb 2001 01:03:17 GMT
In article <95d0i4$osv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <95d06o$om3$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > I have a free downloadable JAVA encryption/decryption application at
> > the URL listed below:
> >
> > [EMAIL PROTECTED]/Dougpage/PageA/moddes.htm
> >
> > It is a modified DES algorithm and makes a fine stand alone
encryption
> > tool. It works best on OS/2. Windows has a Java compatability
> problem.
> >
> > The byte parity relation was removed because it is a front-door kind
> of
> > logical correlation.
> >
> > The s-box bit replacement part of the algorithm was altered to a
> simple
> > bit rotation process because the original form was a back-door kind
of
> > functional impression apon the input bit set.
> >
> > Douglas Eagleson
> > [EMAIL PROTECTED]
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
> Try:
>
> llef.tripod.com/Dougpage/PageA/moddes.htm
>
> Doug
> >
>
> Sent via Deja.com
> http://www.deja.com/
Try:
http://llef.tripod.com/Dougpage/PageA/moddes.htm
Doug
Sorry for the URL confusion.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Thu, 1 Feb 2001 17:09:53 -0800
Ok, I was going to reply, but a little test of mine just finished. I can now
state rather forcefully that on the system I am on right now 10K sig/s can't
be done regardless of how fast the algorithm is. I just tested the bandwidth
to disk, I can write about 12000 entries per second to the disk (without any
hashing or signing occuring). So I think I've reached a suitable remedy, we
absolutely must reduce the speed requirement. So as of right now it stands:
ECDSA
ESIGN
NSS (response recieved in private see ntru.com for details, claim of 0.5 ms
per sig)
QUARTZ
seem to be the best bets for software.
For hardware RSA seems to be everyone's (meaning the designers) favorite
Rainbow Cryptoswift seems to peek at 1000 private key ops/second
nCipher does 300, but can be combined together to get 2000/sec
Those seem to be the two fastest, am I missing anybody important?
Joe
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 01 Feb 2001 17:27:15 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> For hardware RSA seems to be everyone's (meaning the designers) favorite
> Rainbow Cryptoswift seems to peek at 1000 private key ops/second
> nCipher does 300, but can be combined together to get 2000/sec
It occurs to me, it's kind of a longshot speedwise and certainly would
involve some kludgy implementation, but you might be able to beat that
speed with Diffie-Lamport signatures. On that P4 you might be able to
run the MD5 compression function a million times a second, and you
could sign an 80-bit message digest with 247 hash steps, or about 4000
sigs/sec. Rather than Merkle hash trees you'd just generate big
blocks of D-L "coupons" (say enough for a few hundred signatures) and
publish their hashes, signed with RSA. To save space in the log you'd
just publish the hash of the DL signature, rather than the whole
signature, but you'd have a server that would give the signature on
request (it could be verified without any secret data).
Ncipher may also have some faster RSA hardware in development. Call
them if you're serious about using something like that.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 01 Feb 2001 17:36:24 -0800
Paul Rubin <[EMAIL PROTECTED]> writes:
> run the MD5 compression function a million times a second, and you
> could sign an 80-bit message digest with 247 hash steps,
Silly me. I meant 160 hash steps.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 02 Feb 2001 01:27:26 GMT
In article <94r7tp$ei7$[EMAIL PROTECTED]>,
"r.e.s." <[EMAIL PROTECTED]> wrote:
> "Terry Ritter" wrote...
>
> | >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
> |
> | The ARC4 state is awfully small for Dynamic Transposition,
> | especially
> | if we shuffle twice. We want more active state in the RNG than is
> | used in a single encryption, and probably do want at least 128 bits
> | in
> | the block. Since rejection in Shuffle (to achieve variable-range)
> | throws away values (and may throw away a lot), probably it is not
> | large enough.
>
> I wasn't proposing to use Dynamic Transposition, but what you
> say is interesting -- especially since the Ciphersaber FAQ says...
>
> "RC4 is a powerful pseudo-random number generator, with a much
> bigger internal state, then [sic] the ones that come with most
> programming systems."
>
RC4's internal state is a permutation on 256 elements, so there are 256!
possible states. That works out to about 1684 bits. How big a state do
you think you need?
Arnold Reinhold
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Liam McGann" <[EMAIL PROTECTED]>
Subject: RE: Blowfish
Date: Fri, 2 Feb 2001 02:07:46 -0000
Small query regarding the 16 round iterations of the algorithm.
I wanted to speed up Blowfish slightly, for a college project to encrypt
MP3s.
B Schneier has said that it is probably safe to reduce the number of
iterations
from 16 to 8 without compromising security. So I changed the number of
rounds
from 16 to 8. It seemed to work fine.
I don't mind if a little security is lost, but what I was wondering was;
If I alter the number of iterations, do I also need to change the rest of
the algorithm code
accordingly? As I mentioned I have only changed the number of iterations (no
other code) and it still seems to encrypt and decrypt, but perhaps in
reality it no longer performs properly?
Can anyone enlighten me as regards this.
Thanks,
Liam McGann, Dublin Institute of Technology.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Blowfish
Date: 01 Feb 2001 18:23:58 -0800
"Liam McGann" <[EMAIL PROTECTED]> writes:
> the algorithm code
> accordingly? As I mentioned I have only changed the number of iterations (no
> other code) and it still seems to encrypt and decrypt, but perhaps in
> reality it no longer performs properly?
No not really. You could reduce the size of the P table to correspond
with the lower number of rounds, and adjust the key initialization
phase accordingly, but it's not important to do so.
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Reply-To: [EMAIL PROTECTED]
Date: 1 Feb 2001 18:27:21 -0600
On Thu, 01 Feb 2001 11:54:44 -0500, Rob Yampolsky <[EMAIL PROTECTED]> wrote:
>back down would be to release a new client. And I suspect that extraction of
>the key from the binary isn't too much of an issue, so that leaves me with the
Actually, it's child's play for any decent cracker. I used to do it in my
sleep back in the early 80's, during my younger and wilder days. Hint:
Binary is just another form of assembly language, and yes, some of us
*DO* know assembly language and can actually read it as easily as we read
"C" code (well, after I wrote a disassembler that added various comments
for system calls and assigned names to stack variables and etc., probably
the first real program I wrote, WAAYYYY back).
Now I'm on the other side of the tracks, writing code to secure programs
and networks. But I'm under no delusion that attackers today are any
dumber than I was as a bright and bored youngster in the early 80's... if
it's in the object code, it can be retrieved almost at will. If it's on
a private system at your corporate headquarters, i.e., you're using
public key encryption and only the public key is embedded in the object
code while the private key is hidden at corporate headquarters, well,
this is beyond the capabilities of a bright youngster -- you're talking
about serious, well-funded, corporate espionage in this case. Which is a
totally different thing to defend against.
--
Eric Lee Green Linux Subversives
[EMAIL PROTECTED] http://www.badtux.org
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: How good is Diamond2 and Saphire ciphers?
Date: Fri, 02 Feb 2001 02:17:41 GMT
Rex Stewart wrote:
[...]
> Sapphire2 (do not confuse with the original version, which
> was shown to have a weakness) is a stream cypher which is
> designed to be both fast, and moderately strong.
I believe it was my attack on Sapphire that motivated the
change to Sapphire II. I showed how to extract some
information on the internal state using adaptive chosen
plaintext with re-origination (that is, each chosen plaintext
gets to start from the same initial state). I don't know just
how far this could have been taken. I had already spent quite
some time on it when Johnson changed the design, and then
there was no longer any interest in the original Sapphire.
The changes introduced Sapphire II defeated the specific
attack, and I determined that I'd have to start over to
attack Sapphire II. I thought, and still think, that there's
an ocean of analysis to do on adaptive re-origination against
stream ciphers with feedback of small inputs.
> I am not a professional cryptographer by any stretch of the
> imagination, but I did a pretty thourough examination of this
> cypher before I decided to use it.
Do you know if anyone else attacked Sapphire? Johnson's paper
presenting Sapphire II just says it was strengthened against
an adaptive chosen plaintext attack.
> It has some similarities to RC4 but with an extra twist that
> it feeds information from both the plaintext and the cyphertext
> streams into the system. This allows it to be used repeatedly
> with a single key, unlike standard stream cyphers.
>
> While feeding back information from either plaintext OR
> cyphertext streams is considered a dangerous practice - he
> used both, which complicates attacks somewhat, and I don't
> think anyone has come up with any useful attacks.
I don't think anyone has really gone at it. The design with
various bytes indexing others makes its workings highly
confusing, but that only implies intellectual toil in finding
attacks; it doesn't imply that those found will be
intractable. Given the amount of time it took me to get a
feel for the behavior of Sapphire, I doubt Johnson had a
deep understanding of Sapphire II when he proposed it.
I'd recommend that anyone using Sapphire II generate a unique
random (or strong pseudo-random) session key per message, just
as one would using RC4. Don't us it as a hash function. The
adaptive attack with re-origination proved more powerful than
expected against the original Sapphire, and Johnson produced
the change too quickly for comfort. There's no significant
new theory to Sapphire II that explains why it will be strong
where Sapphire was flawed.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: RE: Blowfish
Date: Fri, 02 Feb 2001 02:48:53 GMT
If your main concern is speed, a 128-bit block cipher would most likely
perform faster than a 64-bit block cipher. So you could just use
Blowfish's older brother Twofish, or another AES cipher.
- Andrew
In article <jOoe6.15004$[EMAIL PROTECTED]>,
"Liam McGann" <[EMAIL PROTECTED]> wrote:
> Small query regarding the 16 round iterations of the algorithm.
>
> I wanted to speed up Blowfish slightly, for a college project to
encrypt
> MP3s.
> B Schneier has said that it is probably safe to reduce the number of
> iterations
> from 16 to 8 without compromising security. So I changed the number of
> rounds
> from 16 to 8. It seemed to work fine.
>
> I don't mind if a little security is lost, but what I was wondering
was;
>
> If I alter the number of iterations, do I also need to change the
rest of
> the algorithm code
> accordingly? As I mentioned I have only changed the number of
iterations (no
> other code) and it still seems to encrypt and decrypt, but perhaps in
> reality it no longer performs properly?
>
> Can anyone enlighten me as regards this.
>
> Thanks,
> Liam McGann, Dublin Institute of Technology.
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: CipherText patent still pending
Date: Fri, 02 Feb 2001 04:17:47 GMT
To update this group on the progress of the CipherText algorithm; I still
have no news on the patent application except that I was granted
permission to file abroad, and recently was assigned an official
'confirmation number assignment' by USPTO. The number is simply used to
reference the application with certain accuracy.
I was quite surprised to find some of my posts to sci.crypt newsgroup
made Cryptography-Digest. As a result I have decided to do some more
'unfunded' (not unfounded) work on the demonstrations and the actual
implementations of it.
It has been implemented in Visual Basic but the implementation spawned a
slight alterration that triggers some revision in the Perl and Java
implementations as well. I am looking forward to soon making all
implementations produce identical texts after ciphers passes.
CipherText is used to demonstrate 'Page-Tag-Encryption' (PTE) and a
'Private E-mail' application on my PWS. The PWS can be accessed online at
www.greentv.crosswalkcentral.com when I am online. The PWS wrapper is
more sophisticated then the previous demonstration which suggested that
PTE may actually be practical as well as possible. It is certainly a
niche market for CipherText, but much work is needed to bring forward an
actual development product that packages the functions necessary for
seamless development.
Private E-Mail is functional but still does not use a whitener. The
Javascript implementation will be enhanced as soon as the Visual Basic
implementation is satisfactory.
CipherText is a non-blocking symmetric cipher that uses two
data-dependent key shifts. It can be made to effectively be resistent to
known plaintext attacks based on it having an expandable keystring and
whitener mask. The applied key and mask can exceed message length so that
no pattern is discernible throughout a message string. This feature has
been implemented and tested satisfactorily.
The algorithm is effective at Perl and Java implemented demonstrations
involving whitening in 7-bit encoded HTTP transmissions without a special
filter.
The algorithm is effective at recursively ciphering many short strings in
an efficient manner. (As demonstrated in the PTE implementation on my PWS
where the lookup table of thirty entry names is ciphered as each page is
returned.) Actual use may require using precomputed static lookups
created for each user if wait times accrue to an unsatisfactory length.)
To explain the algorithm briefly, it uses the checksum-like attribute of
the variable-length, 32 byte domain, root key to articulate the rotation
of a modified version of the root key. The modified key (this is one
data-dependent shift) can vary in length from the root (effectively
expanding the root) so that in double ciphering, the pattern of applied
ciphers will not repeat for a message of 100 characters when using just a
10 character key. Before the first cipher of each pass a second
data-dependent shift is applied based on the key attribute value.
A 96 byte domain whitener mask is then applied with XOR logic. The
whitener can be derived from a known whitener applying a mask key. This
is in effect a third cipher that randomizes the message dramatically.
The result can be a short, ciphered message of only a few characters with
the integrity to resist known plaintext attacks, and to find applications
in the default internet HTTP and elsewhere.
-Charles Prichard
http://greentv.crosswalkcentral.com -PWS referral
http://members.nbci.com/chuck_prichard -PWS referral
------------------------------
From: [EMAIL PROTECTED]
Subject: Where is the encryption hardware?
Reply-To: remove.nospam.in.address.to.reply
Date: Fri, 02 Feb 2001 04:22:32 GMT
With all of the obvious benefits of strong cryptography in preventing
eavesdropping/identification and providing tamper-resistant
communications, I have but one question: why are there no consumer
communications products with real encrypted transmission capabilities?
As anyone knows, any monkey with a scanner and a little patience can
intercept most un-encrypted civilian communications. Since civilians
make up the bulk of the "consumer" market, why are telecommunications
devices such as network interface cards, faxes and cellular phones not
equipped with encryption hardware? Ed
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Thu, 1 Feb 2001 20:49:49 -0800
<[EMAIL PROTECTED]> wrote ...
| "r.e.s." <[EMAIL PROTECTED]> wrote:
| > "Terry Ritter" wrote...
| > [r.e.s. wrote:]
| > | >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
| > |
| > | The ARC4 state is awfully small for Dynamic Transposition,
| > | especially
| > | if we shuffle twice. We want more active state in the RNG than
is
| > | used in a single encryption, and probably do want at least 128
bits
| > | in
| > | the block. Since rejection in Shuffle (to achieve
variable-range)
| > | throws away values (and may throw away a lot), probably it is
not
| > | large enough.
| >
| > I wasn't proposing to use Dynamic Transposition, but what you
| > say is interesting -- especially since the Ciphersaber FAQ says...
| >
| > "RC4 is a powerful pseudo-random number generator, with a much
| > bigger internal state, then [sic] the ones that come with most
| > programming systems."
| >
|
| RC4's internal state is a permutation on 256 elements, so there are
256!
| possible states. That works out to about 1684 bits. How big a state
do
| you think you need?
Suppose we use ARC4 to encipher successive N-byte blocks,
and perform a Durstenfeld Transposition ("Shuffle") on
the N bytes of each block -- using the ARC4 byte-stream
to generate the PRNs called by the Shuffle algorithm.
Considering Terry Ritter's negative conclusion above, in
spite of the 1684-bit state, for what values of N *would*
ARC4's state be sufficient?
--r.e.s.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Thu, 1 Feb 2001 20:42:32 -0800
<[EMAIL PROTECTED]> wrote in message
news:95d2dm$qk7$[EMAIL PROTECTED]...
> In article <94r7tp$ei7$[EMAIL PROTECTED]>,
> "r.e.s." <[EMAIL PROTECTED]> wrote:
> > "Terry Ritter" wrote...
> >
> > | >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
> > |
> > | The ARC4 state is awfully small for Dynamic Transposition,
> > | especially
> > | if we shuffle twice. We want more active state in the RNG than is
> > | used in a single encryption, and probably do want at least 128 bits
> > | in
> > | the block. Since rejection in Shuffle (to achieve variable-range)
> > | throws away values (and may throw away a lot), probably it is not
> > | large enough.
> >
> > I wasn't proposing to use Dynamic Transposition, but what you
> > say is interesting -- especially since the Ciphersaber FAQ says...
> >
> > "RC4 is a powerful pseudo-random number generator, with a much
> > bigger internal state, then [sic] the ones that come with most
> > programming systems."
> >
>
> RC4's internal state is a permutation on 256 elements, so there are 256!
> possible states. That works out to about 1684 bits. How big a state do
> you think you need?
Obnit: RC4's internal state is a permutation of 256 elements, and two 8 bit
variables, giving a total of 256! * 256^2 possible states. You have
shamefully understated it... (:-)
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Thu, 1 Feb 2001 21:00:27 -0800
Prichard, Chuck <[EMAIL PROTECTED]> wrote in message
news:Lxqe6.1473$[EMAIL PROTECTED]...
> To update this group on the progress of the CipherText algorithm; I still
> have no news on the patent application except that I was granted
> permission to file abroad, and recently was assigned an official
> 'confirmation number assignment' by USPTO. The number is simply used to
> reference the application with certain accuracy.
Glad to hear it. However, to save you the trouble of constantly keeping us
up to date, the next time we want to know, we'll ask.
> CipherText is a non-blocking symmetric cipher that uses two
> data-dependent key shifts.
[Rest of hand waving snipped]
Obvious questions:
- Have a credible cryptanalyist studied this algorithm? If not, why do you
claim it to be secure?
- For that matter, what security claims do you make?
- Where can someone find a non-handwaving algorithm description, preferably
in mathematical notation? I couldn't find any sort of description on your
web site.
--
poncho
------------------------------
** 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
******************************
