Cryptography-Digest Digest #874, Volume #9 Tue, 13 Jul 99 10:13:07 EDT
Contents:
Re: Fractal encryption ("Douglas A. Gwyn")
Re: Fractal encryption (Glenn Davis)
Re: Benfords law for factoring primes? ("Douglas A. Gwyn")
I wonder why he wrote it that way. (wtshaw)
Re: Base encryption (wtshaw)
Re: Benfords law for factoring primes? (David A Molnar)
Re: Is it possible to combine brute-force and ciphertext-only in an ("Douglas A.
Gwyn")
Re: How Big is a Byte? (was: New Encryption Product!) (Paul Schlyter)
Re: Analysis of ICE? (Vincent Rijmen)
Re: Fractal encryption (Mok-Kong Shen)
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: Base encryption (Mok-Kong Shen)
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
I want some encryption algorithms (Sankar Subburathinam)
Re: Fractal encryption (Jim Gillogly)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Tue, 13 Jul 1999 03:26:56 GMT
Krishna Sawh wrote:
> Where can I find more infomation on fractal encryption, dose any body
> here know anythink ???
That's two different questions. :-)
------------------------------
From: Glenn Davis <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Mon, 12 Jul 1999 20:28:27 -1000
Krishna Sawh wrote:
>
> Where can I find more infomation on fractal encryption, dose any body
> here know anythink ???
>
> Krishna Sawh
> [EMAIL PROTECTED]
I propose using the Mandelbrot Set to carry a secret message.
The color in the image is the number of iterations, but a limit is
set to that number, like 1024 iterations. Beyond that count,
the program puts a black pixel. The message is encoded at the edge of
the black by adding extra black pixels.
Send that image of the Mandelbrot Set.
The recipient has a secret key (coordinates, maximum # of
iterations) to producean image without the message. XOR two images.
To be continued...
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: Tue, 13 Jul 1999 03:46:02 GMT
[EMAIL PROTECTED] wrote:
> Clearly he meant most signifigant _bit_ rather than most signifigant
> _digit_!
Gwyn's law: The most significant digit of a positive integer,
using base-two representation, is 1 with probability 1.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: I wonder why he wrote it that way.
Date: Tue, 13 Jul 1999 01:26:04 -0600
When I picked up THE 900+ page crypto novel several weeks ago, I saw on
the bargin table at B&N a book named, Codes, Ciphers, and Other Cryptic
and Clandestine Communications, Making and Breaking Secret Messages from
Hieroglyphs to the Internet, by Fred B. Wrixon, copyright 1998.
This is actually a fairly good introduction to cryptography for the
general public. It's loaded with history (perhaps sometimes too
detailed), and gives a once over of a wide range of topics, with some
rather detailed algorithm descriptions, with analytic instructions for
certain ciphers.
No, it does not have any programming code, and some will find it
undertechnical for their needs, yet, it contains snippets of information
that are nifty to know if you have missed them.
The one thing I most dislike about the book, despite of its wonderful
specturm treatment of the subject, with few exceptions more than a third
of each page is blank, making the book 50% heavier than it should be. The
type is generous, making reading easy, but without my book platform to
support the thing, it would something I would quickly grow tired of
holding.
The strangest statement in the book, which really leaves me grinning and
crying with laughter occurs on page 553, "Rongorongo consists of tiny,
amazingly regularly formed glyphs about 1 centimeter high and 10
millimeters wide."
The book is surely worth the sale price, and you have plenty of room in
the margins to write those crypto budding ideas you might come up with.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Base encryption
Date: Tue, 13 Jul 1999 01:25:48 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>
> Start with using Huffman codes to compress a text message into binary
> for encryption. Then, convert to the base-26 alphabet for some more
> encipherment by classical methods.
One of my points is that while historically base-26 has been popular, you
can apply the same techniques to any base, even in the conversion between
bases.
The possibilities are almost endless, but you must consider where you
start and what you want to produce, are you starting with plaintext, or
just want ciphertext to look like something else.
>
> As it happens, 2^47 is *very* slightly smaller than 26^10, so
> conversion is extremely efficient. (I note as a warning that since
> *some* reduncancy _is_ introduced, two separate keys should be used
> for encryption before and after the conversion.)
Personally, I try to stay at or under 10^10 with 10% agreement of powers,
but if you go higher, you can get almost any conversion you want, with
long block lengths.
>
> Finally, four characters from the 26-letter alphabet can be quickly
> converted to three characters from a set of 78, which is more
> efficient than using 64 characters but should still be Internet-safe.
> (78 is 3 times 26, so just break up one letter into three symbols from
> 1 to 3 and combine with the three others.)
>
Concerning base 26, here are some interesting relationships. I'll leave
it to the reader to find the right powers involved:
105 to 26; 95 to 26; 26 to 96; 77 to 26; 26 to 78; 58 to 26; 26 to 59; 41 to 26.
--
Rest sometimes allows you to find new things to worry about but should give you the
patience to do something about them.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: 13 Jul 1999 06:59:16 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> Clearly he meant most signifigant _bit_ rather than most signifigant
>> _digit_!
> Gwyn's law: The most significant digit of a positive integer,
> using base-two representation, is 1 with probability 1.
At this point it may be worth noting that the lattice factoring
algorithm for numbers of the form p^k q (p, q prime) requires
a "hint" about the most significant bits of p. The more bits known,
the more efficient the algorithm is. The authors reference some
other work on "factoring with a hint" which shows that half the
most significant bits are generally enough to factor in poly time.
Now I know one bit!
Only (ln p / 2) - 1 to go!
-David Molnar
paper referenced is "Factoring N=p^r q for large r" at
http://theory.stanford.edu/~dabo/abstracts/prq.html
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: Tue, 13 Jul 1999 07:09:24 GMT
Nicol So wrote:
> If you don't mind, could you explain in simple terms what is the
> current thinking on the subject among physicists?
Basically, the problem with the Copenhagen Interpretation was that
the interaction between the observed quantum system and the observer
was not subject to the same laws as an unobserved quantum supersystem
(= observed system + observer) should have had according to the rest
of the quantum theory. This is most easily seen in the notion that
the observed system's state (wavefunction) "collapses" from a mixed
state to a pure state upon making an observation. I think von
Neumann was among the first to note that this was inconsistent.
The best current approaches to the measurement issue all revolve
around the consistent notion that the states of observer and observed
become "entangled" with each other according to normal quantum laws.
I think papers on this can be found on the net, probably by searching
for "quantum theory of measurement", "quantum entanglement", or
"quantum computing" (a topic that has come up here before). Happy
hunting!
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 13 Jul 1999 10:58:27 +0200
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>
>>Here's my PDP-10 Reference Manual (this one's dated 1971; previous
>>copyright dates on the IP page go back to 1967). In the glossary
>>it says "Byte: Any contiguous set of bits within a word." In the
>>intro it says "The hardware permits automatic packing, unpacking, and
>>sequential access of any size bytes. Since characters are frequently
>>represented as 7-bit ASCII code, the 36-bit word contains 5 characters.
>>When a 6-bit subset of ASCII is employed, six characters are stored
>>per 36-bit word."
>
> And here's another silly question from me: how do we know that the
> people at DEC weren't using the term byte _incorrectly_, in a sense
> other than that intended by the people at IBM who coined the term?
How do you even know what "correct" use is? Note that I'm talking
about knowledge here, not opinions. Is there some ANSI standard
where one could look this up? Without that, one can easily get
involved in circular arguments like:
- The word "byte" is only used to mean 8 bits, like they do on IBM
- Well, at DEC, "byte" can mean any number of bits
- But at DEC they use "byte" incorrectly ....
In the absence of an official standard, one will have to consider
actual usage of the word. The the usage at DEC will then count as
much as the usage at IBM
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Vincent Rijmen <[EMAIL PROTECTED]>
Subject: Re: Analysis of ICE?
Date: Tue, 13 Jul 1999 11:03:35 +0200
[EMAIL PROTECTED] wrote:
> BTW does -58 for 16 rounds means 2^58 pairs required? If so then it is
> better then DES for 16 full rounds... Can some clear up 'Table 3.
> Differential Analysis for an arbitrary number of rounds.' please?
>
Well, the table considers variants of ICE, with a reduced number of
rounds.
The first column states the number of rounds, the second column gives the
logarithm of the probability of the characteristic used:
-58 means a probability of 2^{-58}.
The third column gives the logarithm of the number of pairs required.
This number is lower bounded by 1/probability. If the S/N ratio
is low, many good pairs arerequired for a successful key recovery.
(Column 5 gives the logarithm of the S/N ratio.)
The fourth column tellls you something about the memory that an attack
would need, and the last column gives the (logarithm of) the fraction of
keys for which tha attack works.
Vincent
--
# Vincent Rijmen |
# | Any philosophy that can be put "in a nutshell"
# | belongs there. -- Sydney J. Harris
# [EMAIL PROTECTED] |
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Tue, 13 Jul 1999 11:58:49 +0200
Krishna Sawh wrote:
>
> Where can I find more infomation on fractal encryption, dose any body
> here know anythink ???
Look into the journals for chaos. In this group I recently called
attention to two articles dealing with application of chaos theory
to cryptology.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 13 Jul 99 08:44:35 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Alan J Rosenthal) wrote:
>Jim Gillogly <[EMAIL PROTECTED]> writes:
>>Of course, nobody disagrees that bytes are usually 8 bits on modern
>>machines, most of which (for our sins) are Intel boxes running a
>>Microsoft OS.
>
>If I recall correctly, in the mid and/or late 1970s (and possibly through
>early 1980s), when there were IBM fans and DEC fans, the IBM types used
>the word "byte" to mean "8 bits" and us DEC-oriented folks found this as
>annoying as many of you find, for example, spelling "lose" as "loose" in
>usenet messages. Of course, we had a three-bit bias due to octal numbers,
>whereas THOSE people used hexadecimal and had a four-bit bias.
Yup. They couldn't count on two hands.
/BAH
Subtract a hundred and four for e-mail.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Base encryption
Date: Tue, 13 Jul 1999 12:25:28 +0200
wtshaw wrote:
>
> > Each ideograph is in turn built of a small set of building blocks,
> > the so-called strokes, e.g. a vertical line, a point, etc.
> > In the European languages the building blocks of words are the
> > alphabetical characters. Thus I am not sure that your comparison
> > of 60000 to 64 is very appropriate.
>
> How many different strokes are there? Is there anything equivalent to a
> coordinate system for placement? The big question here is whether a
> formula for each ideograph is reasonable, such that from it a clear
> picture for that word could be drawn? If not, why not? Would not such a
> formula be sufficient to replace the word?
There are basically 8 different types of strokes (units). But these
are put in different loactions of an ideograph and can be of
different size (e.g. a horizontal line may be short or long). It
could theoretically be possible to describe an ideograph with
sophisticated techniques of computer science, I believe, for instance
graph grammars. But practically it seems to be not 'possible' (or
to put it otherwise, a formal description would need many more
bits than the Unicode). There is one dictionary system that looks
up the words based on the characteristics at the four corners of
an ideograph and could be employed as a basis for coding but that
system is not always unambiguous since what is inside of the corners
could vary from case to case.
> > On the other hand, the Chinese telegraphic code maps a subset of
> > the words to 4 decimal digits. Via Unicode every Chinese ideograph
> > has a 2 byte binary value.
>
> Could this be the answer for the above.
>
> > This has no correspondce for the words
> > in the European languages. I said a couple of times previously that
> > if there were a commonly accepted (quasi-standard) numerical encoding
> > of English words, e.g. if a publisher of a big dictionary would
> > associate a number to each word, then in the thus numerically
> > encoded plaintext frequency analysis would be comparatively much
> > more difficult to perform than in the case with the alphabets.
>
> Letters and numbers are simply to different bases, which are easily
> converted to each other.
But the character frequencies, become lost when numerically encoded
(e.g. 'e' would not always, in fact rarely, be mapped to, say, '9').
The same applies to digrams, trigrams etc. If one now scrambles the
digits obtained, it is clear that one can do much less with the
techniques of frequency analysis compared to the case where one
scrambles the characters.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 13 Jul 99 08:41:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
>Jim Gillogly <[EMAIL PROTECTED]> wrote, in part:
>>John Savard wrote:
>
>>> Although I'm well aware that many old mainframe computers had 6 bit
>>> _characters_, I didn't realize that the PDP-10 did use the term "byte"
>>> in referring to its variable-length character feature in its
>>> documentation.
>
>>Here's my PDP-10 Reference Manual (this one's dated 1971; previous
>>copyright dates on the IP page go back to 1967). In the glossary
>>it says "Byte: Any contiguous set of bits within a word." In the
>>intro it says "The hardware permits automatic packing, unpacking, and
>>sequential access of any size bytes. Since characters are frequently
>>represented as 7-bit ASCII code, the 36-bit word contains 5 characters.
>>When a 6-bit subset of ASCII is employed, six characters are stored
>>per 36-bit word."
>
>And here's another silly question from me: how do we know that the
>people at DEC weren't using the term byte _incorrectly_, in a sense
>other than that intended by the people at IBM who coined the term?
I'll guarantee you that, if it was IBM cybercrud, we changed it
to a better term.
/BAH
Subtract a hundred and four for e-mail.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Tue, 13 Jul 1999 13:17:52 +0200
The present thread having apparently come to an end, I venture to
summarize the results of the discussions:
The second scheme in my post, i.e. Boris Kazak's method of using
lower/upper case for denoting 0/1, seems unlikely to be a practical
(successful) means for getting around the export regulations.
The same applies to my original suggestion of employing sentences of
a book to denote byte values.
On the other hand, the first scheme is o.k., at least from the
opinions gathered todate. To repeat, it is as follows: The author
claims copyright of his code, permits free copying and sends that
in printed form (analogous to PGP) to a country without crypto laws
for placing (by a foreign subject) on a server there. In his paper
published on the domestic server, a reference to the code, i.e.
URL without 'http://', is given at the place where the code would
have been if crypto publications were free. Subject to ultimate
clarification with the authorities, giving a link, i.e. using the
full URL for mouse click, is considered to be o.k., since NIST does
just that in the case of AES.
While eventual further contributions to this thread are certainly
sincerely wellcome, I like to thank at this place everyone who
has given their valuable viewpoints to enable the above resume
of an in my view (especially for code writers) essential issue to
be written.
M. K. Shen
------------------------------
From: Sankar Subburathinam <[EMAIL PROTECTED]>
Subject: I want some encryption algorithms
Date: Tue, 13 Jul 1999 16:44:41 +0530
This is a multi-part message in MIME format.
==============55B261E85B73A42AC36EE4DD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello Friends,
I am looking for some algorithms that can be used for
encryption and at the same time for sompression.
Any helping pointers will be highly appreciated.
warmest regards,
sankar
==============55B261E85B73A42AC36EE4DD
Content-Type: text/x-vcard; charset=us-ascii;
name="sankar.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Sankar Subburathinam
Content-Disposition: attachment;
filename="sankar.vcf"
begin:vcard
n:Subburathinam;Sankar
tel;home:80-3440047
tel;work:80-3370445 Extn: 3515
x-mozilla-html:TRUE
org:Compaq India;Telecom Development Centre
adr:;;;Bangalore;Karnataka; ;India
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Engineer
x-mozilla-cpt:;2880
fn:Sankar Subburathinam
end:vcard
==============55B261E85B73A42AC36EE4DD==
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Tue, 13 Jul 1999 06:51:54 -0700
Glenn Davis wrote:
> > Since the edge of the Mandelbrot set is self-similar at any scale,
> > it seems possible for the cryptanalyst to pick any other spot on
> > the boundary and run some trials...
> > I suspect the analyst would be able to get close to the right result
> > even if she were in the wrong area of the map.
> The black "circles" of the Mandelbrot set appear at many scales
> and coordinates. The image may be 10^-30 of the whole area, so
> searching for it will be hard work without the key. There is an
> infinitude of places available to focus on for the carrier image.
I agree that finding <the> right place would be difficult or impossible,
but my suggestion was that because of the similarity of structures
across the entire set, "decrypting" in a wrong but plausible location
might result in finding a structure that's close enough to recover
many or most of the bits. Repeating it in several wrong places
might help narrow down which differences are due to location and
which are due to enemy action.
As with many encryption systems, whether it works or not would
probably depend on the details of the implementation. Glenn went
on in a subsequent message to say:
> The placement of the message pixels needs to be done carefully
> so that your attack would fail. You make a good point about that
> attack. To place the pixels in appropriate cusp locations in the
> Mandelbrot's black circles would be the answer. Self-similar
> cusps occur ubiquitously, but at the finest scale, a pixel is
> either black to represent a smaller structure, or not black,
I'm not clear on the term "at the finest scale" applied to the
Mandelbrot Set. The point of a fractal is that at any magnification
the structures look the same, so that if my attack works at all,
it should be magnification-independent: pick any section of
boundary, eliminate the cost of rotation by picking a section
with the correct orientation across the landscape, magnify it
enough so that the gross features match, then X-Y shift it until
the Hamming distance is minimized.
> because smaller structured are not set on a quantized grid. So
> one is free to place a black pixel, or leave one out at a cusp
> without flagging any oddity such as your attack would catch.
I'm not following how one picks such a pixel carefully, but you
may be right. Again, the details might determine whether this
would work.
--
Jim Gillogly
Highday, 20 Afterlithe S.R. 1999, 13:40
12.19.6.6.8, 6 Lamat 16 Tzec, Second Lord of Night
------------------------------
** 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
******************************
