Cryptography-Digest Digest #960, Volume #10 Sun, 23 Jan 00 18:13:01 EST
Contents:
Re: Challenge. (Scott Nelson)
Re: Transposition over ASCII-coded text (wtshaw)
Re: XOR for bits, EOD for trits (wtshaw)
Re: XOR for bits, EOD for trits (wtshaw)
Re: Combination of stream and block encryption techniques (wtshaw)
Re: Intel 810 chipset Random Number Generator (Herman Rubin)
Re: How much random needed for random (Herman Rubin)
Re: NIST, AES at RSA conference (Mok-Kong Shen)
Re: Challenge. (Doug MacKay)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: Ciphers for Parallel Computers (Tim Tyler)
Re: New Crypto Rules (Bill Unruh)
Re: NIST, AES at RSA conference (CLSV)
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: How much random needed for random ([EMAIL PROTECTED])
Re: NIST, AES at RSA conference ("Brian Gladman")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Challenge.
Reply-To: [EMAIL PROTECTED]
Date: Sun, 23 Jan 2000 17:17:05 GMT
On Sat, 22 Jan 2000 [EMAIL PROTECTED] wrote:
>Hi,
>
>Can anyone crack this code?
>If you can, email me the solution.
>
>x11yijx24xcydx.ztlyoyaxxzilxmytyuy8x.yuytzoozoozn.zznv
>
>Jack
>
>P.S. It is more for amateurs than professionals with huge computer
>power.
I make it out as
"pleasereadthesci.cryptfaqbeforeyoupostandomciphertext."
Low level "non-science" cryptography is more of a puzzle
than a topic for discussion. You might have better luck
posting to rec.puzzles.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Transposition over ASCII-coded text
Date: Sun, 23 Jan 2000 11:46:20 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>
> One way to combine error correction and encryption is to first
> remove redundancy from the PT, encrypt that, then add redundancy
> back for error control. The added redundancy does not weaken
> the encryption.
That does make good sense, to keep the redundancy fairly low. Messages
can be input in a less redundant form, as in using telegraphic
abreviations. The skill in reading such things is easily learned, as is
that for writing it.
Interestingly enough, many of those in crypto are already well schooled in
doing this, almost a complete list of chronic and serious posters in this
group.
The goal of decreasing redundancy is to allow real meaning to be conveyed
in as brief a form as possible. An active method for doing the same with
real text could be used, drop the, a, an, replace and with es, from with
de, use some real code lists for usual things. As a ARS guy, I am happy
to correspond in that fashion, even with encryption as a step, just not
doing that step on the actual airwaves.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: XOR for bits, EOD for trits
Date: Sun, 23 Jan 2000 11:59:34 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Probably most people would have just used noncarrying addition without
> even thinking of any alternatives.
>
> 0 1 2 0 1 2
> ------ ------
> 0 | 0 1 2 0 | 0 2 1
> 1 | 1 2 0 1 | 2 1 0
> 2 | 2 0 1 2 | 1 0 2
>
> The first table shows noncarrying addition, the second your proposed
> method, which indeed does result in a Latin Square, and is thus
> reversible.
>
Yes, it shows the easy and varied logic possibilities with trits. You can
produce a third choice. Now, you can a another input to select between
the three methods, trit input of course.
As I get more hand control back, I will surely be hitting the discretes to
see if I can build such gates, but it will still be a while as the thought
of dropping a solder iron in my lap is enough to put in off, as if I had
much feeling there either.
Setting voltate levels is possible, or using phases of AC for the trit
logic, self clocking. Of course you dont have a flip flop either, since
that is bit based. Trit logic can be build so that binary logic can still
be used too....lots to think about here.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: XOR for bits, EOD for trits
Date: Sun, 23 Jan 2000 12:12:04 -0600
In article <[EMAIL PROTECTED]>, "Peter L. Montgomery"
<[EMAIL PROTECTED]> wrote:
>
> Call the left function ADD3 and the right function XOR3.
> Then
> ADD3(x, y) == x + y (mod 3)
> XOR3(x, y) == -x - y (mod 3)
>
> We can evaluate XOR3 as ADD3(z, z) where z = ADD3(x, y).
> We can evaluate ADD3 as XOR3(0, XOR3(x, y)).
> If a ternary machine provides one of these, it is easy to get the other.
>
Maybe...interesting...then, the XOR3 is more primative than the ADD3?
EOD would mean equal or different. Being systematic does mean accomodating
all possibilities for these devices, more than an hand full.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Combination of stream and block encryption techniques
Date: Sun, 23 Jan 2000 12:20:47 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Ah, I see you are apparently arguing for a THIRD category, i.e.
> for stuffs that don't clearly fall into either (of the existing two)
> categories, don't you? (Would you like to suggest a name for that?)
> Isn't the mere existence of the fact that there are examples that
> don't clearly fall into either categories an indication of deficiency
> of the current classification system and therefore gives additional
> support for removing the boundary between the two categories?
>
There is a problem with purity where something is mostly one thing or
another, as there are three common hues of white based on the choice of
wavelengths to be mixed.
And black, well, it's hard to compare a good black where it is necessary
to have everything visable not.
Well, not everything that walks and quacks like a duck is a duck, and
ducks can be so that they neither walk nor quack, as well as doing only
one of these.
--
To prevent the comprimise of with the most common configuration
of computers is something like preventing a sculptor from being too original. If a
computer design is corruptable, it will be.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 23 Jan 2000 13:36:03 -0500
In article <86dvcl$a17$[EMAIL PROTECTED]>,
Michael Kagalenko <[EMAIL PROTECTED]> wrote:
>Herman Rubin ([EMAIL PROTECTED]) wrote
>]In article <86au71$m0n$[EMAIL PROTECTED]>,
>]Michael Kagalenko <[EMAIL PROTECTED]> wrote:
>]>Guy Macon ([EMAIL PROTECTED]) wrote
>]>]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
................
>]> No. You are wrong. So long as you can reliably count the number of cycles
>]> of quartz crystal, you can use this to recover thermally random numbers.
>]> Temperature dependence may be indeed a proble, but it can be accounted
>]> for either by thermostabilising or by simply measuring it and feeding
>]> it into computational process.
>]Using the general idea of random, not only this, but everything
>]else, is random.
> False. You did not understand the physics that I am proposing to use.
>] But this does not mean that it will have the
>]independence properties needed for use as "random numbers".
> As I said elsewhere, you are wrong.
Independence is a very strong property. For numbers to be
used as "random numbers" are typically used, it is often
more important than the uniformity of the distribution,
which can be corrected, is the independence of the numbers
produced by the device. Exact independence means that
the conditional probability distribution of one output
given the rest is the same as not having that information.
Perfect independence is impossible. Radioactive decay,
counting the parity of the number of events sufficiently
rarely, comes quite close, although the bias in the
recording device limits how much can be done; there are
ways to use multiple streams to improve things.
It is only the UNpredictable part which is useful for
random purposes. Moderate range dependence of thermal
noise is hard to keep.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Subject: Re: How much random needed for random
Date: 23 Jan 2000 13:44:05 -0500
In article <[EMAIL PROTECTED]>, Yoni M. <[EMAIL PROTECTED]> wrote:
>I'm using SecureRandom (java) in my SSL implementation to produce the
>random bytes needed for the challanges. My problem is performance, it
>takes too long to generate the bytes. If I'm using a simple Random
>everything is much faster.
>Can I initialize the secure random with the current time (long), or
>isn't it enough ? This way is much faster than initializing the
>SecureRandom without any seed.
>Does anyone knows of a short cut or suggestion how to improve the
>performance without reducing security ?
Any pseudo-random generator will fail a test, namely, the
test it came from that generator. The ones believed to be
cryptographically strong are quite slow. Of course, one
with a seed with a large number of bytes will, if those bytes
are generated by "at random", be random as long as only those
bytes, or an equivalent functionally independent set, are
used. The rest is a problem of determining the generator
and the seed, and then carrying out the computation.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 23 Jan 2000 20:23:09 +0100
CLSV wrote:
>
> Well, governments *are* paying experts to research
> cryptography. In the United States they are concentrated
> in a certain Fort Meade in Maryland. What more could one
> wish? ;-)
>
> But seriously I think a crisis is made up (concerning pure
> cryptographic research) in this thread where no real crisis
> exists.,
Do you seriously believe that the results obtained in Maryland
and similar places will be published for the benefit of the
general public?
M. K. Shen
------------------------------
From: Doug MacKay <[EMAIL PROTECTED]>
Subject: Re: Challenge.
Date: Sun, 23 Jan 2000 14:17:47 -0500
> Hi,
>
> Can anyone crack this code?
> If you can, email me the solution.
>
> x11yijx24xcydx.ztlyoyaxxzilxmytyuy8x.yuytzoozoozn.zznv
To save everyone's time this says:
"I do not know how to read the sci.crypt FAQ on challenges"
and is just XOR'ed against a value I dont feel like posting right now.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 23 Jan 2000 20:23:55 GMT
In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
>> Why not just do what CipherSaber does, which is combine the
>> passphrase with a random salt before doing the key setup, and
>> send the salt in the clear?
>
>The problem is that you want to skip key setup because
>it is very labor intensive. But I posted an alternative
>like initializing I and J with other values than 0.
I thought that the "coins" method might make key setup
tolerably fast. Re-using keys with different initial I and J
sounds very dangerous. Collecting a few such messages
reveals too much of the state vector.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Reply-To: [EMAIL PROTECTED]
Date: Sun, 23 Jan 2000 20:57:06 GMT
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
:[TT wrote]
:> I'm not qualified to evaluate these claims, based on my current knowledge
:> of the NTRU public-key cryptosystem. Can anyone more in the know comment?
: I may not be too overly qualified either, but a brute-force attack can
: ALWAYS be parellelized, so I believe there's an 8-letter word beginning with
: bull that says it all. [...]
It looks like I was misinterpreting their hype.
After re-reading the material, they are talking about parallelising the
testing of a single key.
In other words, the paragraph I cited was not intended to apply to the
process of parallel searches, testing more than one key at a time.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Legalise IT.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: New Crypto Rules
Date: 23 Jan 2000 21:19:43 GMT
In <86f8sv$opq$[EMAIL PROTECTED]> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> Could someone be nice enough to state Plainly. What is the minimun
>one needs to do to leaglly do to put ones own free source code to ones
>encryption software out on the net for others to download. Please don't
>say look at the BXA rules. THey are of no help to those of use in the game
>for fun. I do not wish to make a profit. I just want the minum hassle of
>putting my source code on the net for FREE.
You are playing with large sums of money here and your freedom. The best
advice is "read the rules" "Get your lawyer to read the rules". Then you
can proceed.
oAnyway, from my very cursory reading of the rules, ( so do not use that
as justification as the men in black coats come for you-- or if the men
in white coats come for you), you can publish source code on the net if
you send Commerce the web address of your site when you put it up.
This is not legal advice.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 23 Jan 2000 21:52:27 +0000
Mok-Kong Shen wrote:
> CLSV wrote:
> > Well, governments *are* paying experts to research
> > cryptography. In the United States they are concentrated
> > in a certain Fort Meade in Maryland. What more could one
> > wish? ;-)
> > But seriously I think a crisis is made up (concerning pure
> > cryptographic research) in this thread where no real crisis
> > exists.,
> Do you seriously believe that the results obtained in Maryland
> and similar places will be published for the benefit of the
> general public?
Well, the smiley was there on purpose.
But I believe that the results obtained by government
agencies could be used for the benefit of the general
public. However this does not imply that those results
will be published.
The development of DES is an example, the algorithm
itself (S-boxes) was made stronger. Why the S-boxes
where designed the way they were was not disclosed.
In fact the disclosure of the algorithm itself was a
mistake. Nevertheless improvements were made that
benefitted the public.
Regards,
CLSV
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sun, 23 Jan 2000 21:56:29 +0000
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>, CLSV <[EMAIL PROTECTED]> wrote:
> >> Why not just do what CipherSaber does, which is combine the
> >> passphrase with a random salt before doing the key setup, and
> >> send the salt in the clear?
> >
> >The problem is that you want to skip key setup because
> >it is very labor intensive. But I posted an alternative
> >like initializing I and J with other values than 0.
>
> I thought that the "coins" method might make key setup
> tolerably fast. Re-using keys with different initial I and J
Hmm, if we use the ARC4 setup that means creating
52 output values that we throw away. Say 30 secs
per character that means 25 minutes shuffling cards
at top speed before encryption starts.
> sounds very dangerous. Collecting a few such messages
> reveals too much of the state vector.
Ah, you got me there. Patching a cipher is never
a good idea. At least not without proper analysis.
Regards,
CLSV
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How much random needed for random
Date: Sun, 23 Jan 2000 22:22:36 GMT
> I'm using SecureRandom (java) in my SSL implementation to produce the
> random bytes needed for the challanges. My problem is performance, it
> takes too long to generate the bytes. If I'm using a simple Random
> everything is much faster.
> Can I initialize the secure random with the current time (long), or
> isn't it enough ? This way is much faster than initializing the
> SecureRandom without any seed.
> Does anyone knows of a short cut or suggestion how to improve the
> performance without reducing security ?
The current time (long) only contains a few bits of entropy
(unguessable or unpredicatable) information. You need to obtain a
better source of true random data for your seed.
As for the PRNG, Java's SecureRandom uses SHA-1 as the basis for it's
PRNG, so it seems ok. The normal Random function is only designed to be
statistically random, but not designed to protect the seed; I wouldn't
touch it with a 10 foot poll.
If you are interested in a good PRNG, try ISAAC. Check it out at
http://burtleburtle.net/bob/rand/isaacafa.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 23 Jan 2000 19:33:07 -0000
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> CLSV wrote:
> >
> > Well, governments *are* paying experts to research
> > cryptography. In the United States they are concentrated
> > in a certain Fort Meade in Maryland. What more could one
> > wish? ;-)
> >
> > But seriously I think a crisis is made up (concerning pure
> > cryptographic research) in this thread where no real crisis
> > exists.,
>
> Do you seriously believe that the results obtained in Maryland
> and similar places will be published for the benefit of the
> general public?
>
> M. K. Shen
Its an interesting question but even if their results are not published,
what evidence is there that NSA will allow a knowingly weak AES solution to
emerge when doing so will put the US information infrastructure - the most
developed and hence the most vulnerable in the world - at risk?
And looking at DES in retrospect it is now clear that the ***covert*** work
that NSA did on its design greatly improved its strength against attacks
that were discovered later.
We have had 50 years when the balance of government interests have favoured
exploitation - in my view this has now changed and the balance has shifted
in favour of protection.
Brian Gladman
------------------------------
** 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
******************************
