Cryptography-Digest Digest #958, Volume #10 Sun, 23 Jan 00 07:13:01 EST
Contents:
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Simple Equivalent keys in Serpent (wtshaw)
Re: Does RSA use real prime ? (Tom St Denis)
Re: MIRDEK: more fun with playing cards. (Paul Rubin)
Re: Transposition over ASCII-coded text (wtshaw)
XOR for bits, EOD for trits (wtshaw)
Re: Combination of stream and block encryption techniques ("Douglas A. Gwyn")
Re: Transposition over ASCII-coded text ("Douglas A. Gwyn")
Re: Challenge. (Roy Longton)
Re: XOR for bits, EOD for trits (John Savard)
Re: XOR for bits, EOD for trits ("Peter L. Montgomery")
How much random needed for random ("Yoni M.")
Re: Challenge. (Paul Schlyter)
Re: Challenge. ([EMAIL PROTECTED])
Solution to GCHQ puzzle published (Jerry Ennis)
Cipher Challenge from 'The Code Book' (Sisson)
Re: Combination of stream and block encryption techniques (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 23 Jan 2000 04:17:25 GMT
Reply-To: [EMAIL PROTECTED]
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.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 23 Jan 2000 04:16:17 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86au71$m0n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
]Kagalenko) wrote:
]>
]>Guy Macon ([EMAIL PROTECTED]) wrote
]>]
]>]I can see the logic behind trying, but not if you are looking for
]>]a good RNG. But what if you are looking for a cheap RNG?
]>]a cheap crystal (or, better yet, ceramic) oscillator costs very
]>]little, and hooks up to a serial or parallel port easily, and is
]>]pretty much immune to 60 Hz electrical noise. I agree with
]>]everything said about the lack of randomness, though. You really
]>]are just measuring fine differences in the time between reads
]>]of your serial/parallel port. Such a circuit, if Von Neuman
]>]compensated and exlusive or'ed with the output of the best PRNG
]>]you can program, would seem to be, on a practical level, much
]>]superior to the PRNG alone.
]>
]> 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.
]
]I made at least six claims in the paragraph above, and I cannot
]tell from your response exactly what I wrote that prompted the
]"You are wrong" comment. Could you elaborate as to exactly what
]you are disagreeing with? I stand by what I wrote above.
]
It is too bad that you stand by it, because a lot of it is bogus.
The most bogus part is
> I agree with
> everything said about the lack of randomness, though. You really
> are just measuring fine differences in the time between reads
> of your serial/parallel port.
As I said above, you can obtain truly random data by measuring clock
drift due to thermal noise in the crystal. The thermal noise
in question exists to the extent the quartz crystal is lossy, in accordance
with fluctuation-dissipation theorem of statistical physics.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Simple Equivalent keys in Serpent
Date: Sat, 22 Jan 2000 23:27:16 -0600
In article <86cu20$752$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
...
> From looking at the key schedule for Serpent, I believe each 128 and
> 192 bit key has an equivalent 256 bit key.
>
> Quoting from 'Serpent: A Propsal for the Advanced Encryption Standard'
>
> ...
> short keys with less than 256 bits are mapped to full-length keys of
> 256 bits by appending one '1' bit to the MSB end, followed by as many
> '0' bits as required to make up 256 bits.
> ...
It would appear that Serpant can be made to automatically scale itself to
different sizes of key. I would call this possibly a good thing. Let's
hope nothing else works similarily to give unfortunate surprises.
--
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: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Does RSA use real prime ?
Date: Sun, 23 Jan 2000 05:02:25 GMT
In article <86dues$nrm$[EMAIL PROTECTED]>,
"Hank" <[EMAIL PROTECTED]> wrote:
> base. Is this true ?
> > >
> >
> > Yes it's true. Factoring a large N bit number will take too long
for
> > most cases. So they use probable primality testers. I wouldn't
> > dismiss them so casually. For the most part the chances your two
> > primes in RSA [say as made by PGP] are not prime is less then 1 in
> > 2^51. Even if they are composite the chances that you
decrypt/encrypt
> > messages sucessfully more then once is way smaller.
> >
> > See the decryption exponent 'e' is found by taking d^-1 mod (p-1)(q-
> > 1). If either q or p are not prime then 'e' will not be the inverse
> > exponent mod pq.
> >
> > Tom
>
> As I know, the encryption/decryption of RSA is based on Fermat's
theorem, which says
>
> If p is a prime, then a^(p-1) = 1 (mod p) for a in Zn (*)
>
> I don't have a detailed proof on this. And I think it is not a
two-way theorem. That means the
> relation might hold for some carefully chosen 'a' even p is not a
prime.
>
> So I wonder how PGP tackles conditions conditons in which p, q
are not real primes.
> Starting a new round of prime hunting ? Or carefully
selecting 'a' to accord with the
To find the inverse exponent you must have two primes. Or know the
prime factorization of the modulus. If I give you a random n, you have
to factor it to find the order of the group.
Fermat little theorem is that if p is prime the order of the group is p-
1, if n = pq, then the order of n = (p - 1)(q - 1). That is what RSA
is based on. The difficulty of find p and q.
So I repeat. If p or q are not prime, encryption/decryption will not
work for the most part [it may work once with a slight possibility].
So you must find new primes.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: MIRDEK: more fun with playing cards.
Date: 23 Jan 2000 05:10:31 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
>CLSV <[EMAIL PROTECTED]> writes:
>> > When you say "one time", you mean "once per message".
>> No, I mean just once before encrypted communication starts.
>
>Could you be more explicit about how you then go on to encrypt more
>than one message?
>
>I can think of one way, which is simply to start the new message with
>the state where you left off the old message, but this requires that
>the recipient either receive all of your messages (unlikely) or at
>least know how long they all were (OK if your recipient is decrypting
>with a computer).
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?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Transposition over ASCII-coded text
Date: Sat, 22 Jan 2000 23:34:40 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Douglas A. Gwyn wrote:
> >
> > Mok-Kong Shen wrote:
> > > If that interleaving is very systematic, would you consider it
> > > as a (non-trivial) scrambling suitable for encryption purposes?
> >
> > Error correction and encryption have quite different goals.
>
> Yes, I know that. But the writer who initiated this thread
> apparently meant that error correction had something essential
> to do with encryption.
>
The common goal is to get the correct message to the receiver. Choices in
both areas are predominated by this concern, whereas using correction that
gives crypto breaking redundancy means that you had better get another set
of algorithms.
--
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: XOR for bits, EOD for trits
Date: Sat, 22 Jan 2000 23:54:01 -0600
XOR means exclusive either the two inputs are the same or they are
different. The output is one of two states as well. Having the output
stream and one of the input streams allow you to solve fort the other,
cryptographically useful.
Obviously, there is no XOR where there are 3 possible states. But, there
is an easy way to combine two streams of trits in a solvable method:
Given two trit inputs, if they are the same, the output is also the same,
00=0, 11=1, 22=2; If the inputs are different, the output is the remaining
third option, 01=2, 10=2, 12=0, 21=0, 02=1, and 20=1. There are lots of
interesting other possibilites for simple trit logic.
Like to do 1-2-3? OK, Fine, but don't get hit with the bubbles.
--
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Sun, 23 Jan 2000 05:31:25 GMT
Mok-Kong Shen wrote:
> one can obviate the boundary between stream and block ciphers.
The existence of shades of grey does not obviate the difference
between black and white.
A classical example of a stream cipher system is the Enigma.
A classical example of a block cipher system is the DES.
There are numerous clear examples in both categories, as well
as some examples that don't clearly fall into either category.
P.S. Note that Enigma did not operate by XORing a key stream
with the plaintext, nor anything comparable to that.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Transposition over ASCII-coded text
Date: Sun, 23 Jan 2000 05:33:20 GMT
wtshaw wrote:
> The common goal is to get the correct message to the receiver. Choices in
> both areas are predominated by this concern, whereas using correction that
> gives crypto breaking redundancy means that you had better get another set
> of algorithms.
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.
------------------------------
From: Roy Longton <[EMAIL PROTECTED]>
Subject: Re: Challenge.
Date: Sun, 23 Jan 2000 01:39:11 -0500
Tom St Denis wrote:
> In article <86d674$coa$[EMAIL PROTECTED]>,
> [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.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> What possess people to post 'break this "rigtyh3g9gtrb34uotufhjwr"' is
> beyond me.
Second that. For all I know, he could've used OTP.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: XOR for bits, EOD for trits
Date: Sun, 23 Jan 2000 07:02:31 GMT
On Sat, 22 Jan 2000 23:54:01 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
in part:
>Obviously, there is no XOR where there are 3 possible states. But, there
>is an easy way to combine two streams of trits in a solvable method:
>Given two trit inputs, if they are the same, the output is also the same,
>00=0, 11=1, 22=2; If the inputs are different, the output is the remaining
>third option, 01=2, 10=2, 12=0, 21=0, 02=1, and 20=1. There are lots of
>interesting other possibilites for simple trit logic.
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.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: XOR for bits, EOD for trits
Date: Sun, 23 Jan 2000 09:49:54 GMT
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (John Savard) writes:
>On Sat, 22 Jan 2000 23:54:01 -0600, [EMAIL PROTECTED] (wtshaw) wrote,
>in part:
>>Obviously, there is no XOR where there are 3 possible states. But, there
>>is an easy way to combine two streams of trits in a solvable method:
>>Given two trit inputs, if they are the same, the output is also the same,
>>00=0, 11=1, 22=2; If the inputs are different, the output is the remaining
>>third option, 01=2, 10=2, 12=0, 21=0, 02=1, and 20=1. There are lots of
>>interesting other possibilites for simple trit logic.
>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.
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.
--
E = m c^2. Einstein = Man of the Century. Why the squaring?
[EMAIL PROTECTED] Home: San Rafael, California
Microsoft Research and CWI
------------------------------
Date: Sun, 23 Jan 2000 11:59:15 +0200
From: "Yoni M." <[EMAIL PROTECTED]>
Subject: How much random needed for random
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 ?
Yoni.
--
Yoni Mizrahi
Development Team
Bridges for Islands
Tel: +972-3-649-9971,
Fax: +972-3-649-8744
Web: http://www.b4i.com
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Challenge.
Date: 23 Jan 2000 09:57:09 +0100
In article <86d674$coa$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> Can anyone crack this code?
> If you can, email me the solution.
>
> x11yijx24xcydx.ztlyoyaxxzilxmytyuy8x.yuytzoozoozn.zznv
It's a one-time pad, with the following solution:
x11yijx24xcydx.ztlyoyaxxzilxmytyuy8x.yuytzoozoozn.zznv
You fool wasting time trying to break my stupid crypto
I leave it as a exercise to the reader to figure out the key... :-)
--
================================================================
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: [EMAIL PROTECTED]
Subject: Re: Challenge.
Date: Sun, 23 Jan 2000 10:47:53 GMT
In article <[EMAIL PROTECTED]>,
Roy Longton <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
>
> > In article <86d674$coa$[EMAIL PROTECTED]>,
> > [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.
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> > >
> >
> > What possess people to post 'break this "rigtyh3g9gtrb34uotufhjwr"'
is
> > beyond me.
>
> Second that. For all I know, he could've used OTP.
Yeah, but I didn't.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Ennis <[EMAIL PROTECTED]>
Subject: Solution to GCHQ puzzle published
Date: Sun, 23 Jan 2000 06:08:34 -0500
GCHQ posted a five-word code hidden on 20 pages
of its website, www.gchq.gov.uk, and invited anyone
who could break it to apply as a recruit.
The Sunday Times solved the puzzle and has published its solution at
http://www.the-times.co.uk/news/pages/Times/frontpage.html?999
------------------------------
From: Sisson <[EMAIL PROTECTED]>
Subject: Cipher Challenge from 'The Code Book'
Date: Sun, 23 Jan 2000 11:20:05 GMT
Hi all,
(sorry if this sounds like an ad, its not really... and even if it is, i
don't make any profit from this site)
If anyone is having trouble with the Cipher Challenge from 'The Code
Book' then you might want to goto my site for help. It has:
Hints for stages 2,3,4,6
Deciphering tools for download
Links to help you
my ideas on stage 5 (probably all wrong though; i haven't finished it...
and probably never will)
well, its at http://users.bigpond.net.au/spendabuck/cipher/
>From Spendabuck
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Combination of stream and block encryption techniques
Date: Sun, 23 Jan 2000 12:36:36 +0100
Douglas A. Gwyn wrote:
>
> Mok-Kong Shen wrote:
> > one can obviate the boundary between stream and block ciphers.
>
> The existence of shades of grey does not obviate the difference
> between black and white.
Yet today, in contrast to ancient times, these shades can be very
well coded in pixels and black and white are simply two 'special'
cases (they have difference in pixel value of 255). Why is having a
more general concept worse than having only two extreme ones in
science? Having only two extreme ones cause the trouble you mentioned
below. As I said in my previous follow-up, one 'need' to
describe/discuss an algorithm in terms of its constituent
operations and a name for calling the whole thing 'stream' or
'block' doesn't help much and could even be misleading in situations
that you argued below.
> A classical example of a stream cipher system is the Enigma.
> A classical example of a block cipher system is the DES.
> There are numerous clear examples in both categories, as well
> as some examples that don't clearly fall into either category.
>
> P.S. Note that Enigma did not operate by XORing a key stream
> with the plaintext, nor anything comparable to that.
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?
M. K. Shen
------------------------------
** 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
******************************
