Cryptography-Digest Digest #459, Volume #12 Wed, 16 Aug 00 11:13:00 EDT
Contents:
Re: 215 Hz five-qubit quantum processor (Andy Newman)
Re: Looking for a DES or RSA chip with write-only key. (Bob Silverman)
Re: Secure Operating Systems (Mack)
Re: Unauthorized Cancel Messages (Ron B.)
Re: Big Brother Is Reading Your E-Mail ([EMAIL PROTECTED])
about Openssl (haifeng)
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: Not really random numbers (James Felling)
Re: test (Future Beacon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Andy Newman)
Crossposted-To: comp.arch
Subject: Re: 215 Hz five-qubit quantum processor
Reply-To: [EMAIL PROTECTED]
Date: Wed, 16 Aug 2000 13:21:24 GMT
Jamie wrote:
>Isn't MS Windows a simulation of a quantum machine?
>You can never tell which application the "operating system" is going to
>crash until you try to use it.
They well may be using such techniques. Do not under estimate
the capabilities of this giant among giants (ahem).
For years we've maligned Bill Gates and Co (capital intended) for
poor s/w but we all mis-understood Microsoft's grand plan. It all
suddenly became clear the other day - in the bathroom or somewhere
like that, the place such grand plans always become clear...
Microsoft's software has been all about proving there is an efficient
solution to the halting problem!
Think about it. All the broken architecure, the backdoors and
security holes, the fundamental mistakes. These are all subtle
(or not so subtle) methods of allowing programs to halt more
quickly than their original authors intended. If you just let
the programs receive their normal inputs they could do anything,
they might not even stop! By adding in new ways of halting programs
the solution space is reduced and all those stuffy comp.sci Unix
lovers can go and cry on their PDP-11s. At first MS had some neat
solutions to the problem but they'd marketed them at the techies
on little machines that did enough halting of their own. As the
programs got "better" they halted less often and this larger market
was needed to solve once and for all that all programs can halt within
reasonable time. The IBM thing happened. They had Xenix but knew its
architecture would allow programs to run unhindered by other programs.
A single address space without protection was needed and a CP/M clone
was available. Great. All sorts of mis-features and hacks (TSRs) helped
make programs halt. They had a sure fire solution in Windows 95 until
the press found out. Imagine being able to prove that any program
whatsoever will halt in just 47.9 days. Even so-called infinite loops!
The Unix nerds are really going to have to re-think things! Do that in
your shell and smoke it hippie Linux commies. See the type of
fundamental research MS are capable of. Then we made them remove it.
It was really a sort of cheating anyway. The installers and DLL sharing
debacle are a good way to get some cross-program interactions that
can help them halt more quickly but the ActiveX-borne programs are
a far more subtle solution to the problem. With the connectivity
afforded by the Internet and the ability to execute arbitrary code
on client computers it is now possible to halt programs on millions
of computers simultaneously, all from your own chair. That's empowerment.
But again the press an so-called "technical professionals" (who obviously
haven't got a clue about pure research such as this, bloody "engineers")
force MS to take out these solutions to the problem. Now they're forced
to even more complex schemes to have programs halt in a reasonable
amount of time. Embedding programs within spreadsheets within word
processor files within web pages within mail messages that are stored
on a network server accessed using NetBIOS atop TCP/IP over RSA is
almost as much code as the flight simulator in the about box.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Looking for a DES or RSA chip with write-only key.
Date: Wed, 16 Aug 2000 13:26:23 GMT
In article <[EMAIL PROTECTED]>,
ronb.cc@usu@edu (Sniggerfardimungus) wrote:
> I'm looking for a DES or RSA chip with one unique quality - I want to
be able
> to burn the key into the thing and have it permanant and non-
readable... in
> some physical fashion, the key on the chip needs to be inaccessible.
This reminds me of the newest and fastest supercomputer.
It was built by <substitute your favorite ethnic stereotype>.
It has write-only memory.....
--
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/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 16 Aug 2000 13:40:15 GMT
Subject: Re: Secure Operating Systems
>
>Mack wrote:
>>
>>>I keep hearing rumors of a secure version of QNX that they don't want
>>>advertised...
>>
>>If there is it will be in the NSA approved
>>security products catalog. They list other
>>highly secure products as well.
>
>Are you saying that the NSA publishes a catalog of everything they
>have? I doubt it. I rather suspect that the catalog has a subset.
>
>
>
The catalog is for all vendors and buyers of secure products
for government use. The list of acceptable products for
use in military applications (and contract work). They generally
don't give a very good description of the product. Just a name
and classification type stuff.
I am sure the NSA has some products not listed, like crypto
breaking machines. Anything they wouldn't publish would
fall in the category of we don't even want anyone else in the
government to know.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Ron B. <[EMAIL PROTECTED]>
Subject: Re: Unauthorized Cancel Messages
Date: Wed, 16 Aug 2000 13:58:42 GMT
On 16 Aug 2000 11:34:06 GMT, [EMAIL PROTECTED] (Guy Macon) wrote:
>Ron B. wrote:
>>
>>On Tue, 15 Aug 2000 13:48:54 GMT, Ron B. <[EMAIL PROTECTED]> wrote:
>>
>>>It appears to me that someone is sending bogus cancel messages to
>>>sci.crypt and the alt.security.* groups. My newsreader shows
>>>several "This message is no longer available" messages for several
>>>legitimate messages. This are clearly not anti-spam cancels as they
>>>are new
>>>responses to postings. Has anyone else seen this?
>>
>>I've contacted support at gte.net. It was a problem with the local
>>server for my area.
>>
>
>I have a suggestion. It would have been better to describe the problem
>that you are seeing and to raise the question of whether cancels are
>the cause rather than assuming that you know the cause of the problem.
Yes, you are right. However, I did contact support and discover that my
"assumption" was wrong. I then notified the group of my error (see posting
you quoted).
>
>BTW, my news server/news reader combination is set to show me every byte
>of every article and to ignore control messages, so when someone cancels
>am article, I see the original and the cancel. All I have seen is the
>usual amount of self-cancels followed by slightly edited versions, and
>the usual spam and spam cancels from the usual sources.
Thank you. That is a relief.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.privacy,alt.security.pgp
Subject: Re: Big Brother Is Reading Your E-Mail
Date: Wed, 16 Aug 2000 14:02:02 GMT
In article <[EMAIL PROTECTED]>,
Michael Brown <[EMAIL PROTECTED]> wrote:
> > I think your method is more alchemy then science, since I can't
> > read XL files I can't see your method.
> Fine. What format do you want it in?
How about PostScript or PDF format?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: haifeng <[EMAIL PROTECTED]>
Subject: about Openssl
Date: Wed, 16 Aug 2000 17:13:34 +0300
Hello,
need help.
Who knews Openssl0.9.x? And
May I use it to get "CA"? May I use it to do "Certificate Validation"?
How do it?
Thanks.
HF:)
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Wed, 16 Aug 2000 20:47:14 -0600
Reply-To: [EMAIL PROTECTED]
Tim Tyler wrote:
> Mark T. VandeWettering <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> :>Any process that appears random may be the deterministic outcome of events
> :>at a lower level. The rational scientist can't currently say one way or
> :>the other about whether there is determinism in physics - he plain doesn't
> :>know.
>
> : Quantum mechanics addresses this issue. It disagrees with you. Please
> : post your refutation of quantum mechanics [...]
>
> Quantum mechanics does not address the issue - to do so it would have to
> claim to be a final theory of physics - something which - AFAIK - no
> living physicist would claim for it.
>
> *If* Heisenberg's uncertainty priciple were the last word ever spoken on
> the matter it might be reasonable to conclude that it's not possible to
> gain enough information about the state of the universe to predict it.
>
> However, as things stand there's still plenty of scope for discovering
> more physics which underpins it.
>
> People might have thought that Brownian motion was random before the
> kinetic theory of gasses offered a more detailed explanation. It may
> well be similar with quantum theory.
>
> Certain types of determinism have been experimentally revealed to be
> very unlikely - but not all such theories can be rejected at present.
>
> I don't "disagree" with quantum mechanics - unless it is presented as the
> final theory of the universe - which it is /extremely/ unlikely to be.
QM may not be the final theory of the universe, but other theories will have to
explain the results of QM. Just like QM does explain Newtonian mechanics as a
limiting case.
The randomness in QM is different from the randomness we assign to dice
throwing. Whether a coin comes up heads or tails or a die shows a 1 or 2 can be
computed in principle from inital conditions and the laws of motion. It turns
out that averaging over initial conditions gives a uniform distribution on the
outcomes. QM is different. Whether an atom decays at a certain time is a random
event, there are no initial conditions to average over.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Not really random numbers
Date: Wed, 16 Aug 2000 10:04:30 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > > <snip>
> >
> > >
> > > >
> > > > I must state this. Files of this nature can be manufactured by other PRNG's.
>They
> > > > will be manufactured as quickly if not more so, and as securely, if not more
>so. May I
> > > > suggest an apropriately tweaked RC4, or BBS for your use. The issue is it
>will take ~1
> > > > hour of operator time to start generating good data with your mechanism, and
>it will
> > > > also take more than a bit of time after that to actually generate the numbers.
> OTOH,
> > > > it will take 1 minute to setup a good RC4 generator, and it will have
>generated a
> > > > reasonable quantity of data( equivalent to your files) in under a half hour.(
>I think
> > > > the fact that it takes less of MY time, and is done before OAP/OAR gets
>started is a
> > > > HUGE advantage.) BBS is slower, but substantially more secure. It will
>probably take
> > > > 5 minutes of my time to setup, and generate an amount of data sulficient to be
>useful
> > > > in several hours. This is speed wise compeditive with your system, and is
>going to be
> > > > more secure than your system in general.
> > > >
> > > > >
> > > > >
> >
> > > <snip>
> >
> > >
> > > > RC4, BBS, and all others when saved to files encrypt just as fast as your
>method -- The
> > > > issue for the user is forufold
> > > >
> > > > 1) how much of my( the user) time do I wish to invest. (ideally as little as
>possible)
> > > >
> > > > 2)how much computer time do I wish to invest (ideally as little as possible)
> > > >
> > > > 3) how much space on my machine/ the remote machine do I want to use for this,
>(
> > > > ideally as little as posssible)
> > > >
> > > > 4) How long is key data going to be lurking in an available form in my/remote
>PC. (
> > > > ideally for as short a period as possible)
> > > >
> > > > versus RC4 you lose on all 4 points.
> > > > versus BBS you lose on points 1,3,4 and cannot deliver security with an
>equivalent
> > > > degree of confidence.
> > > >
> > > > You have a second rate stream cypher -- it is slower than most BLOCK
>algroithims. I
> > > > admit that using large "random files" will give a speed enhancement, but they
>add
> > > > secondary points of attack to your algorithim, and any other stream cypher,
>and most
> > > > block cyphers can do the same trick faster.
> > >
> > > I think your confidence level is not warranted.
> > >
> > > "is going to be more secure than your system in general." This is
> > > clearly over reaching.
> >
> > Does your system have a mathematic proof which indicates that a break of the
>system is
> > equivalent to the solution of the QRP problem? Or tying a its dificulty of
>breaking to the
> > same? If so then feel free to attack BBS, but for well chosen values BBS has a
>known minimum
> > level of security, and cannot have "bad keys". Your system can have bad keys, and
>has no
> > minimum guaranteed security level. I feel that this results in a system " more
>secure in
> > general" than yours.
> >
> > >
> > >
> > > "1) how much of my( the user) time do I wish to invest. " This is
> > > certainly a (modest) concern. It is answered by asking yourself how
> > > much more secure is OAP-L3 than other methods.
> >
> > It is no more secure than any other PRNG. It is less secure than BBS( in general)
>and can
> > probably compare to RC4 with a sulficient investment of operator time. OTOH RC4 is
>faster,
> > takes less effort to setup properly, and is simpler to use for equivalent quality
>random
> > numbers.
> >
> > > As you should know,
> > > OAP-L3 uses no mathematical equations in generating random numbers.
> >
> > Really?
> >
> > >
> > > There is no modulo operation, for instance.
> >
> > None by that name -- but you do out put your numbers with discarded values( I
>believe any
> > value of 3*255 or higher is discarded in post processing when you are combining
>the three
> > streams -- if that is not mudulo truncation what is it?
> >
> > > In other words, there
> > > are no inherent constraints in the random number generation process.
> >
> > Please define "constraints" -- I think you constrain your generator in any number
>of ways --
> >
> > >
> > > With no constraints there is no way to trivialize cracking the
> > > random number generator.
> >
> > There are no such known ways of using such versus any other crypto grade PRNG
> >
> > > This may make the additional time worth
> > > it. Besides, the time need be invested only once since you will be
> > > able to generate more random numbers than you could ever possibly
> > > need with very very little additional effort.
> > >
> > > "2)how much computer time do I wish to invest?" This point also
> > > addresses the limited cost of using OAP-L3. You cannot simply look
> > > at cost. As above you must look at what you are getting for your
> > > cost. See below.
> > >
> > > "3) how much space on my machine/ the remote machine do I want to use
> > > for this,..." This is a valid cost concern. See below.
> > >
> > > "4) How long is key data going to be lurking in an available form in
> > > my/remote PC." This is valid security concern.
> > >
> > > Here is my response to the remaining concerns:
> > >
> > > You may be aware that OAP-L3 Version 4.1 / 4.2 is the original
> > > implementation of the theory / concept. This implementation has
> > > the cost concerns that you have a legitimate reason to point out.
> > > And you may not be willing to incur these costs.
> > >
> > > My proposed implementation for Version 5.0 is available at
> > > http://www.ciphile.com from the What's Ahead web page.
> > >
> > > Version 5.0 is explained in detail in the files available for
> > > download by clicking the blue anchors located at the bottom of
> > > this page: Version 5.0 Tables file and the associated Version
> > > 5.0 Text file.
> > >
> > > Version 5.0 will not require you to generate random number files
> > > beforehand. Permanent hard drive space will not be required because
> > > the key / encryption data will be kept on floppy. This pretty much
> > > dispels #2, #3, & #4.
> > >
> > > I addressed #1 initially, above.
> > >
> > > Depending on which variation of version 5.0 one uses, the
> > > encryption time will vary.
> > >
> > > Here is a brief description. Full details by clicking the blue
> > > anchors at the bottom of the What's Ahead web page.
> > >
> > > ("E" notation means that a number expressed as 5E6 = 5 x 10^6 or
> > > 5,000,000.)
> > >
> > > With only 2920 data bytes you will be able to generate 9.2E15 random
> > > numbers from 0 - 255 with a security level equivalent to 2000 bits;
> >
> > RC4 with a combiner
> >
> > with only 300 data bytes get security equivalent to 2000+ bits
> >
> > >
> >
> > >
> > >
> > > or with only 4600 data bytes you will be able to generate 2.3E17
> > > random numbers from 0 - 255 with a security level equivalent to
> > > 10,000 bits;
> >
> > RC4 with a combiner
> >
> > with only 2000 data bytes get security greater than 10000 bits
> >
> > >
> > >
> > > or with only 1,271,000 data bytes (fits on one floppy) you will be
> > > able to generate 1.3E36 random numbers from 0 - 255 with a security
> > > level equivalent to 100,000 bits.
> >
> > Imagine typing in 1271000 random characters. Sound fun to you. It sure does not
>sound fun to
> > me.
> >
> > RC4 with a combiner
> >
> > with only 20000 bytes of data get security superior to 100000 bits.
> >
> > >
> > >
> > > The Version 5.0 Tables file and the associated Version 5.0 Text file
> > > describe how this is done.
> > >
> > > You don't need to keep the key / encryption data on your computer.
> > > Keep it on a floppy disk.
> >
> > Get the floppy stolen and copied. You still have a single point of failure which
>compromises
> > the whole system, and which cannot easily be rekeyed.
> >
> > > Insert it when needed then remove.
> > >
> > > Thanks for your consideration.
> >
> > You just don't get it. your method is less effective, more difficult, and slower
>than other
> > public domain methods. Why should it be used?
>
> I said you are over reaching. What do you mean by less effective and
> support why OAP-L3 is less effective?
Less effective is fairly easily defined: Given a specific quantity of input key, how
random is the
output ( your method thends to need more keying data to achive a given level of
entropy than many
others).
Annother definition of effective that is useful to examine is how many "weak keys"
exist in a given
method. Your method possesses numerous weak keys -- if the user selects poorly, he may
get very
poor random numbers from your system, BBS or RC4 if properly implemented will always
give a stream
of numbers of known minimum quality.
A third useful form of effectiveness that you have issues with is key agility.
Assuming that you
learn that your key is compromised, but also need send data ASAP. To set your system
up( properly)
will take a highly skilled operator on a fast PC a half hour, while RC4 can be
swithched keys and
transmiting on an alternate key in less than a minute( assuming an equally skilled
operator), and
BBS in less than 5 minutes. Maybe your data isn't that urgent, but if it is which
delay will be
more acceptable.
A fourth form of effectiveness that your system needs work on is operator time
consumption -- as an
employer would you rather have your employee spend 30 minutes focused on a rekey every
keying cycle
or would you rather have them focused for 1 to 2 minutes, and available for the extra
20 odd
minutes to perform other tasks?
> Are you saying it is less
> secure.
Yes. Where is your proof of security? Who other than yourself will speak up in favor
of your
claims?
> I say OAP-L3 is more secure because there are no inherent
> constraints in the random number generation process and therefore no
> constraints can be exploited to trivialize the cracking of the random
> number process.
What does "no inherent constraints" mean in this context. In what way are BBS or RC4
"constrained"
or "restricted" in their output? How do their inherent properties constrain the values
that they
output in any real sense? How can this be used to "trivialize" the cracking of those
methods?
>
> You cannot just say "less effective" in a vacuum. You must state
> the proposed use for the software. What application did you have in
> mind? Encrypting email messages?
I might use it for encrypting e-mail messages if I felt particularly massocistic. It
could be used
for person to person traffic if they were willing to invest the effort. But for that
aplication, I
would rather use RC4 -- it is faster and easier to use.
>
>
>
> I claim that the military could use OAP-L3 effectively. For
> instance, the U.S. Navy could use it to encrypt communications to
> the entire fleet.
(data only? or data+voice?)
> How many megabytes / gigabytes of data do you
> suppose the entire Navy transmits to its fleet each day?
Alot of data. Given a desire not to have a compromised key the navy would need at
least one
fulltime key generator to keep everyone in keys using your system, or they would need
one person
for an hour each week generating RC4 keys , and available the remainder of the week --
which should
they prefer?
>
>
> OAP-L3 is simple.
Not for the amateur user( unless substantial upgrades to the interface and
documentantion have been
made in the past month)
> And the security benefits outweigh your other
> concerns which are of greatest concern in this first implementation.
> They come down to generating the OTP files beforehand and storing
> them. These concerns are easily dealt with.
Please let me know what measures have been taken to address my concerns in re
performance?
>
>
> And just because you cannot imagine using OAP-L3 effectively does
> not mean that it cannot be done.
Of course it can be used securely. Of course it CAN do the job. But I if can pound
nails with a
jagged piece of rusty steel, does that make a jagged piece of rusty steel the ideal
tool for that
job? No. The same goes for OAP/OAR.It can do the job, but it is a poor tool for that
purpose.
> You will admit you have no
> interest in solving your issues with OAP-L3.
Just as I would have no interest in repairing a car that has gone through a crusher --
the return
on investment isn't worth it. But as a customer, it is NOT my job to fix OAP-L3, it is
your job to
resolve customer issues. If I buy a program with an unusable interface is it my job
to fix that?
Or if it cannot meet the marketing claims made for it must I fix it?
> So since you have
> not thought about how to solve these issues for yourself, why should
> anyone listen to you: someone who chooses not to think
> yet make cursory superficial claims which I say again are easily
> dealt with?
>
Given that I have discussed these issues with you in the past, and further that I have
examined
your program in deatil and the mechanisms with which it attempts to provide security,
and that I
have seen other programs in action doing the same thing as well if not better than
your product,
where have I not been diligent? Have you addressed any of my claims in anything other
than a
superficial manner?
>
> Why don't you just say you want to trash OAP-L3 and don't care to
> support your position other than to give vague and general
> statements with no specific situations.
I see only that you respond to rational arguments with diversions and half truths.
>
>
> Give us your biggest objection to OAP-L3 with a proposed use where
> it would not be effective or where it would be less effective?
Sure -- e-mail. Compare it to PGP. It costs more, offers security that is at best
equivalent, is
more easily compromised, is harder to use, harder to change keys with, has been
subject to
substantially less analisys, is slower, offers fewer features, and offers less
technical support
for the begining user. Certianly it COULD be used for that aplication, but PGP has it
beat.
Or alternatively secure web transactions-- compare it to RC4 as a SSL cypher.
Or for securing local files -- comapre it to a block cypher or RC4 with a memorizable
key.
> And
> how many people need this capability?
I am not certian -- I'd say most of us who use crypto.
>
>
> Perhaps Internet backbone service providers who wish to encrypt and
> transmit terabytes of data per hour might find OAP-L3 unacceptable.
Most certianly.
>
> But how many users need to encrypt and transmit terabytes or even
> gigabytes each hour through one server or portal?
Not many.
>
>
> I say again, you are overreaching to maintain your mostly untenable
> and insupportable position.
Ditto.
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Crossposted-To: sci.physics
Subject: Re: test
Date: Wed, 16 Aug 2000 11:03:11 -0400
I may be an idiot, by my problem was with only two news groups -
this one and sci.math. There was never any problem with the test
groups, including eznet.test.
I suppose being unkind can be worth the occasional mistake.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
On Wed, 16 Aug 2000, Uncle Al wrote:
> Future Beacon wrote:
> >
> > Last test didn't work
>
> Idiot. news:alt.test
>
> --
> Uncle Al
> http://www.mazepath.com/uncleal/
> http://www.ultra.net.au/~wisby/uncleal/
> http://www.guyy.demon.co.uk/uncleal/
> (Toxic URLs! Unsafe for children and most mammals)
> "Quis custodiet ipsos custodes?" The Net!
>
------------------------------
** 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
******************************
