Cryptography-Digest Digest #83, Volume #11 Wed, 9 Feb 00 18:13:01 EST
Contents:
Re: Actually you can see me here .. with your RealPlayer ... ("Nick")
Re: new standart for encryption software... ("finecrypt")
Re: New standart for encryption software. (David Wagner)
addition chains, implementation? (Anton Stiglic)
Re: Anybody know about this flaw? (ChenNelson)
Re: Guaranteed Public Key Exchanges (Vernon Schryver)
Re: Anti-crack (Vernon Schryver)
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: Seeking Information on FRACTAL CRYPTOGRAPHY ("Douglas A. Gwyn")
Re: Seeking Information on FRACTAL CRYPTOGRAPHY ("Douglas A. Gwyn")
Re: NIST, AES at RSA conference (Bryan Olson)
Re: Message to SCOTT19U.ZIP_GUY ("Douglas A. Gwyn")
Re: Message to SCOTT19U.ZIP_GUY ("Douglas A. Gwyn")
Re: New standart for encryption software. (Eric Lee Green)
Re: new standart for encryption software... (Eric Lee Green)
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: Guaranteed Public Key Exchanges (Darren New)
Re: Re: How to password protect files on distribution CD ("John M. Dlugosz")
----------------------------------------------------------------------------
From: "Nick" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.israel
Subject: Re: Actually you can see me here .. with your RealPlayer ...
Date: Wed, 9 Feb 2000 16:16:26 -0500
How do you do "kill file"?
Mike Andrews <[EMAIL PROTECTED]> wrote in message
news:Onjo4.9413$[EMAIL PROTECTED]...
> In sci.crypt Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
>
> [nothing relevant to this group]
>
> How the Hell did you get out of my killfile? In you go!
>
> *PLONK* !
>
> --
> "Cutting the space budget really restores my faith in humanity. It
> eliminates dreams, goals, and ideals and lets us get straight to the
> business of hate, debauchery, and self-annihilation."
> -- Johnny Hart
>
------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Thu, 10 Feb 2000 00:06:09 +0300
Eric Lee Green wrote:
>Key generator. You keep ignoring those two words. I haven't seen your key
>generator.
Eric Lee Green,
You can read about how FineCrypt generates keys in program's online help.
http://www.finecrypt.com/fcinst.exe
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New standart for encryption software.
Date: 9 Feb 2000 13:41:04 -0800
In article <[EMAIL PROTECTED]>,
Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
> Although our source code is available for review under NDA, any
> INFOSEC professional knows that spiking cryptosystem implementations
> at the object code level is a much greater threat than "backdoors"
> spelled-out in well-documented source code.
But you seem to be overlooking that, even if we are willing to
trust you not to intentionally "spike" the system, we have no reason
to trust you to get all the details correct. The history of
cryptography shows over and over again that even the best of
intentions (or even the best of qualifications!) are no guarantee
against inadvertent mistakes. (And these mistakes are often very
subtle.)
This type of flawed reasoning has been the downfall of many
systems in the past. Why should we believe your system will fare
any better than others have?
> Hence, the emphasis on
> testing performance of the cryptosystem, rather than trusting pretty
> source code listings.
I'm not sure what you mean by "performance", but if you mean
"how fast it encrypts", it sure sounds like the classic mistake of
measuring the quantities you know how to measure instead of the
quantities that actually matter.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: addition chains, implementation?
Date: Wed, 09 Feb 2000 17:06:02 -0500
Is there an *implementation* of an algo that computes
an addition chain, heuristicaly, for big values (I'm interested
in 256 bit values). For example, J. Bos and M. Coster
had an algo (CRYPTO 89), is there any implementations
of this?
I'd need one in C or C++.
Thanks for any refs...
Anton
------------------------------
From: [EMAIL PROTECTED] (ChenNelson)
Subject: Re: Anybody know about this flaw?
Date: 09 Feb 2000 22:10:20 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Well, the fact that you're using PUBLIC keys means that interception
is useless to an attacker. The beauty of public key crypto. Deriving
the private key from the public key is VERY difficult, if not
impossible.
Later,
Nelson Chen
=====BEGIN PGP SIGNATURE=====
Version: PGP for Personal Privacy 5.5.2
Comment: For public key, go to key server with key ID 0xD28C0DD9
iQA/AwUBOKHmS21ACZTSjA3ZEQII9ACgkikzeyoKqR0zjOvjovNHX+W6c+kAoNZ2
Us9PdWEnfzWDzXFX9zQMfVlE
=VvwJ
=====END PGP SIGNATURE=====
==========================
To earn $0.05 per clickthrough from your web page, please go to
http://www.3wmart.com/ and sign up for our button banner program.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Guaranteed Public Key Exchanges
Date: 9 Feb 2000 14:57:50 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>...
>And people wishing to get key certificates have to prove their
>identity to the key certifying authority by some other means than
>E-mail.
Have you danced that dance? I started to do it with Thawte to for
an HTTPS server before deciding it was a waste of time, that running
my own rogue CA is plenty good enough for my purposes (which are
not my publicly visible stuff). Thawte seemed to want more than
email, but only a FAX and (I think) optionally a U.S.Postal Service
letter containing copies of a DBA or similar license.
I also looked at Verisign, and as I recall, they made signing up as easy.
A single FAX or letter nominally from you does not strike me as
much protection against a man in the middle. I suppose they might
send a postal letter to your `whois` or DBA address, but anyone
who can intercept your email will have not be impressed by the
difficulties of intercepting USPS mail in most cases.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Anti-crack
Date: 9 Feb 2000 14:45:23 -0700
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> ...
>Ouch. Sorry I suggested it. I didn't read it, usually everything in
>Embedded Systems is pretty good. Makes you wonder what they paid to
>advertise so they got the article on the cover.
I have no such doubts about their integrity. I think they needed inter-ad
filler and printed what they could get. The author of the piece might
not be an idiot. Maybe he spent the time and effort appropriate for
what he got out of the deal, or less than what I'll have spent on this
netnews article. Thanks to the various archives, this drivel of mine
might last longer and have wider circulation than his article. As I
read http://www.embedded.com/bpa.pdf, they seem to claim only about
50,000 subscribers. I haven't seen netnews arbitron numbers for many
years, but 50,000 readers for a group was small back then.
As I said before, "Embedded Systems" is not as consistently bad as some
of the other trade rags, but like all trade rags, its inter-ad filler
should be read only by people who know little and care less about the
subject or already have wider and deeper knowledge than any unrefereed
magaznine would want to try, but are curious about the current "buzz."
Consider the other current articles at http://www.embedded.com/2000/0002/.
"Embedding with GNU: The GNU Compiler and Linker" is great, if you don't
have or need more clues about gcc than Dilbert's boss. The article is a
nice screed to help convince the pointy-haired that buying Inprise's or
Microsoft's SDK is not the only alternative. If you need clues enough to
use or decide whether to use gcc, it would be smarter to look at the .info
files on the nearest NetBSD, FreeBSD, or Linux CDROM or FTP site.
"Data Memory Paging Management, Part 2" is also not bad for what it is,
but if you know anything about how paging in real systems for the last
35+ years (say after Atlas but starting with the SDS 940/U.C.Berkeley
Project Genie) or you need to write some embedded code that pages, you
will probably be disappointed.
It's insane to hope for substance in any trade rag except in the ads.
They cannot pay enough to people with clues to spend enough time to write
real papers. A reasonable article would take a good week to write. Can
you imagine them budgeting the approximately $10,000 that is the going
rate for a week's serious consulting work from someone with clues for each
of half a dozen articles in each issue?
The refereed journals can hope that their prestige and the academic
publish-or-perish regime will provide them content. However, even they
have troubles, as the flood of lame masters theses in the IEEE journals
and the years of toxic waste in the "Communications of the ACM" attest.
If you do want to write commercially and know something, the major
technical book publishers would love to hear from you. Not only will a
book produce much wider and more lasting fame than a trade rag piece, but
the publishers will pay you real money and see that your text is reviewed
by your peers. Unfortunately, you'll probably make a lot more after money
by sticking with your day job. I privately review a few book manuscripts,
spending 10X or more time than the small "honorarium" would buy at my
usual rate just for the change of pace, social consciousness, and ego
gratification. The editors are continually asking if I know anyone who
wants to write a book. Some of the manuscripts send me show they're
desperate and will seriously consider practically anything from anyone.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 17:19:47 -0500
Reply-To: [EMAIL PROTECTED]
On 9 Feb 2000 13:41:04 -0800, [EMAIL PROTECTED]
(David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
>> Although our source code is available for review under NDA, any
>> INFOSEC professional knows that spiking cryptosystem implementations
>> at the object code level is a much greater threat than "backdoors"
>> spelled-out in well-documented source code.
>
>But you seem to be overlooking that, even if we are willing to
>trust you not to intentionally "spike" the system, we have no reason
>to trust you to get all the details correct. The history of
>cryptography shows over and over again that even the best of
>intentions (or even the best of qualifications!) are no guarantee
>against inadvertent mistakes. (And these mistakes are often very
>subtle.)
>
>This type of flawed reasoning has been the downfall of many
>systems in the past. Why should we believe your system will fare
>any better than others have?
>
Mr. Wagner:
I'm having difficulty identifying what "flawed reasoning" it is of
which you think me/us guilty. ??
Are you saying that the source code we make available for review might
be fraudulently different from that which we compile in some newby
error manner, as opposed to being fraudulently different in an
intentional (spiking)
>> Hence, the emphasis on
>> testing performance of the cryptosystem, rather than trusting pretty
>> source code listings.
>
>I'm not sure what you mean by "performance", but if you mean
>"how fast it encrypts", it sure sounds like the classic mistake of
>measuring the quantities you know how to measure instead of the
>quantities that actually matter.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Seeking Information on FRACTAL CRYPTOGRAPHY
Date: Wed, 09 Feb 2000 22:30:07 GMT
John Savard wrote:
> The main reason for the bad rep is essentially that a function can be
> nonlinear without really scrambling its input thoroughly; that will be
> enough to obtain chaotic behavior without being enough to produce a
> cryptosecure pseudorandom generator.
Another, very serious, problem is that many if not most forms of
chaos actually exhibit regular patterns (considered at the
statistical level). The very concept of an attractor is that of
a strong pattern.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Seeking Information on FRACTAL CRYPTOGRAPHY
Date: Wed, 09 Feb 2000 22:38:10 GMT
Tim Tyler wrote:
> However there are few references to "chaos theory" - perhaps because
> this is widely considered the pop-science deviant offspring of
> nonlinear systems theory, run by those who exploited the mathematics
> by marketing its pretty pictures to the public.
Just because a subject has popular appeal doesn't mean it isn't
worthy of serious study. In fact, the theory of dynamical systems
has experienced rapid development in the past few decades, and its
characteristic ideas are quite different from classical nonlinear
systems theory. (Poincar� and Julia did in some ways anticipate
these "new" ideas, but the field as a whole didn't exploit their
insights for a long time.)
The main reason you don't hear much about chaotic cryptosystems
is that it is exceedingly hard to devise a good one.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Wed, 09 Feb 2000 22:29:56 GMT
Terry Ritter wrote:
>
> Paul Crowley wrote:
>
> >And here lies the crux of the argument. We haven't proven the
> >strength of our ciphers, and you haven't proven the strength of your
> >multiple encryption schemes. You're relying on just the reasoning
you
> >accuse us of.
>
> I dispute that. You have taken my words out of context and
> misrepresented my position; while the words are similar, their meaning
> is not.
You miss the point. The greatest misrepresentation of
positions has been your incessant ridicule of the
"unscientific" reasoning of others. Over and over you
lectured on how there is no mathematical proof of security
to an audience that did not claim there is.
>From the start we've been addressing the problem of
achieving security in a setting where we can not prove we
succeed. Whether one phrases the outcome as trusting a
system we cannot prove to be secure, or as relying on a
system we cannot trust, is irrelevant.
> "We all know" that if the most favorable attack cannot be applied,
> only less favorable attacks remain. This form of "we all know" is
> simple logic and is based on facts and logical consequences. It means
> that I expect the reader to bring some minimal context to the
> statement.
Your logic is deceptive. The "we all know" may be a logical
truth, but it applies to the entire "if" and does not imply
"only less favorable attacks remain". The consequent we
really want still depends on "the most favorable attack
cannot be applied" and that falls into the "everyone
believes" category.
We only know what attacks _we_ favor, while it is the
attacks that may hurt us are those that our adversaries
choose. Are we justified in assessing what an adversary can
do and might achieve based on our understanding? If not,
then your logic above still yields nothing. If so, then you
owe a lot of retractions.
[...]
> We can agree that there are no -- and probably *can* be no -- provable
> ciphers. But that does not mean that we must accept what we have. It
> does not mean that there is no point in attempting to protect against
> possible problems, or reduce their effects, even though the resulting
> system is no more provably strong than the original.
And that is why I am so happy with the AES effort.
> Such reasoning can be seen as a form of mathematical fallacy which is
> often presented in early algebra, the "equality" of two infinities:
> True, a cipher has infinite possibilities for failure, and true, a
> multi-cipher also has infinite possibilities for failure, but it is
> false that those two infinities are equal.
Perhaps you missed the point in your algebra class too. The
cardinality of the rationals is equal to the cardinality of
the integers, while the cardinality of the reals is greater.
They are all precisely defined and the results are provable.
How do you define the infinities you talk about for a cipher
and multi-cipher, and what is your proof that they are not
the same?
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Wed, 09 Feb 2000 22:46:31 GMT
[EMAIL PROTECTED] wrote:
> Pass one encrypt with an "AES" ciper
> Pass two use Compression A
> Pass three encrypt with a different key or different cipher
> Pass four use Compression B
> Pass five encrypt with a different Key
Those "compression" stages are not likely to compress,
so they simply amount to keyless transformations.
One might as well substitute real encryptions in their place.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Wed, 09 Feb 2000 22:47:31 GMT
"SCOTT19U.ZIP_GUY" wrote:
> Are you telling me the bastards can steal what email I send to others
> but don't get the email I sent them. I think the whole thing is Bogus and
> that they we try to some day go after those that did there best to follow the
> law.
Make sure you help Clinton out by registering your handguns!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 15:54:58 -0700
"Albert P. Belle Isle" wrote:
> Mr. Wagner:
>
> I'm having difficulty identifying what "flawed reasoning" it is of
> which you think me/us guilty. ??
I suggest you read Mr. Wagner's paper on how he compromised the original
Netscape SSL implementation by reverse-engineering the original PRNG used
(which was pathetic).
Then we'll talk. Because that's exactly the sort of stupidity by implementors
that he was talking about. Netscape's engineers figured that they knew what
they were doing so they didn't need to open the source for their SSL code.
They were wrong.
I still wouldn't give a plugged nickel for Netscape's SSL stack, though they
did fix the gaping hole that Mr. Wagner found.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Wed, 09 Feb 2000 15:57:15 -0700
finecrypt wrote:
> Eric Lee Green,
>
> You can read about how FineCrypt generates keys in program's online help.
>
> http://www.finecrypt.com/fcinst.exe
Sorry, I don't do Windows.
There are web standards for online documentation: HTML, PostScript, or PDF.
Things I cannot read are of little interest to me. Your .exe file does not do
anything on my Linux box.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 18:01:23 -0500
Reply-To: [EMAIL PROTECTED]
On 9 Feb 2000 13:41:04 -0800, [EMAIL PROTECTED]
(David Wagner) wrote:
>
>I'm not sure what you mean by "performance", but if you mean
>"how fast it encrypts", it sure sounds like the classic mistake of
>measuring the quantities you know how to measure instead of the
>quantities that actually matter.
Mr. Wagner:
I don't know what reason you have to make such a pejorative
interpretation of my use of the term "performance," (unless you're an
afficionado of fast cars and influenced by their advertising's use of
the term).
Being a somewhat old fashioned engineer, I intended the term as the
summary of all those things that are the result of actually using a
physical realization of a design, as opposed to the paper design's
intentions.
Specifically, any good INFOSEC professional should be looking at the
actual contents of the files produced on the disk - whether this
refers to ciphertext or supposedly Sanitized clusters - regardless of
how good the source code looks.
Obviously, the naive belief that the Win32 API file mapping call to
flush-to-disk actually does (as opposed to only flushing-to-VCACHE,
which may or may not write to disk) was obvious in the WIPE.C routines
from the source code for PGP5.3 as soon as I reviewed them.
(By the way, this same mistake looks like it was repeated in the
Yarrow code on your Counterpane web-site.)
However, reviewing the source code for PGP2.62 will show that this
"old reliable" bit of DOS code religiously does flush-to-disk calls.
It was only by observing that Win95 ignored the calls and failed to
overwrite when PGP was run in a DOS window that I was able to refute
Microsoft's claims that 16-bit cache-flush calls were handled like the
32-bit calls as a matter of "backwards compatibility."
Many people still insist on using PGP2.62 under Win9x "graphical
front-ends," even though it makes a bad joke of their attempts to
overwrite supposedly-Sanitized plaintext - after all, "the source code
looks good (was reviewed by experts, etc.)"
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 23:06:28 GMT
No Brainer wrote:
>
> Darren New wrote:
>
> > No Brainer wrote:
> > > secret...however I thought there may be some kind of protocol whereby two
> > > people unknown to each other can exchange public keys and retain integrity.
> >
> > There is. You just don't know *who*! :-) If they're unknown to you, you can
> > exchange public keys with them securely, but have no idea what person you're
> > exchanging the keys with. Think about it. ;-)
>
> LOL :)
>
> If you're talking about the middle man - yes - you definitely would be able to
> exchange keys with him/her securely, however if I wanted to exchange public keys
> with YOU, how would you and/or I know that the keys received are the "real" keys
> and not just substituted ones (via Mr Middle)?
Ask it a different way. You and I are "unknown to each other." If you want
to exchange keys with *me*, why? You couldn't even verify I'm not the man in
the middle if you met me face to face, could you? Calling me on the phone
won't help if you don't know my voice. Etc.
One of my bosses recorded himself speaking his own PGP fingerprint and put
it up on his web site as a .au file. If you've spoken to him, you have a
pretty good way of knowing that you're getting the right fingerprint. Still
not perfect, tho.
--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: "John M. Dlugosz" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix,comp.security
Subject: Re: Re: How to password protect files on distribution CD
Date: Wed, 9 Feb 2000 17:07:49 -0600
True example: UltraVision for EGA.
Chris Adams <[EMAIL PROTECTED]> wrote in message
news:_Bal4.6629$[EMAIL PROTECTED]...
> On Sun, 30 Jan 2000 23:37:14 -0700, Bill \"Houdini\" Weiss
<[EMAIL PROTECTED]>
> wrote:
> >I've wondered recently, what is the cost of some decent-speed DES
> >hardware? Because, one would make a hell of a dongle. Have the
> >program call the hardware to do vital parts of the code, and make the
> >hardware fast enough that the calls can be big enough to make the
> >program really fucking cumbersome to use without it. Added to
>
> Or, look at it another way: build a hardware accelerator so that your
program
> is not only inseparable from the hardware but faster as well, thus giving
your
> *customers* a reason to buy it. Done right, the "dongle" becomes a major
> feature.
------------------------------
** 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
******************************
