Cryptography-Digest Digest #873, Volume #9 Tue, 13 Jul 99 00:13:03 EDT
Contents:
Re: How Big is a Byte? (was: New Encryption Product!) (John Varela)
Re: How Big is a Byte? (was: New Encryption Product!) (Peter Seebach)
Re: randomness of powerball, was something about one time pads ([EMAIL PROTECTED])
Re: Fractal encryption ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: How hard is it to find the key in DES? (Bradley Yearwood)
Re: How Big is a Byte? (was: New Encryption Product!) (Peter Seebach)
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: Analysis of ICE? ("Dan")
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (Dennis Ritchie)
Re: Benfords law for factoring primes? ([EMAIL PROTECTED])
Re: How hard is it to find the key in DES? (fungus)
Re: Analysis of ICE? ([EMAIL PROTECTED])
Re: Is Stenography legal? ("Kristof Burek")
Re: Fractal encryption ("Kristof Burek")
Re: Is it possible to combine brute-force and ciphertext-only in an (Nicol So)
Re: What is the "real" length of a key in 3-key 3DES? (Nicol So)
Re: Fractal encryption (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Varela)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 12 Jul 1999 23:59:40 GMT
On Mon, 12 Jul 1999 22:15:52, [EMAIL PROTECTED] (Matthew Gates)
wrote:
> In article <[EMAIL PROTECTED]>,
> Boris Kazak <[EMAIL PROTECTED]> writes:
> > Just as B(reast) has two N(ipples), B(yte) has two N(ibbles)
>
> Breast singular, two nipples?
That's udderly ridiculous.
--
John Varela
to e-mail, remove - between mind and spring
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
From: [EMAIL PROTECTED] (Peter Seebach)
Date: Tue, 13 Jul 1999 01:35:51 GMT
In article <7matvg$p1o$[EMAIL PROTECTED]>,
Paul Schlyter <[EMAIL PROTECTED]> wrote:
>Does this mean that a C implementation on the Cray supercomputer
>must have 64-bit chars?
No, as long as it can figure out a way to address the individual sub-words,
it's allowed to.
That said, I believe at least one did the "obvious" thing; sizeof(long) == 1,
LONG_MAX=(2^63-1).
-s
--
Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
Date: Sun, 11 Jul 1999 22:05:03 -0400
From: [EMAIL PROTECTED]
Subject: Re: randomness of powerball, was something about one time pads
Douglas A. Gwyn wrote:
>
> [EMAIL PROTECTED] wrote:
> > Perhaps the best example of this principle if the contest Hofstadter
> > offer when he was contributing to Scientific American. The deal was to
> > send a postcard containing a number to SA in order to win a prize of
> > $1,000,000 divided by the largest integer submitted.
> > He thought the best answer was a complicated analysis of the
> > probabilities. In fact it was obvious by inspection that the value of
> > winning was less than the cost of the postage stamp.
>
> No, what it demonstrated was that the utility (measured in
> satisfaction, fame, or whatever) of merely being the winner was
> greater, for many entrants, than the money offered as the prize.
You are analyzing the actions of the participants. I was analyzing the
structure of the offer.
>
> Unbounded or open-ended games often hold surprises. For example,
> suppose you're matching coins against the (fair) house and double
> your bet each time you lose, starting with a $1 bet the first play
> and each time you won the previous play. Note that each time you
> win the play, you are $1 ahead for that "run" (losing streak, win).
> Evidently, you can make an arbitrarily large amount of money if
> you keep playing. What (if anything) is wrong with this "system"?
It is a 1-D random walk with exponentially increasing step sizes in one
direction (the negative/losing end), and constant step sizes in the
other (positive/winning end). Also, it is the _exact_ opposite of the
"investment strategy" of letting your winners run and cutting off your
losses.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Fractal encryption
Date: Tue, 13 Jul 1999 01:57:12 GMT
In article <[EMAIL PROTECTED]>,
"Krishna Sawh" <[EMAIL PROTECTED]> wrote:
> Where can I find more infomation on fractal encryption, dose any body
> here know anythink ???
This has to be a theme. Can someone finally answer this question and
end this? It seems that every two weeks this question comes up...
I thought cryptosystems based on chaotic maps and such existed? Is
this along the posters line of questioning? If so where could we find
a description of such?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Sun, 11 Jul 1999 21:22:49 -0400
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
[EMAIL PROTECTED] wrote:
>
> In article <7mdo04$bc$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > > It matters not when concerning security issues.
> >
> > Can you prove that, or are you just making it up?
>
> My logic is what makes 'y += state[++x]' more secure then 'y += state
> [x++]'? The first is normally faster for some compilers, but they both
> have a similar effect. All 'x' is used for is to make sure each
> element is used at some point.
>
> I know the standard (well accepted standard) uses the first...
>
> > > If I put a &255 the compiler CAN NOT optimize it away.
> >
> > Of course it can. What are you talking about?
>
> Well it would have to optimize it by only using the lower 8 bits. In
> turbo c for example if I did
>
> c = (unsigned char) (a + b);
>
> It would make
>
> ; {
> ; c = (unsigned char) (a + b);
> ;
> mov al,byte ptr DGROUP:_a
> add al,byte ptr DGROUP:_b
> mov ah,0
> mov word ptr DGROUP:_c,ax
>
> And
>
> c = (a + b) & 255;
>
> would make
>
> ; c = (a + b) & 255;
> ;
> mov ax,word ptr DGROUP:_a
> add ax,word ptr DGROUP:_b
> and ax,255
> mov word ptr DGROUP:_c,ax
>
> Both of which are equally as fast. Either way you have to exclude or
> and against (or mod) the part you need.
>
> How would a C compiler optimize
>
> c = (a + b) & 255
>
> in your books?
I depends on what the variable c is used for later in the code stream.
If c is never read, then this is a dead store and _all_ of it goes
away. If c is written to before it is read it is a dead store too.
It also depends on the attributes of a and b. If they are both const
and have initialization values of 2 and 3 the compiler is going to store
5 in c and ignore the &255. If c is used in following expressions the
compiler may not even load from c, simply providing the known value of 5
as necessary. This enables further optimizations due to constant
folding, and those enable still more.
Trivial cases, such as a and b being parameters to a function and c the
return value are easy in that WYSIWYG. But non-trivial cases are
harder. They can produce nothing, in the case of a dead store, a
little, in the case of an effective const, or a huge deluge of code if a
and/or b are user-defined classes with non-standad operator+() or
operator&(udc lhs, int rhs) functions.
------------------------------
From: [EMAIL PROTECTED] (Bradley Yearwood)
Subject: Re: How hard is it to find the key in DES?
Date: 13 Jul 1999 01:37:07 GMT
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Bradley Yearwood wrote:
>> Single-DES (56 bit key) is thus demonstrated to be far too weak now
>> for most applications.
>
>It is *barely* too weak against a modern adversary who uses an
>EFF-like attack. A similar attack against 3DES would be pointless.
Agreed on 3DES, so far, I hope.
I disagree for most casual (casual on the using side, not on the adversary
side) applications on the _barely_ aspect for single DES. I feel that most
casual applications will have enough of a bitwise known-plaintext aspect to
allow trial decrypts to be scored by simple bit-masked comparison, as I
believe the EFF chip does.
This is not to say that it is especially difficult to devise ways of using
single DES which prevent the EFF machine from making useful progress. The
question is whether most people will be sufficiently careful and diligent
to do so.
------------------------------
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
From: [EMAIL PROTECTED] (Peter Seebach)
Date: Tue, 13 Jul 1999 01:30:36 GMT
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>However, AFAIK, that is the *only* place the term byte has ever been used
>to describe anything other than an (ahem) octet,
You chose probably the funniest possible newsgroup in which to make this
claim.
-s
--
Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
Date: Sun, 11 Jul 1999 22:11:15 -0400
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
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.
OK, nostalgia fans, place this:
[picture of three "suits" with submachineguns hosing down a <TLA>
convention booth]
Caption: "Eat flaming death minicomputer mongrels!"
------------------------------
From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: Analysis of ICE?
Date: Mon, 12 Jul 1999 20:42:38 -0500
[EMAIL PROTECTED] wrote in message <7mdtgs$2gu$[EMAIL PROTECTED]>...
>I was just wondering if there ever was any analysis of ICE done?
It's broken: Differential Cryptanalysis of the ICED Encryption Algorithm,
Bart Van Rompay, Lars Knudsen, Vincent Rijmen. ICE was introduced at FSE
'97, and this paper showing it to be broken was given at FSE '98.
ftp://ftp.esat.keleuven.ac.be/COSIC/vrompay/fse98.ps.gz
------------------------------
Date: Sun, 11 Jul 1999 22:14:30 -0400
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
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?
They spoke English. Their usage counts.
>
> John Savard ( teneerf<- )
> http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Tue, 13 Jul 1999 02:41:07 +0100
Reply-To: [EMAIL PROTECTED]
Peter Seebach wrote:
>
> Paul Schlyter <[EMAIL PROTECTED]> wrote:
> >Does this mean that a C implementation on the Cray supercomputer
> >must have 64-bit chars?
>
> No, as long as it can figure out a way to address the individual sub-words,
> it's allowed to.
>
> That said, I believe at least one did the "obvious" thing; sizeof(long) == 1,
> LONG_MAX=(2^63-1).
I don't know about "at least one," but the Cray C compiler
for Unicos on the X/MP and Y/MP has sizeof(char)==1,
sizeof(anything else)==8, and I don't recall any deviations
from C89 requirements except for a bug or two, which CRI fixed.
For short and int, though they were stored in 64-bit words,
cheaper instruction sequences and shorter registers were
used when possible, so that int*int or int/int didn't
call forth the full messiness needed to do better than
required to get a 32-bit result.
Dennis
------------------------------
Date: Sun, 11 Jul 1999 22:07:33 -0400
From: [EMAIL PROTECTED]
Subject: Re: Benfords law for factoring primes?
Bob Silverman wrote:
>
> In article <[EMAIL PROTECTED]>,
> mok-kong shen <[EMAIL PROTECTED]> wrote:
> > Blank wrote:
> > >
> > > Has anyone looked into using Benfords ( prob first digit D = log
> 1+1/D ) law
> > > to sort the lists of potential factors for brute force prime
> cracking? Do
> > > observable primes obey Benfords law. Its late here and my quickly
> hacked
> > > little VB pgm seems to say no.
> >
> > The cause that one probably has neglected that could be that the
> > benefit resulting from the law
>
> Your reply "assumes facts not in evidence".
>
> I ask:
>
> What benefit?
>
> Specify an algorithm by which doing trial division by primes whose
> most significant decimal digit is "1" gives a speed improvement.
>
> A straight application will make it SLOWER on average. To see this
> I give a hint: If N is a randomly chosen large integer, the
> probability that a prime p divides N is 1/p. A full explanation
> will follow if noone gets it.
>
> This entire thread is "wrong headed"
Clearly he meant most signifigant _bit_ rather than most signifigant
_digit_!
;-)
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him think"
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: How hard is it to find the key in DES?
Date: Tue, 13 Jul 1999 05:16:46 +0200
Bradley Yearwood wrote:
>
> This is not to say that it is especially difficult to devise ways
> of using single DES which prevent the EFF machine from making useful
> progress. The question is whether most people will be sufficiently
> careful and diligent to do so.
DESX would defeat the EFF machine for very little cost.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Analysis of ICE?
Date: Tue, 13 Jul 1999 02:46:41 GMT
<snip>
I found this http://www.funet.fi/~bande/docs/crypt/
For anyone who cares...
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?
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Kristof Burek" <[EMAIL PROTECTED]>
Subject: Re: Is Stenography legal?
Date: Tue, 13 Jul 1999 03:16:27 +0100
I think it would be _very_ amusing if an entire court-full of stenographers
were suddenly to be pounced upon and arrested. Who would do the stenography
when they came to court?
Kristof
PS is this deja.com designed for ... ...?
<[EMAIL PROTECTED]> wrote in message
news:7m163f$vsn$[EMAIL PROTECTED]...
| Is stenography legal? I mean what if I took a 100 byte message and
| spread out the plaintext among 1024 bytes of random giblygook. It
| would be hard to decrypt (how so is challenging)....
|
| Is this against EAR?
|
| Tom
| --
| PGP key is at:
| 'http://mypage.goplay.com/tomstdenis/key.pgp'.
| Free PRNG C++ lib:
| 'http://mypage.goplay.com/tomstdenis/prng.html'.
|
|
| Sent via Deja.com http://www.deja.com/
| Share what you know. Learn what you don't.
------------------------------
From: "Kristof Burek" <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Tue, 13 Jul 1999 03:29:40 +0100
Krishna Sawh <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
| ... ... dose any body
| here know anythink ???
A good question!
Kristof
|
| Krishna Sawh
| [EMAIL PROTECTED]
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: Mon, 12 Jul 1999 23:35:23 -0400
Douglas A. Gwyn wrote:
>
> Nicol So wrote:
> > In my layman's understanding, the Copenhagen interpretation is
> > the philosophical interpretation of QM currently favored by
> > physicists.
>
> No, it has fortunately fallen out of favor, and many physicists
> never were happy with it.
If you don't mind, could you explain in simple terms what is the current
thinking on the subject among physicists? (I understand that this is
not really cryptology, but I think it will be of interest to the readers
of this group because of the subject's connection to the theoretical
existence of non-determinism). Thanks.
Nicol
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Mon, 12 Jul 1999 23:54:38 -0400
Kristof Burek wrote:
>
> PS my understanding would be that since there are far fewer than 2^168
> possible mappings of a 64-bit block to another 64-bit block, ...
Try to come up with an expression for the number of permutations on
64-bit strings and you'll quickly realize that the above is not true.
Nicol
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Fractal encryption
Date: Mon, 12 Jul 1999 21:08:55 -0700
Glenn Davis wrote:
> 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.
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. The number of iterations
wouldn't be too huge, because it would need to be computable
in reasonable time; in any case, it could be estimated from
the points that <are> there. The cryptanalyst XORs it, and
tries various X-Y movements, rotations, and iterations until the
Hamming distance between that spot and the cryptogram is minimized.
Repeat this a number of times in different places along the boundary,
and check what parts of the XOR'ed shadow change from point to point.
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.
--
Jim Gillogly
Highday, 20 Afterlithe S.R. 1999, 03:58
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
******************************
