Cryptography-Digest Digest #125, Volume #13 Wed, 8 Nov 00 19:13:01 EST
Contents:
Re: A question about RSA (Simon Johnson)
Re: CHALLENGE TO cryptanalysts (Simon Johnson)
Re: CHALLENGE TO cryptanalysts (Sundial Services)
Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software (Tom
St Denis)
Re: Updated XOR Software Utility (freeware) Version 1.1 from CiphileSoftware (Tom St
Denis)
Re: CHALLENGE TO cryptanalysts (Tom St Denis)
Re: [newbie] Is PGP 7.0 hash extension secure? ([EMAIL PROTECTED])
Re: A question about RSA (Paul Crowley)
Re: Hardware RNGs ([EMAIL PROTECTED])
Regarding assymetric encryption algorithms ("NoLimitB")
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: A question about RSA
Date: Wed, 08 Nov 2000 22:11:25 GMT
In article <[EMAIL PROTECTED]>,
Chenghuai Lu <[EMAIL PROTECTED]> wrote:
> Suppose we know n (= p * q), which is a multiple of two large primes,
> and phi(n) where phi(x) is the Euler function. Can anybody give the
> algorithm to find p and q in polynomial time?
>
> Thanks.
>
> --
>
> -Chenghuai Lu ([EMAIL PROTECTED])
>
oooh, u can't without solving P=NP.... for which there is a million
dollars going.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: CHALLENGE TO cryptanalysts
Date: Wed, 08 Nov 2000 22:39:50 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Melinda Harris wrote:
> >
> > The notorious Crypto-Eccentric is preparing to issue a challenge on
January
> > 1st 2001 to cryptanalyst and hackers alike including all government
agencies
> > to crack his braintwisting ANEC code. It is to support his claim of
having a
>
> I can hardly imagine that there will be a single person
> of our group unreasonable enough to spend a minute of
> his precious time examining any new encryption scheme
> that does not have a well crafted document giving concise
> and clear description of the algorithm as well as convincing
> rationales of the design. Indeed, presenting pure codes is
> the notoriously worst way of attracting other person's
> attention to a cipher.
>
> M. K. Shen
>
That's a perfect reply...... the only reason i'm typing this is to
back that reply.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 08 Nov 2000 16:35:05 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: CHALLENGE TO cryptanalysts
Anyone in the world can create a message, encipher it 500 different
times with 500 different cryptosystems and "challenge" someone to break
it. Obviously they will not be able to do that, nor will they try.
Cryptosystems in the real world need to be able to encrypt and decrypt
messages accurately in a flash -- maybe in a silicon chip -- and produce
provably predictable security against the attacks to which the data is
likely to be subjected, which is to say, "security that is appropriate
to the classification of the data." They need to be able to encrypt and
decrypt millions of messages that way.
The now-familiar SSL (Secure Socket Layer) technology is a perfect
example of security like this. It's one of the most widely used
security protocols in the world. And it is completely transparent. It
is not appropriate to military Classified information, much less Secret,
maybe not even Confidential -- but it's perfect for concealing your
credit-card number on its way to an on-line store. The encryption that
is used in automatic teller-machines and credit-card swipe terminals is
another example of this sort of cryptography.
It's not spook stuff ... hell, it's MUNDANE ... but it's vital.
>Mok-Kong Shen wrote:
>
> Melinda Harris wrote:
> >
> > The notorious Crypto-Eccentric is preparing to issue a challenge on January
> > 1st 2001 to cryptanalyst and hackers alike including all government agencies
> > to crack his braintwisting ANEC code. It is to support his claim of having a
>
> I can hardly imagine that there will be a single person
> of our group unreasonable enough to spend a minute of
> his precious time examining any new encryption scheme
> that does not have a well crafted document giving concise
> and clear description of the algorithm as well as convincing
> rationales of the design. Indeed, presenting pure codes is
> the notoriously worst way of attracting other person's
> attention to a cipher.
------------------------------
From: d <[EMAIL PROTECTED]>
Subject: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Wed, 08 Nov 2000 23:34:40 +0000
Command line One Time Pad utility. Options: pad generation, randomness
testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
source and DOS executable included.
Free download at <http://www.vidwest.com/otp/>
Your bug reports/other feedback will be gratefully received.
[EMAIL PROTECTED]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile Software
Date: Wed, 08 Nov 2000 23:27:39 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Or going way over the top ranting and raving in these news groups.
I re-post
---
Sure these are the sources/things I have posted in the last six months.
The peekboo v2.01 program, the cryptobag API, the Tiger/PRNG API, the
password generator, the ciphers TC1 to TC7, my revision of Twofish, my
two revisions of Blowfish, my SHA-256 source code, my sbox generator
(new release soon btw), my affine transorm code, my "nyberg sbox" code,
my new serpent and gost sboxes, GOST source code and my observation on
the suboptimality of Matsui sboxes.
What have you done?
Tom
---
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from CiphileSoftware
Date: Wed, 08 Nov 2000 23:28:39 GMT
In article <[EMAIL PROTECTED]>,
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Scott Craver wrote:
> >
> > Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > >>
> > >> I, like you, marvel at how poor the programming had to have been
such that
> > >> 1.0 couldn't open up files in 2 different directories. :-)
> >
> > >With all your (all those in this news group) experience in
> > >programming and encryption and aesthetics, it is I and not most of
> > >you with the ideas and the software products and the strategy and
> > >the GOOD will to get these fully functional products out to the
> > >public.
> >
> > You can't read. Others have already written this utility
and
> > made it available to the public. I mean, even the source
code.
> >
> > And it's such a dinky little utility too. Who's going to
download
> > hundreds of kilobytes of executable code to perform a
simple XOR?
> >
> > Could someone please submit Mr. Szopa's executable to
bloatbusters?
> > It's not like 7MB large, but it is huge for its intended
purpose.
> > And the fact that, somehow, the first version couldn't open
files
> > in separate directories (despite all the functionality
available
> > in file open dialogs) really makes it funny.
> >
> > -S
>
> Am I doing things just so you can rant and rave and waste all your
> time?
Well I am sorry but an "xor utility" is not particularly usefull.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: CHALLENGE TO cryptanalysts
Date: Wed, 08 Nov 2000 23:26:03 GMT
In article <TVhO5.4825$[EMAIL PROTECTED]>,
"Melinda Harris" <[EMAIL PROTECTED]> wrote:
> The notorious Crypto-Eccentric is preparing to issue a challenge on
January
> 1st 2001 to cryptanalyst and hackers alike including all government
agencies
> to crack his braintwisting ANEC code. It is to support his claim of
having a
> statistically crack-proof encryption scheme. Participants may
download the
> encrypted text embodying ANEC cryptographic algorithms and employ any
tools,
> or methodologies they can, to attempt to decrypt the message. There
will be
> no-holds barred hacking rules to illustrate the confidence in the
strength
> of A.N.E.C. The message will be sealed in an envelope and stored in an
> independent safety deposit box and revealed if deciphered prior to its
> twelve month deadline. If the twelve month deadline expires and
encrypted
> text is not deciphered it would certainly help validate his claim.
He will
> upload to a site where it is available worldwide.
> Please note: The self proclaimed crypto-eccentric does not conform to
the
> traditional practices, beliefs, or standards within the cryptography
> profession
> A.N.E.C techniques to produce chaos within the analytic process are as
> follows:
> Intricate hypercubes,hieroglyphic ciphers,triple cross cipher
transition,
> computational cipher base charts, coincidental cipher
repetitions,reversed
> standard alphabet,null ciphers,multi-algo transitions,Idiosyncratic
inverse
> ciphers,multi-transpositional cipher base charts,equivalent primary
> component alternatives/anec cifax,kanji ciphers,ideogram
ciphers,matrix
> technique, manipulation of constant movement and shifting strategy,
> stay tuned....
> questions email
> [EMAIL PROTECTED]
I am unaware of any of those "methods" as being secure.
What is ANEC suppose todo?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [newbie] Is PGP 7.0 hash extension secure?
Date: 08 Nov 2000 15:43:40 -0800
Zero-Knowledge MIME Encapsulated Message
--OY3XGXZLKBJSMI6J4G6N6RB6W9O5WHXLPS70F2T
Content-Type: text/plain
[EMAIL PROTECTED] (David Wagner) writes:
> >Recall that we are doing Hash(Key) || Hash('0'||Key), where || means
> >concatenation. SHA-1 will give you roughly 2^160 different outputs
> >for Hash(Key) as you run thorugh the 2^256 possible inputs. However
> >the second term, Hash('0'||Key), will also give you 2^160 outputs, and
> >these will be uncorrelatable to the outputs from the first hash.
>
> Note that the last statement is an unproven assumption, and there are
> reasons to be skeptical that you will ever get much more than a 160-bit
> security level from these types of constructions. That doesn't mean
> that the above is broken or an unreasonable implementation---if it only
> provides 160 bits, rather than 256 bits, of strength, there is probably
> no harm done---but don't assume you get something for nothing here.
It's not clear what "strength" or "security level" means in this
context. All we ask is that if you hash a buffer with 256 bits of
entropy, you will get output with that much entropy. This is a much
weaker condition to meet than in many other applications of hash
functions.
As fror the "unproven assumption", the statement was that you could
not feasibly correlate Hash('0'||Key) with Hash(Key). It is true that
this is not proven with regard to SHA-1, but then, any statement about
the strength of SHA-1 is an unproven assmption.
Consider a weak WHash which is the left 10 bits of SHA-1. WHash has
10 bits (or maybe 5 bits) of strength. Now concatenate
Whash('0'||Key) || Whash('1'||Key) || ... || Whash('F'||Key) to get a
160 bit hash. Would we say that the resulting construction can have
only 5 or 10 bits of strength, because the constituent pieces do?
Also, as far as internal chaining variables, the SHA-1 transform takes
a 160 bit chaining variable and a 512 bit input buffer. In the
example above (where our goal was to preserve 256 bits of entropy from
the input into the output) we might well be giving it less than 512
bits of input. In that case there will be no chaining and the size of
the chaining variable is irrelevant. Therefore this size cannot be of
central relevance in evaluating the strength of the construction.
Ob
--OY3XGXZLKBJSMI6J4G6N6RB6W9O5WHXLPS70F2T--
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: A question about RSA
Date: Wed, 08 Nov 2000 23:45:16 GMT
Simon Johnson wrote:
>
> In article <[EMAIL PROTECTED]>,
> Chenghuai Lu <[EMAIL PROTECTED]> wrote:
> > Suppose we know n (= p * q), which is a multiple of two large primes,
> > and phi(n) where phi(x) is the Euler function. Can anybody give the
> > algorithm to find p and q in polynomial time?
> oooh, u can't without solving P=NP.... for which there is a million
> dollars going.
Not so on two counts. First, given n and phi(n), determining p and q is
straightforward. Second, factoring has not been proven to be
NP-complete; this means that if there is a polynomial time factoring
algorithm, it doesn't mean that P = NP, or in other words it wouldn't
lead to a polynomial-time algorithm for all problems in NP.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 23:53:44 GMT
> > Ummm, no. That will apparently happen within a single program, but
if
> > you would try an small experiment, and run a small program that
reads
> > from and writes to the hard drive continually, and a seperate
> > interactive program, you will see that this is simply not the case.
>
> Nonsense, it _is_ the case.
Then obviously we're using different caliber of hardware. I am using a
modern setup with DMA controllers. That means quite simply that the
processor can go and do it's own thing while the, in this case, hard
disk controller reads from memory without affecting the speed of the
CPU. The disk will not affect the speed of the program executing.
>
> > The
> > program that reads/writes will be forced to wait for the hard drive
but
> > only because the operating system offers a syncronous view of the
> > system, the second application will not see the system the same way,
> > the second program will see a system without the disk delay.
>
> Nonsense again. The other program will sometimes be interrupted for
> disk I/O and sometimes not be, depending upon exactly when the disk
I/O
> completes. When the disk I/O completes, not only will the TSC be
> advanced by the time to do the I/O but the code will run slower due to
> the caches being blown out by the disk I/O code.
They will only be interrupted when an active I/O write occurs, and that
is just the writing to memory for the DMA controller to take care of
the issue. So when does the disk controller ever deal with the cpu? for
a few bus cycles, when the cpu sends a signal to the controller with
information on what to transfer where.
>
> > What you
> > are perceiving as CPU delay is only an artifact of performing the
> > measurements on a synchronous appearing system, using the same
process.
> > If you seperate them, you will notice that the read/write overhead
is
> > very, very small, and will not give you anything even remotely like
> > good randomness.
>
> *sigh* Again, you make no sense. We aren't after "good" randomness. We
> are just after sufficient randomness. A thousand bits where one in a
> hundred of them is a '1' is a good entropy source if properly fed
> through a cryptographically strong hash function.
No, it is a source of distillable randomness, for which a perfect hash
function will work very well. A cryptographic hash function does not
necessarily have this behavior, a cryptographic hash functions main
property is that given the hash, you cannot determine a value that
generates that hash. A cryptographic hash also leaks, compared to a
perfect distillation function, in that as was also pointed out in this
thread, a 160-bit hash function does not offer a full 160-bits of
distillation room, it offers some lesser space.
> Right, this will give you some randomness for precisely the reason I
> said it would, which is that some things a computer does are
> unpredictable, such as disk I/o.
Disk I/O is one of the most predictable. For the disk I/O you are
taking a few megabits/second measuring the time it takes to 1/66.667
millionth of a second, and you are calling it random, after that has
again been sampled at 100 MHz, (again at 200 MHz) and again at 500 MHz.
Remembering that these are all within tolerances of the ideal value,
you will get apparently random information, but no more so that having
a user tap a button, that button signal is sampled, the sample sampled
and the sample sample sampled, and compared in timing to the original.
In fact it's the same thing, you are claiming that there is randomness
involved here, I am telling you that where there is randomness it is
not from when the user presses the button, it is from the oscillators
in the middle.
> Did you need read the thread? Or not understand it? Or what? Of
> _course_ it fails DIEHARD, it's not unbiased. That doesn't mean it's
not
> random!
Perhaps you need to read more carefully, the values I tested were
distilled over the course of 3 days, not the few moments you seem to
believe they were. This was not a test to see if the quick result was
random, this was a test to see if there was enough randomness involved
at all to do much of anything. Since I distilled over 3 days, and still
repeatedly failed DIEHARD, it's a safe bet that this is far too slow to
even count as marginal entropy.
>
> > > > Many workstations don't have hard-drives of thier own. The
network
> > > > traffic is very easy to monitor. It can often be done from
outside
> > of the
> > > > building. Tempest certainly works if the cables aren't shielded.
> > >
> > > Monitoring the network traffic doesn't do you any good because you
> > > don't know the exact instant the network card on the client
machine
> > will
> > > notice the traffic. Knowing when it's put on the wire won't tell
you
> > the
> > > billionth of a second that it will be noticed by the CPU.
> >
> > Neither will the system clock. When the data reaches and is
detected by
> > the NIC, that data then gets processed for the PCI bus, which runs
at
> > either 33 MHz or 66 MHz, you will lose all entropy from precision,
and
> > god forbid it should be an ISA card, that transfer is < 10 MHz if I
> > remember correctly.
>
> A precision of 66Mhz would allow one-66th of a part per million to be
> detectable in a second.
And comparing that to your "billionth of a second" that's a not very
useful number is it?
>
> > Most use PCI, that is either
> > 33 or 66 MHz, then it will hit the system bus, where it will be
either
> > 66, 100, 133, or 150 MHZ, and will likely be forced to the common
> > granularity. After this it gets put in the CPU cache (again with
> > granularity loss), then it is read by the CPU (again with
granularity
> > loss, this time by forcing it to match the CPU clock).
>
> Please explain to me how measuring something clocked at 66Mhz by a
> 500Mhz clocks results in a granluarity loss.
Because it is 66.667 MHZ, being sampled by 500.000 MHZ, they will very
rarely coincide, making the sampling rate artificially drop. We don't
notice it normally because the synchronicity that forcibly becomes
involved at taking 10MHz, 100MHz, or 1GHz, forcing it to 66.667 MHz,
and referring that to 150.000 MHz, sampling that at 500 MHz, is very
destructive for the exact timing. Going from 10 to 66.667 MHZ means
that only 1/66667 clocks will coincide, all others must be delayed.
Going to the next level, leaving the PCI bus, only 1/150000 will
coincide, all others must wait. Sampling that again at 500 MHz, 4/5
must wait, again losing granularity on your measurements. I haven't
even begun to count the cache delays, the resistance of the wires,
clock variance, etc, which will make it increasingly difficult to get
an accurate measurement. Now, how exact did you want to make this
measurement?
>
> > If the system
> > has an EV6 bus (or another advanced bus protocol) you can add at
least
> > one more granularity killer into that, all before you can measure
it.
>
> These are not granularity killers at all. Going from a slower clock to
> a bus at a faster clock loses nothing.
Only if they are perfect multiples, going from 200 MHz, to 950 MHz, you
will lose because some signals will be delayed.
>
> > Computers are designed to eliminate all the randomness in their
> > behavior that is possible, pretending it is another way does not
change
> > anything.
>
> That's a nonsensical claim.
So it doesn't make sense to you that designing something that will fail
randomly, randomly read the wrong location (or right one for that
matter), generate random timing is better than designing something
where the exact behavior at each instant is known? Somehow I hope they
don't think like you, otherwise all the answers that modern chips give
on arithmetic would make FDIV look miniscule.
>
> > > They may synchronize their I/O clock to the system bus, but I
doubt
> > > they could synchronize other clocks. That would require that the
> > > frequencies line up. If they do synchronize their CPU to the bus
> > > clock,
> > > however, that would significantly reduce (in theory) the amount of
> > > entropy available from disk reads.
> >
> > They all syncronize to some degree, the better the drive the more
> > syncronous it's going to be.
>
> Actually, the reverse seems to be true. The more sophisticated drives
> are more likely to have independently clocked agents, such as a cache
> management processor. Cheap IDE drives, however, seem to be fully
> synchronous to the bus clock. Nevertheless, there's entropy in the
> variation in the rotational speed of the disk as measured by that
clock.
> However, how much entropy is there seems to be in dispute.
Again the claim that the better/more expensive it is, the worse it's
made?
>
> > Unfortunately taking the clock drift
> > between the HD cycle and the system cycle won't generate entropy, it
> > will only express the entropy of another influence, most likely
> > temperature, which is now very carefully controlled on virtually all
> > systems. That is not to say that there isn't any entropy available
> > there, just that you'll have to work very hard to get enough of it
to
> > be useful.
>
> The temperature is not carefully controlled enough to restrict
> oscillator drift. It still drifts by a few parts per billion, which is
> enough to be measured. If you can take active steps to measure it, you
> can grab about 4 good bits of entropy per second.
You can only measure it with the assuredness of the closest clock
split, and in modern systems there are a fairly large number of them.
You may be able to gather entropy using timings in these systems, but
the amount of it is going to be astronomically small.
I am however enjoying the conversation, it is making me think.
Joe
>
> DS
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "NoLimitB" <[EMAIL PROTECTED]>
Subject: Regarding assymetric encryption algorithms
Date: Thu, 09 Nov 2000 00:08:57 GMT
Hi,
I am not very familiar with encryption beyond a basic understanding of
methods, algorithms, and terminology. I am seeking a solid assymetric
encryption algorithm for the purpose of encoding small amounts of
information ( generally less than 512, but sometimes up to 1024 octets ).
The only necessity is a VERY high level of security. An established
algorithm that has been attacked many times and has left the data
sufficiently encrypted. Least important is speed, beyond that of a
reasonable level. By reasonable, 15 minutes max time allowed for encrypting
512 octets by means of around 500MHz Pentium class computer is desirable.
Of course, I understand that it's difficult to come up with something that
is so specific, but as I said, that is the least important criteria. Ease
of implementation would also be desirable, but hey, I know you can't have
everything!
Thanks for taking the time to read and answer this question.
[B.R]
------------------------------
** 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
******************************
