Cryptography-Digest Digest #290, Volume #12 Wed, 26 Jul 00 12:13:01 EDT
Contents:
Re: Playing with an 8 bit cipher. (Runu Knips)
Re: Proving continued possession of a file ("Rick Heylen")
Re: Rabin's information dispersal algorithm (Wei Dai)
Re: TheArgon Site (John Savard)
Re: Small hash checksum (Anders Thulin)
HTTPS & SSL ([EMAIL PROTECTED])
Re: Playing with an 8 bit cipher. ("Trevor L. Jackson, III")
Get Free Software (George Peters)
Re: Steganographic encryption system (Mark Evans)
Re: Steganographic encryption system (Mark Evans)
Re: 8 bit block ciphers ("Scott Fluhrer")
Re: Debating Behaviors in sci.crypt (Adam Durana)
Re: Small hash checksum (Paul Koning)
Re: RC4-- repetition length? (Mark Wooding)
Re: How is the security of Outlook Express encryption ? (Guy Macon)
Re: Question.How to avoid weak curves? (Robert Harley)
Jackboots straw isn't above the law: ("Sam Simpson")
Re: Proving continued possession of a file (Andru Luvisi)
Re: AESC-stream cipher (Jerry Coffin)
----------------------------------------------------------------------------
Date: Wed, 26 Jul 2000 12:06:13 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Playing with an 8 bit cipher.
Mack wrote:
> This is to be part of a larger function. Its use is an s-box.
Ah ! Okay.
> When using embeded applications with only 64 bytes of
> memory it really isn't practical to use all of it for the
> encryption.
Yep.
------------------------------
From: "Rick Heylen" <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 26 Jul 2000 11:10:46 GMT
There's a mild theoretical problem with this if the file contains repeating
data and the important informational content of the file is the order in
which the repeating pattern occurs. For instance if the file's data is
structured such that the numbers x_1 through x_m only take two values x_one
and x_two then Bob can just store x_one, x_two, the number (t) of x_one
blocks and the sum (u) of all the y values such that x_y == x_one. When
challenged by Alice, Bob's response is
response=x_one^(t*b*r+u*i*r)*x_two^( (m-t)*b*r + (m*(m+1)/2-u)*i*r)
Storing x_one, x_two, t and u requires much less storage for Bob and the
computing time for the response is much shorter.
The reason why we can store it in less space is that most of the
information about the order in which the x_one blocks and x_two blocks
occur in the file has been thrown away. The reason why we can throw it away
but still relply to the challenge correctly is that we can store the sum of
the exponents for all the bases which are the same. The method generalises
to the cases where x_1 through x_m take a number (less than m) of distinct
values.
Rick
--
I've got an allergy to Perrier, daylight and responsibility.
PGP key 512/CA5CADED C/C++, Java and Optical Media Expert
Key fingerprint = 00 00 00 00 00 65 AB 2F 76 EB EF F7 9C 10 FA 88
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: Rabin's information dispersal algorithm
Date: Wed, 26 Jul 2000 04:38:10 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Generally it's desirable for no information about the message to be
> leaked if the attacker has less than n pieces, which is obviously not
> the case for this method. However, that could still be achieved with the
> same efficiency by applying an AONT to the message before splitting it.
>
> Alternatively, create a temporary random "message" R of size 128*n bits,
> split R as described above, and make public the real message encrypted
> under hash(R). (This is not quite the same as an information dispersal
> algorithm because of the extra public data, but it can be used for some
> of the same applications.)
IDA is mostly used for reliability rather than secrecy. In some
applications being able to recover useful partial information with less
than n pieces may actually be a desirable feature.
Besides AONT, there is also an older idea for using IDA as a secret
sharing algorithm, described in the paper "Secret Sharing Made Short"
by Hugo Krawczyk. The idea is to encrypt the message with a random
symmetric key, secret-share the key, and information-disperse the
encrypted message. Append each piece of the encrypted message with a
share of the key to obtain a share of the message.
--
cryptopp.com - a free C++ class library of cryptographic schemes
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: TheArgon Site
Date: Wed, 26 Jul 2000 12:35:33 GMT
On Wed, 26 Jul 2000 05:15:28 GMT, [EMAIL PROTECTED] (James Pate
Williams, Jr.) wrote, in part:
>From elementary chemistry we know
And I recall seeing on the web something called "The Eye of Argon",
which was a silly burlesque of stories in the Conan genre.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Small hash checksum
Date: Wed, 26 Jul 2000 12:30:41 GMT
[EMAIL PROTECTED] wrote:
>
> Hello,
>
> I am looking for a way to represent a larger checksum like this:
>
> A0D20D19181D1DCF9A0BAADAE496CEB5
>
> with a smaller signature using 4 or 6 characters (e.g. A62D9K or just
> A62T). It doesn't have to secure at all since the two will be placed
> besides each other. It just has to be fairly unique.
Assuming that the original checksum is 'good', just pick any 4 or 6
letters/nibbles from it. Try it: create one thousand test document
that you're going to checksum, and then check the number of
collisions you get.
> I will use it for a fast check, and the larger checksum I will use in
> cases of doubt.
If you choose a good checksum algorithm, and do a byte-by-byte or
word-by-word comparison that terminates as soon as you have found a
difference, I don't think you will see much speed difference.
You have an unusual application if comparing hash codes is a bottleneck
that needs this kind of speed-up.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Hj�lmaregatan 3B, 212 19 Malm�, Sweden
------------------------------
From: [EMAIL PROTECTED]
Subject: HTTPS & SSL
Date: Wed, 26 Jul 2000 13:58:29 GMT
Dear friend:
We have puzzled by some emergent questiones of https.
Our question is:
1) If we visit one homepage[for example: index.html] which include
some pictures. Do the browser will retrieve index.html througth one
socket and retrieve pictures throught other sockets? If it does, how
to retrieve pictures throught SSL?
2) If the connection from browser to server will be breaken after
we retrieve one page [for example:index.html] from web site? If it
does, Do the SSL connect will need rebuild?
3) How long the SSL connection will be timeout after connected ?
Any advise is welcome!
Best regard!
Techinfo group
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 26 Jul 2000 10:19:38 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Playing with an 8 bit cipher.
Mack wrote:
> "Trevor L. Jackson, III" [EMAIL PROTECTED] wrote:
> >
> >If you have MIPS to use instead of memory you could emulate the permutation
> >table with a smaller working set. You'd need a lookup function that, given a
> >single byte of input (virtual array index), would return the contents of the
> >shuffled table that you don't have room to store. The lookup function would
> >have to (laboriously) backtrack the shuffle process until it could determine
> >the contents of the desired slot in the table.
> >
> >This can probably be implemented in only a few bytes, but would take O(N^2/2)
> >operations on average where each operation is a virtual byte swap driven by
> >the RNG controlling the shuffle. Since N is 256, this is not going to be
> >fast.
> >
> >
> That is why I was looking for 8 bit block ciphers
> that were reasonbly fast. On the fly calculation
> with minimal memory.
Do you have a definition of "reasonably fast"? What is your desired data rate?
Can you tolerate variations in the data rate?
The backtracking mechanism mentioned above would require on average 512 operations
(the original description is wrong), but has a worst case performance of 32K
operations (the frequency of this condition is 1:256!). If you have a low power
machine at 10 MHz your average throughput would be about 2 Kb/sec.
------------------------------
From: George Peters <[EMAIL PROTECTED]>
Subject: Get Free Software
Date: Wed, 26 Jul 2000 14:30:41 GMT
At www.endecs.com/uenigma.exe an entire suite of encryption products is
available.
Because of specilized setup, it is a self-extracting .exe which you will
need to run the setup.exe after extraction.
It contains a file system, email & ftp clients and messaging
applications.
Well worth the download.
------------------------------
From: Mark Evans <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 26 Jul 2000 15:35:42 +0100
phil hunt <[EMAIL PROTECTED]> wrote:
> Jackboot's RIP bill and his other measures to stamp out our liberties are one
At the same time making sure he protects his own liberties to speed on
public roads...
> of main tihngs motivating me to develop stes. (Another motivation was to
> find out if it was possible).
--
Mark Evans
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
------------------------------
From: Mark Evans <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Wed, 26 Jul 2000 15:36:36 +0100
phil hunt <[EMAIL PROTECTED]> wrote:
> On Wed, 12 Jul 2000 00:40:39 -0400, jungle <[EMAIL PROTECTED]> wrote:
>>current, well working stego have ration of 1 to 2 ...
>>and all are super safe / super stego ...
>>you are creating stego that will have ratio of 1 to 30 ...
>>
>>what a waste of resources ...
> I'm not forcing you to use it, you know.
> BTW, have you ever heard of "traffic analysis"?
Surely the question should be "has Jack Straw?"
--
Mark Evans
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: 8 bit block ciphers
Date: Wed, 26 Jul 2000 07:41:10 -0700
Runu Knips <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mack wrote:
> > I do have 64 bytes total. But all of it can't be used for
> > the encryption. 8 of it has another use.
>
> I don't believe you have 64 bytes total. How many stack
> space do you have, and how many registers (of which
> size) ? 64 bytes total is pretty small to do anything
> useful.
Obviously, you've never worked in an embedded environment. We're talking
about a CPU on a chip that might be used to control a toaster. Yes, it can
get that constrained.
One thought is looking at a design like NewDES (by Robert Scott, it's in
Schneier). As designed, it could be done with no additional RAM space other
than the key and the data block (and the chaining block if you are using it
in CBC). It does have a fixed 256 byte sbox, but that's ROM, and on the
embedded controllers I worked with (long, long ago), that wouldn't be too
much of a problem.
I have heard that the initial sbox proposed was weak, and that an
alternative was much better against differential attacks. However, I do not
have a reference to that. There is a Robert Scott that posts here on
occasion, maybe you can ask him.
--
poncho
------------------------------
From: Adam Durana <[EMAIL PROTECTED]>
Subject: Re: Debating Behaviors in sci.crypt
Date: Wed, 26 Jul 2000 14:47:33 GMT
Actually you are the one causing problems not other people. You time
and time again make posts about "base encryption". Each post is the
last post reformated, you never provide any meaningful proof to back up
your claims. You simply make claims, and outrageous claims at that.
When you make such claims with no proof at all you tend to get a
negative response. And each time you repost your claims the responses
get more and more negative. I would take this as a clue to not make
such posts any more. And as for the part of your post saying the
people who reply negatively to you are actually trying to get
attention, it seems to me you are the one trying to get attention. I
suggest you rethink what you post and why you post it.
- Adam
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Small hash checksum
Date: Wed, 26 Jul 2000 10:25:26 -0400
[EMAIL PROTECTED] wrote:
>
> Hello,
>
> I am looking for a way to represent a larger checksum like this:
>
> A0D20D19181D1DCF9A0BAADAE496CEB5
>
> with a smaller signature using 4 or 6 characters (e.g. A62D9K or just
> A62T). It doesn't have to secure at all since the two will be placed
> besides each other. It just has to be fairly unique.
>
> I will use it for a fast check, and the larger checksum I will use in
> cases of doubt.
Just take a portion of the original checksum. If the original
is any good, pieces of it will be uniformly distributed as well.
paul
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: RC4-- repetition length?
Date: 26 Jul 2000 15:18:50 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
> Quadruple Serpent (that is, the block cipher defined by iterating 4
> copies of the Serpent block cipher, each with an independant 256 bit
> key) run in counter mode is a stream cipher that has no more than
> 1024+128 bits of total entropy, and so by the above analysis should be
> far easier to break. But, if you have the foggiest clue that it is
> even slightly breakable, even with 2 gigabytes of keystream, I suggest
> you let NIST know right away...
Well, I can distinguish it from random after 2^{64} blocks (no
collisions in counter mode!). However, this doesn't lead any sort of
key recovery attack at all. I think that this just adds more weight to
your point.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: How is the security of Outlook Express encryption ?
Date: 26 Jul 2000 11:24:57 EDT
jungle wrote:
>
>
>Greg wrote:
>>
>> > Does anyone know what is the key lenght of Outlook Express's
>> > singing/encryption ?
>
>===============
>
>> I developed a piece of software that placed itself between
>> OE and the crypto layer and intercepted the plain text.
>
>this has nothing to do with the ORIGINAL question ...
Does anyone know how good the case hardening on this lock is?
I am using it to lock my cardboard shoebox shut and I am worried
about someone with a diamond blade hacksaw cutting the lock off.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Question.How to avoid weak curves?
Date: 26 Jul 2000 17:27:16 +0200
Sergio Arrojo writes:
> [...MOV and Anomalous conditions...]
> Are there any further attack I should know about in order to prevent
> weaknesses in the chosen elliptic curve?
Don Johnson wrote:
>See IEEE P1363 and P1363a. The other thing you MIGHT consider is
>using a random curve, that is, one generated in a canonical fashion
>from a seed. This is for the HYPER-PARANOID.
In cryptography shouldn't one always be hyper-paranoid? =:-)
With that in mind, I would recommend picking random curves and
switching curves often.
One thing that needs to be done is counting points on the curves.
Since very recently, that has become MUCH easier to do so at least in
characteristic two. Using the methods described in the paper FGH.ps
linked from:
http://www.lix.polytechnique.fr/Labo/Mireille.Fouquet/elliptic.html
it is now possible to count points for cryptographic key sizes in
seconds or minutes with a small standalone program on an ordinary PC.
We have also gone up as far as 4001 bits using a few days on a fast Alpha.
Bye,
Rob.
.-. .-.
/ \ .-. .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' [EMAIL PROTECTED] `-'
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Jackboots straw isn't above the law:
Date: Wed, 26 Jul 2000 16:46:54 +0100
He's quick enough to remove our liberties (see for example the RIP
Bill etc), but his family & associates haven't avoided the law
totally:
J.Straws brother charged with assault on a 16yr old girl:
http://news6.thdo.bbc.co.uk/hi/english/uk/newsid%5F745000/745168.stm
J.Straws brother charged with 2nd assault on a 16yr old girl:
http://news6.thdo.bbc.co.uk/hi/english/uk/newsid%5F756000/756584.stm
J.Straws son caught selling Cannabis:
http://news6.thdo.bbc.co.uk/hi/english/world/europe/newsid%5F44000/44
289.stm
J.Straws car caught speeding (100+ on a motorway ):
http://news6.thdo.bbc.co.uk/hi/english/uk%5Fpolitics/newsid%5F844000/
844033.stm
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Mark Evans <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> phil hunt <[EMAIL PROTECTED]> wrote:
>
> > Jackboot's RIP bill and his other measures to stamp out our
liberties are one
>
> At the same time making sure he protects his own liberties to speed
on
> public roads...
>
> > of main tihngs motivating me to develop stes. (Another motivation
was to
> > find out if it was possible).
>
> --
> Mark Evans
> St. Peter's CofE High School
> Phone: +44 1392 204764 X109
> Fax: +44 1392 204763
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 26 Jul 2000 08:34:20 -0700
"Rick Heylen" <[EMAIL PROTECTED]> writes:
>
> There's a mild theoretical problem with this if the file contains repeating
> data and the important informational content of the file is the order in
> which the repeating pattern occurs. For instance if the file's data is
> structured such that the numbers x_1 through x_m only take two values x_one
> and x_two then Bob can just store x_one, x_two, the number (t) of x_one
> blocks and the sum (u) of all the y values such that x_y == x_one. When
> challenged by Alice, Bob's response is
>
> response=x_one^(t*b*r+u*i*r)*x_two^( (m-t)*b*r + (m*(m+1)/2-u)*i*r)
Could this be fixed by encrypting the file first and computing the
summary information using the encrypted file? Alice stores the key
she used, and sends Bob the key along with the other information in
the challenge, although it never changes.
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Wed, 26 Jul 2000 09:56:36 -0600
In article <8ljim1$64r$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> Dear Jerry,
>
> Thank you very much for your investigation.
>
> I suppose that your approach measures performance of
> Input/output file system mostly and not of the
> Algorithm.
You suppose incorrectly -- if you read what I did, you'll quickly
realize that part of the way I tested was designed _specifically_ to
remove this from the equation. It may be that it's somewhat
incomplete, as Delphi may do I/O a bit less efficiently than the
"null-encryption" (i.e. copy) program I used to isolate the
encryption from the I/O. If so, we might see (for example) a
difference of 10% between my estimate and the real number. I'm
_quite_ certain that Delphi hasn't messed up the I/O so badly that
it's off by a factor of 180:1 though.
> I would like suggesting following steps.
>
> 1. Take any file for encryption with the length of 256 byte.
> 2. Modify first call to encryption in AlexMainDlg.pas as follows:
> For I:=0 to NNNN do <call to encryption>
> 3. Then use stop watch to measure this loop call.
IMO, your suggestions are _quite_ poor. They measure something
completely UNrelated to the program in real use, leading to a result
that simply doesn't mean anything, even at best. Of course, using a
stop-watch instead of a timer built into the machine is _nowhere_
close to "at best", but that's a more or less separate question.
> I think that 99% of performance takes key schedule.
> This is why it is not reasonable to use a script for
> Multiple starting of the program. The approach above helps
> to separate performance of encryption algorithm from I/O
> system and key schedule.
Your approach will produce results that don't give anybody an
indication of anything useful. I took the results of encrypting a
single file of approximatly 180 Megabytes. That should involve ONE
key setup, followed by 180 Megabytes of encryption. I subtracted off
what it took to simply copy the file, thus eliminating (most of) the
effects of the I/O speed.
If there's any major problem with the approach I took, it's that it
encrypted a file MUCH larger than most people are likely to encrypt
on a regular basis. This amortizes the key setup over a larger
amount of encryption time, which will make your encryption look
FASTER than anybody can expect to see in most normal uses.
The simple reality is this: there's simply no way to put your
algorithm to use in such a way that your performance claims have any
chance of being anywhere close to accurate.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
** 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
******************************
