Cryptography-Digest Digest #85, Volume #11 Wed, 9 Feb 00 23:13:01 EST
Contents:
Re: new standart for encryption software... ("finecrypt")
Re: New standart for encryption software. (David Wagner)
Re: Anti-crack ([EMAIL PROTECTED])
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: permission to do crypto research (Xcott Craver)
Re: I'm returning the Dr Dobbs CDROM (Frank M. Siegert)
Re: Anybody know about this flaw? (Dan Day)
Re: Guaranteed Public Key Exchanges (Dan Day)
Re: Using Gray Codes to help crack DES (Dan Day)
Re: Anti-crack (Dan Day)
Re: new standart for encryption software.. (Johnny Bravo)
Re: new standart for encryption software... (Johnny Bravo)
----------------------------------------------------------------------------
From: "finecrypt" <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Thu, 10 Feb 2000 04:02:11 +0300
>Repeating the sequence 1,000
>times is not going to add 1,000 bits of entropy. In fact, it may not add
any
>entropy at all, if nothing happens to be changing on your system at that
>moment in time.
Sounds like you never worked with Windows (and if so, why you value Windows
specific program?) . Among pseudo-random values that has been retrieved
during key generation (and I specified these values in my post ) there is
such values as milliseconds since Windows started, types of events in input
queue, 1 ms time for last message and so on. These values permanently
changing during key generation. .
> Not to mention that it is *SLOW*.
Slow for what? Entire cycle of key generation on PIII takes less than 0,1
sec.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New standart for encryption software.
Date: 9 Feb 2000 17:46:31 -0800
In article <[EMAIL PROTECTED]>,
Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
> 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).
I apologize if any offense was taken. I guess I'm overly buried
in the "systems" world, where performance always means speed. I
see you meant something very different by the term. I apologize
for any confusion I may have caused.
> 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.
The problem is still that this sort of "black box testing" of
cryptographic systems is not enough to detect many types of bugs.
Flawed key generators are one obvious example of a vulnerability
that can be exceedingly difficult to recognize without source.
(For instance, the Netscape key generator was MD5-ing the time
of day and some other predictable values. There's no way you are
going to find that flaw just by looking at program outputs.)
There are many other examples, too.
Ideally, one would combine source code audits with checks of the
actual output of the system. (Indeed, your comments later in your
post give a great example of why both are needed!) But if you
leave out the source code and other detailed information about the
system, it makes the auditor's job much more difficult.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Anti-crack
Date: 9 Feb 2000 17:44:35 -0800
In article <[EMAIL PROTECTED]>,
CJ <[EMAIL PROTECTED]> wrote:
>Has anyone researched means of protecting
>programs from being cracked with encryption?
If I can hear it, I can record it.
If I can see it, I can record it.
If my computer can execute it, I can comprehend it.
Why do people have trouble with these facts?
--
Matthew Skala "Ha!" said God, "I've got Jon Postel!"
[EMAIL PROTECTED] "Yes," said the Devil, "but *I've* got
http://www.islandnet.com/~mskala/ all the sysadmins!"
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Wed, 09 Feb 2000 21:17:22 -0500
Reply-To: [EMAIL PROTECTED]
On 9 Feb 2000 17:46:31 -0800, [EMAIL PROTECTED]
(David Wagner) wrote:
>In article <[EMAIL PROTECTED]>,
>Albert P. Belle Isle <[EMAIL PROTECTED]> wrote:
>> 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).
>
>I apologize if any offense was taken. I guess I'm overly buried
>in the "systems" world, where performance always means speed. I
>see you meant something very different by the term. I apologize
>for any confusion I may have caused.
>
>> 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.
>
>The problem is still that this sort of "black box testing" of
>cryptographic systems is not enough to detect many types of bugs.
>
>Flawed key generators are one obvious example of a vulnerability
>that can be exceedingly difficult to recognize without source.
>(For instance, the Netscape key generator was MD5-ing the time
>of day and some other predictable values. There's no way you are
>going to find that flaw just by looking at program outputs.)
>There are many other examples, too.
>
>Ideally, one would combine source code audits with checks of the
>actual output of the system. (Indeed, your comments later in your
>post give a great example of why both are needed!) But if you
>leave out the source code and other detailed information about the
>system, it makes the auditor's job much more difficult.
Mr. Wagner:
I couldn't possibly disagree with your last paragraph.
If you'll re-read my original posting I think you'll see that we're in
essential agreement on the _necessity_ for source code reviews
(multiple) to catch implementation errors.
My point was/is that this, in itself, is not _sufficient_ in INFOSEC.
If your threat profile includes serious, professional atackers, you
obviously must go beyond this to counter object code-level spiking.
Whether through "poisoned" compilers or more direct methods, this
completely bypasses what are then placebo audits of source code.
Even if it doesn't, if you have to operate in the world of proprietary
operating systems, (the vast majority of the world's computing
platforms), much if not all of whose source code is _not_ available
for review, it is essential to check for what the OS actually does
with the API calls you give it - whether through mis-implementation or
just mis-documentation.
Direct examination of what actually gets written to disk clusters is
an essential component of such checking, as I tried to illustrate with
my little (real) example.
>From your last paragraph, I think you'll agree - I just want to
(perhaps over-) emphasize this often-overlooked point in the cacophony
of "show me the source code" calls from the semi-INFOSEC-literate, for
whom this mantra has become a dangerous oversimplification of what
real INFOSEC demands. Necessary - but by _no_ means sufficient.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: permission to do crypto research
Date: 10 Feb 2000 02:38:05 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
>>
>That is a disgusting challange to visalize, but I get your point. I did
>get carried away.
No problem. Sorry for the outburst.
>I would guess that almost all people who garner their own software have at
>some time had programs that would not pass legal standards, but the courts
>have ruled that this is apt to be found, and only trafficing in such
>beyond a certain value within a certain timeframe is something that can
>get you in trouble.
Well, agreed that trafficking, rather than possession, is what
will get you in trouble. I disagree about the "beyond a certain
value" part. Usually you need to infringe by a certain value in
order to get noticed, and thus a lawsuit. However, from PGP to
DeCSS we have seen heavy lawsuits over what can barely be
described as software "trafficking," certainly profitless,
arguably not with any quantifiable value.
This is an annoying quirk, and maybe a fatal flaw, of the RIAA
and MPAA: they adopt measures perceiving everyone as a potential
criminal, but don't apparently have any idea that consumers don't like
this, or that their law is untenable. They really buy their own hype.
I mean, there are intellectual property disputes in the computer
industry too, but there people are smart enough to understand that
their patents may be a tad unfair: they know not to sue the Hell
out of everyone, and end up getting their law scrutinized. The
usual goal is picking a small enough royalty to avoid challenges.
The MPAA, in contrast, seems to think that the DMCA is bulletproof.
>Worrying about a single program that disassembles, be making it as illegal
>as lots of other things, surely is not more important, just what you might
>do with it combined with a certain value within a certain timeframe might
>makie it a problem.
Well, when you publish a paper proposing a watermarking method,
you are expected to supply standard numbers. This implies
possession by many people (and hence distribution) of a standard
program. The output of the detector after StirMark is applied
once, then twice, etc.
You could write your own program to stress-test your marks,
but in a research paper you want numbers that people can compare
to the next guy's numbers. My fear is that one of these tools
may one day come under fire.
-Xcott
------------------------------
From: [EMAIL PROTECTED] (Frank M. Siegert)
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Thu, 10 Feb 2000 03:20:01 GMT
On 08 Feb 2000 14:06:14 -0600, Victor Zandy <[EMAIL PROTECTED]> wrote:
> I don't know how the PDF files on the CDROM were prepared, but
>they look like they were scanned from physical book pages. For recent
>titles, like Stinson, they should have been generated from the
>computer originals to make a smaller file, with better image quality.
Most likely the pages are CCITT G3 compressed inside the PDF and if
you use a nice PDF tool to produce the PostScript stream containing
all page images as compressed bitmap (most PS printers can handle FAX
G3 these days) your PS pages should be as small (relatively spoken) as
the PDF source.
Such a nice (and free) tool is 'xpdf' see
http://www.foolabs.com/xpdf/
You'll need 'pdftops' which is part of the Win32 binary archive. Do
not set the option '-level1' as this will completely unpack the Fax
compressed data resulting in the usual large and bloated PS files.
As usual your mileage may vary.
* Frank Siegert * frank@this<SPAMBLOCK>.net
* http://www.this.net/~frank
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Anybody know about this flaw?
Date: Wed, 09 Feb 2000 22:57:11 GMT
On Wed, 09 Feb 2000 23:50:14 +0800, No Brainer <[EMAIL PROTECTED]> wrote:
>I was wondering if anyone knows of a secure way to exchange public keys
>between two people via Internet e-mail without using any other form of
>communication?
The whole point of a "public key" is that it doesn't MATTER if it's
intercepted. You don't NEED a "secure way" to exchange them.
You could publish them in the newspaper if you like.
>Also, would the proposed system work if "someone unbeknownst to us" was
>intercepting and modifying the key exchanges?
Simple interception would be no problem whatsoever.
Someone in the middle modifying the key exchange is a bit more
of a tricky problem, but unless they're in a position to fiddle
with ALL your subsequent traffic, I can't see that it would do
them much good. For example, if you sent your public key to
person X, and person Q in the middle intercepted your public
key and then sent another public key to X, the first time person
X uses that public key to encrypt a message to you, you would
not be able to read the message. UNLESS person Q was *always*
in the middle, and constantly intercepted, de-encypted (using
his own private key) the message from X, and then re-encrypted
it to you using your original public key.
Protecting against such attacks is one reason that public-key
programs like PGP let you produce a "digital fingerprint" of
a public key, which you and person X can compare (over the phone,
for example) to ensure that the public key he received is really
the one that you sent. And once you've verified that (and you
have likewise verified that you received X's public key properly),
a person in the middle could neither eavesdrop, nor spoof.
I can't think of a way to do this sort of cross-checking ENTIRELY
over an email link, but then I can't think why you'd be so
unrealistically restricted, either.
If you HAD to be restricted to only an email link, and could
pre-arrange things with person X, your best bet would be to
send a verification message (after key exchange) that contains
the digital fingerprint of the public key you received, hidden
in a message in such a way that Q would not know to look for
it (and alter it to match the bogus key he had substituted).
For example, steganography in a WAV file of your kid singing,
attached to an email saying, "isn't Billy just adorable?!"
If you're not familiar with steganography, it's the science
of hiding a message within a larger message (or file) in a way
that its presence is not even suspected by an eavesdropper. One
way to do this is to change the lowest order bit of each sound
sample in a WAV file to be the information you want -- being
the lowest order bit, it's mostly random noise anyway, and changing
the bits will not noticeably change the actual sound if
played.
But then, if you had prearranged things with person X, you
could simply send the fingerprints to each other using an
IDEA-encrypted message that used a pre-arranged password as a key.
So far, I can't think of a way to verify the public keys
WITHOUT a pre-arrangement (i.e., entirely through methods
negotiated through, and carried out via, email, with the
possibility that Q has always been in a position to intercept
and modify the email stream).
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Guaranteed Public Key Exchanges
Date: Wed, 09 Feb 2000 23:28:55 GMT
On Thu, 10 Feb 2000 02:29:58 +0800, No Brainer <[EMAIL PROTECTED]> wrote:
>
>I was hoping there was a new protocol of some type that would allow me to
>exchange public keys with integrity and take the middle man "out of the
>loop" (without the need for another secure channel of course).
In theory, anything you could have used to establish secure communications
with the INTENDED recipient could instead be used to (unintentionally)
establish communications with the man-in-the-middle. And once the
man-in-the-middle does the same with your intended recipient, he's
got all the channels he needs to pretend to be nothing more than a
wire connecting you and your intended recipient.
>Just think, we fly man to the moon and send missions to mars (we won't
>mention the last two "disappearances") and no-one has yet to come up with
>this solution :)
Well, I've got at least a partial workaround... As one of your
first messages, send your recipient an attached EXE file of a popular
sort, such as the "gerbil in the microwave" animation. The man-in-the-middle
would have no reason not to just re-encrypt it with his own "him-and-your-
recipient" key, and then forward it to your recipient. However, unbeknownst
to the man-in-the-middle, you've modified the "gerbil in the microwave"
program to, 24 hours after receipt, pop up a message saying, "hey, Joe,
I snuck this message to you just to try to evade any man-in-the-middle --
the public key I sent you has a digital fingerprint of A34D88... If that
doesn't match the public key you sent, we're in big trouble!"
This isn't foolproof, however:
1. If the man-in-the-middle is a great hacker, he might analyze the
program before forwarding it, and discover the "trojan horse".
2. If the man-in-the-middle is paranoid enough, he might not forward
anything that might contain such a trojan horse. On the other
hand, this greatly complicates his life, because now he has to
start faking messages from the recipient saying, "hey, that was
fun", followed by, "oh, I got your verification message, and
everthing's fine", and any subsequent traffic that might have
ensued from the original exchange had it actually gone through.
3. Even if it gets through and your recipient realizes your public
key has been spoofed, how does he alert you? The man-in-the-middle
will stop such warnings from getting back to you. But then,
the jig is up on one end, and your recipient will no longer send you
sensitive information, and the man-in-the-middle has to
either make up normal messages to you from your recipient, or
pretend to sever communications, or something.
But at least it's a step in the right direction.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Using Gray Codes to help crack DES
Date: Thu, 10 Feb 2000 00:30:45 GMT
On 8 Feb 2000 23:24:52 GMT, [EMAIL PROTECTED] wrote:
>
> count = count + 1
> greycode = count ^ (count >> 1)
Hey, that's really slick. But I'll be damned if I can figure
out why it works...
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Anti-crack
Date: Thu, 10 Feb 2000 00:53:50 GMT
On Tue, 8 Feb 2000 20:40:48 -0600, "Matt" <[EMAIL PROTECTED]> wrote:
>
>http://inner-smile.com/nocrack.htm
>
>By far one of the best sources of info on this subject.
Spectacular site -- thanks for the pointer, I had not
run across it before.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software..
Date: Wed, 09 Feb 2000 22:28:54 +0000
On Wed, 9 Feb 2000 21:51:42 +0300, "finecrypt" <[EMAIL PROTECTED]>
wrote:
>I agreed with you that you cannot trust program if you don't know how it
>works. But if you test the program with oficial test vectors of authors of
>algorithms and IF ciphertext produced by the program will *exactly matches*
>with test ciphertext, THEN you will know how program works.
You are missing the point. I can easily write a program that will match
every and all possible test vectors for a dozen ciphers and still outputs
all cipher text with ROT13 encoding. The only thing test vectors prove is
that the test vectors work right, since we can't see the source we have no
idea if the test vector code is the same code used to encrypt data.
>Moreover, you
>will know that the program encrypts exactly as intended by authors of
>encryption algorithms and that there is no any backdoors.
You know no such thing. The only thing test vectors prove is that you
can match the test vectors correctly. It does not preclude broken RNGs,
partially leaked keys, improper cipher implementation for actual
encryption or any number of possible problems with the program. The only
thing we have is your word, and frankly, that is not good enough as we
don't know you and have no reason for that level of trust with a total
stranger.
>You will be able
>to crack ciphertext produced by the program only if you crack algorithm.
Only if you've done it correctly and didn't include a deliberate or
accidental weakness, and we can't know that.
>Oficial test vectors is the more reliable guarantie than the source code.
The only thing it shows is that the test vector code works, it says
nothing about the actual encryption itself. Your constant argument by
assertion in the face of common sense is starting to set off snake-oil
detectors.
>Today FineCrypt is sole program that offer possibility to check it with
>oficial test vectors.
Scramdisk has implemented test vectors for the two years I have been
using it, and very likely much longer than this. I expect you to change
your website, you are not the "first" nor the "sole" program to implement
test vectors. Refrain from claiming this in future postings.
From what little I can tell by your website you are offering file
encoding, let's compare features to Scramdisk.
Scramdisk Finecrypt
1) Open Source Yes No
2) 256 Bit Encryption Yes No info given at site
3) Virtual Partition Yes No info given at site
4) On the fly encryption Yes No info given at site
5) Free Yes No
6) Fits on Floppy Yes No
7) Stenography Yes No info given at site
1) The source for Scramdisk is open for examination and for nearly
unlimited use in other projects and enhancements.
3+4) If Finecrypt requires me to decrypt a file, work on the file, then
recrypt the file; not only is it much more work, it is a security risk.
Scramdisk works on entire partitions and virtual partitions, unlocking
multiple files with a single key and allowing those files to be worked on
while they are still encrypted on disk. Programs working in those
partitions writing temp files while working will automatically have those
temp files encrypted as well.
5) You can't beat the price of Scramdisk, especially with a product
costing $24.95.
7) Partitions are not identified in standard way, attempting to access
a partition with an invalid password will not result in an error message
that would reveal the presence of a partition. There are no headers or
other information that will identify a Scramdisk Partition. Partitions
can be hidden in the lower bits of .wav files, allowing the files to still
be playable while containing hidden information equal to 25% or 50% of the
size of the .wav file.
I will not install and execute a program to see if it fits my needs,
that is what a web site is for. There is no info on the Finecrypt site
that describes what the program is, what it does, why it would help me,
what it does better than Scramdisk, why I should pay for something I
currently get for nothing.
Johnny Bravo
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: new standart for encryption software...
Date: Wed, 09 Feb 2000 22:34:29 +0000
On Thu, 10 Feb 2000 00:06:09 +0300, "finecrypt" <[EMAIL PROTECTED]>
wrote:
>You can read about how FineCrypt generates keys in program's online help.
We are not going to download and install a program just to find
information that should be on the web site. Why bother, we have a
perfectly functioning, freeware alternative. Scramdisk at
http:..www.clara.scramdisk.net, the site will let you know if it meets
your needs by giving a complete description of what the product is and
what it does, allow you to download the program, source code and user
manuals as needed. The author of Scramdisk is very willing to answer
questions in the newsgroup he created just for that purpose
alt.security.scramdisk.
You have to expend some effort to convince people to pay for a product
that costs $25 more than a perfectly good alternative with user
confirmable security. Telling people "just download it and don't bother
me with questions" isn't going to make the grade.
Johnny Bravo
------------------------------
** 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
******************************
