Cryptography-Digest Digest #545, Volume #10 Thu, 11 Nov 99 10:13:04 EST
Contents:
Re: Can the SETI@home client be protected? (David A Molnar)
Re: multiple valid passphrases? ("Craig Inglis")
Re: Cryptography for Dummies ("M. Kohl")
Re: Can the SETI@home client be protected? (Mark Baker)
Re: Can the SETI@home client be protected? (fungus)
Re: Cryptix or JCE1.2 ("Tim Wood")
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Web Confidential for Windows (Alco Blom)
Re: Can the SETI@home client be protected? (Doug MacKay)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
Re: Build your own one-on-one compressor ("Trevor Jackson, III")
Password Policy (Boaz Lopez)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! ("Alexander PUKALL")
Re: Research suggestion? (Tom St Denis)
Re: S/MIME plug-in for Eudora? Strong Encryption (SkinD)
ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED or not ? ("Alexander PUKALL")
anno: open bcrypt - free file encryption (Juergen Thumm)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 08:31:57 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
[Paul Crowley points out that "fake" transcripts which verify as valid
must be hard to produce]
> It's not clear, though, whether the SETI problem makes it easy to
> find a transcript with the property you mentioned.
In the absolute worst case, would the transcript be a complete trace of
program execution, which the server would then have to repeat and check
for correctness, maybe by doing the computation itself? It seems to me
that this is an upper bound on how much work needs to be done to verify a
client transcript.
Then the question is how small can we make that proof by massaging it
somehow? For instance, can we turn the transcript into a proof which is
itself probabilistically checkable, and therefore easy for the server to
check?
There's a page on "Proof Carrying Code" at
http://www.cs.cmu.edu/~necula/pcc.html
which looks interesting -- it's not clear to me how practical it would be
here, though.
Thanks,
-David
------------------------------
From: "Craig Inglis" <[EMAIL PROTECTED]>
Subject: Re: multiple valid passphrases?
Date: Thu, 11 Nov 1999 09:24:24 -0000
John Myre wrote in message <[EMAIL PROTECTED]>...
>Craig Inglis wrote:
>>
>> Hi,
>>
>> if I wanted to encrypt some plaintext using a
>> symmetric encryption algorithm (blowfish or whatever),
>> but I would like to be able to decrypt using one
>> pass phrase from a list of valid pass phrases, it
>> would seem like I could encrypt the plaintext as follows...
>>
>
[snip]
>
>One practical point - I think the step where the original
>K ("random") is hashed with the passphrases to create the
>final K is pointless. The final number isn't any more
>random than the starting one - just different. Unless you
>mean that the initial K has little entropy, so that you
>need the (secret) passphrases to help. In that case I'd bet
>that K doesn't need to be "random" at all. Depending on the
>situation, a fixed K might even work.
I just thought that if I initialised K with some (most probably
weak random value it might help to hide how many actual
passphrases were valid, and where the cipher text started.
For instance, in the case of a single passphrase, if K might
well equal H(passphrase) or similar.
Perhaps there is a better way of achieving the same goal?
Or maybe there is little value in trying to hide this anyway? :-)
Regards,
Craig.
------------------------------
From: "M. Kohl" <[EMAIL PROTECTED]>
Subject: Re: Cryptography for Dummies
Date: Thu, 11 Nov 1999 09:19:11 +0100
Dear all!
Now I know where to start.
Thank you for your valuable help.
Greetings
Markus
Black holes *really* suck.
[EMAIL PROTECTED]
------------------------------
From: Mark Baker <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Thu, 11 Nov 1999 09:32:31 +0000
Guy Macon <[EMAIL PROTECTED]> writes
>There is no need to actually prevent patched clients from running -
>if the server can detect that the client is patched, it can stop
>sending work to be processed, thus shutting the client down.
>
I'm very much a newbie when it comes to digital signatures and such so
some of the experts here will surely be able to point out problems in
this idea, but I can't learn without asking questions so here goes:
Prior to sending back its result, the S@H client sends back its
platform/version code and a checksum value generated after xoring the
code segment executing in memory with the Work Unit file on a word by
word basis (specifically the FFT routine).
The server (knowing the platform/version) can then perform an equivalent
check to verify the checksum.
I'd imagine a serious hacker could find some way to bypass even this,
but surely it would be more trouble than it's worth to do so.
--
Mark Baker - 1.4* per arecibo ad sapientis extra terrestrialis
Web Pages: http://www.lange.demon.co.uk/Index.html
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Wed, 10 Nov 1999 22:49:01 +0100
Johnny Bravo wrote:
>
> Can anyone find any obvious flaws in such a scheme?
>
Nope.
Given that there's a surplus of clients it sounds like the
best solution.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Subject: Re: Cryptix or JCE1.2
Date: Thu, 11 Nov 1999 09:37:46 -0600
JCE is the official sun implemented provider is is only available in the
USA.
Cryptix is available outside the USA it is a clean-room (or was last time I
checked) implementation of the JCE (i.e.. same spec but by a third party...
it also has some additional abilities). look at http://java.sun.com to find
out more about that.
I think your question is one of who you trust to code an encryption
algorithm for you.
A book called "JAVA Cryptography" by "Jonathan Kundsen" will help you use
the JCE (or Cryptix or whatever).
Tim
Emmanuel Drouet wrote in message <[EMAIL PROTECTED]>...
>Hello !
>
>Could you tell me what is the difference between Cryptix3.1.1 and JCE1.2
>?
>Is JCE1.2 more secure than Cryptix ?
>I don't know which one to use...
>
>Thanks,
>Emmanuel :o)
>
------------------------------
From: Coen Visser <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 10:13:38 +0000
"james d. hunter" wrote:
> You're still missing the point.
> Both TRNGs and URNGs [Unreliable RNG] are given the modifier
> "random" because "random" applies to the -generators- and not
> the -strings-.
If you want to define it that way. But this leads to a useless
definition -> A TRNG produces strings that are "unpredictable"
(we can not use the word random anymore, it is reserved for
the generators and not the strings). So we have no other means to
qualify the strings other than to say that they are produced by
a TRNG and therefore are "unpredictable". But we have no means to
qualify the TRNG (is it really truely random?) because we can not
talk about the degree of randomness of the strings it produces
(that was not allowed).
IMHO defining "(degree of) randomness" as a quality of finite
and infinite strings gives a solid starting point to discuss the
quality of RNGs in the field of computer science. Whether or not
this is true for discussing physical RNG I don't know, but the
moment you start manipulating discrete samples of a physical RNG
in a computable manner you have to consider the computer science
implications.
> > Hmm, the compression argument itself seems to have been compressed
> > using a "lossy" compression method and therefore some information has
> > been lost ;-) Optimal compression of strings is computed + O(1),
> > you still need some Turing Machine (of size O(1))
> > to decompress your compressed string. It seems to me you can not
> > compress both "0" and "1" but one of them can be compressed using the null
> > string as the input of your TM.
> You need strings to define the TM, so the TM can be reduced to {},
> and you're left with "1" as incompressible.
How would you decompress anything with no TM to interpret your
decompression routines? You need at least a small basis for computation.
What does a ".zip" file mean if you can not define an unzipper? At the
very least you need a Universal Turing Machine of size O(1) to interpret
your unzipper. That is the required minimal overhead.
Regards,
Coen Visser
------------------------------
From: Alco Blom <[EMAIL PROTECTED]>
Subject: Web Confidential for Windows
Date: Thu, 11 Nov 1999 11:18:05 +0100
Reply-To: [EMAIL PROTECTED]
Web Confidential 1.0 for Windows
Web Confidential is an intuitive, easy-to-use program for
managing user IDs, passwords, registration numbers, and the like.
Thanks to the use of a number of advanced features of Windows 95/98,
Web Confidential can be used in close conjunction with popular Internet
software, such as Netscape Navigator and Microsoft Internet Explorer.
While Web Confidential is suitable for a wide variety of personal data,
from credit card numbers to serial numbers, Alco Blom designed Web
Confidential particularly for the World Wide Web in mind. "Increasing
numbers of Web sites maintain some form of user registration," points
out Blom. "You may not realize it, but in the course of time you may
registered at a couple of dozen sites. Do you remember the passwords
you entered for all of them?"
Web Confidential allows Web surfers to store URLs, user IDs, and
passwords in one secure location. Web Confidential can automate the
process of logging into a password-secured Web page by automatically
passing URL, user ID, and password to your Web browser.
To ensure the personal information stored in Web Confidential remains
confidential, the program's password files can be encrypted using
state-of-the-art encryption technology.
Web Confidential supports keys of up to 448 bits in length, using the
Blowfish algorithm.
Alco Blom and Arno Stobbe have released Web Confidential as shareware.
After a trial period of thirty days, users are encouraged to register
the program for US$20. The Home Page of Web Confidential is:
<http://www.web-confidential.com>
FTP Download:
<ftp://ftp.web-confidential.com/pub/web-confidential.zip>
Web Confidential runs on Windows 95/98/NT.
Contact Arno Stobbe at: <mailto:[EMAIL PROTECTED]>
------------------------------
From: Doug MacKay <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Thu, 11 Nov 1999 11:07:04 +0000
Mark Baker wrote:
<snip>
> I'd imagine a serious hacker could find some way to bypass even this,
> but surely it would be more trouble than it's worth to do so.
<snip>
Unfortunately this would only stop some of the people, not all. A
number of the people who are altering the client would most likely view
this as a challenge and quickly figure out a way to circumvent this.
Soon as one person discovered a way to do so, others would quickly
follow.
Then again... anything that is done to prevent altered clients, other
than double checking the results, will be circumvented in one way or
another. The client runs on untrusted users systems. Such a user has
full access to the binary and can alter it in nearly infinate ways to
pass whatever checks are in place localy.
Since the data is being processed faster than its being produced double
checking results seems quite possible. If at any point a client returns
a false answer for a test packet known to be true, send more test packes
their way. If discrepancies continue, stop using the results from that
client and then run through the logs to see which packets he has been
sent and double check all of them.
At this point you would have two options. Either stop sending the
altered client data (at which point he/she would realize they have been
discovered and just setup a new client) or keep sending them data but
ignore the results.
Though sending data which you intend to ignore wastes bandwidth and some
cpu time it will probably place you ahead in the long run. When each
altered client is ready to recieve data just send them some random
packet that is in the queue to be examined. Dont remove the packet from
the queue, just send it. This way the client will be unable to determine
they have been removed from the pool of trusted clients (perhaps you
could keep updating their stats as well.. just keep it noted for
yourself who is invalid).
Also, for this to work you need a large pool (not crypto sized large =)
of test packets. These packets could possibly be previously valid
packets which gave interesting results. If the same
"interesting" results arent reproduced by the client, then you probably
have your badguy.
-doug
------------------------------
Date: Thu, 11 Nov 1999 07:34:25 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Coen Visser wrote:
> "Trevor Jackson, III" wrote:
>
> > Randomness _implies_ incompressibility. They are not identical.
>
> Hmm, you can convince me by giving an example of an incompressible
> string that is not random.
By what appears to be your definition all sufficiently long strings are
compressible because when shown a single string you can claim to name it and then
the name is a shorthand, thus a compressed version, for the original string.One
cannot compress individual strings without resorting to such sophistry.
One can compress the output of a generator to the exact degree that the behavior of
the generator is predictable.
>
>
> > Properly, no string is a random string.
>
> It is impossible to prove that a string is random, what do you mean with
> "no string is a random string"?
I mean that the adjective "random" applied to the noun "string" does not yeild a
meaningful concept.
>
>
> > Randomness applies to the source or
> > the selection process that generated the string rather than the output of of
> > the generator. If you neglect this difference you get into the position of
> > denying the randomness of "0000000000" because it can be compressed, in spite
> > of the fact that you flipped the coins yourself.
>
> So what is wrong with denying the randomness of "0000000000"?
Nothing.
> It is quite possible to produce a *finite* non-random (sub)string with
> a fair coin.
No.
A fair coin will select select randomly. Thus all outputs of a fair coin toss are
random even if they select the string "0000000000". There are 1024 strings that
represent the possible outputs of 10 fair coin tosses. No matter which if the 1024
you end up with, it was random because it was selected randomly. OTOH, there is a
perspective (flawed IMHO) that considers any such single string to be non-random
simply because it is the one you got as output, wrote down, used, whatever.
This difference can be resolved by considereing the tense of the statement.
'"0000000000" WAS randomly selected' versus '"0000000000 is random'. Claiming
randomness in the present tense is invalid.
> On the other hand I don't believe it is possible to
> produce an *infinite* non-random string by throwing a fair coin.
> Your reasoning has some troublesome consequences. Say I have two
> random sources. One "true" random source (TRNG), and one unreliable not
> quite random bit string generator (URNG-generator). If both
> sources produce "0000000000" then I would have to
> acknowledge the randomness of the produced bit-string because
> it is produced by TRNG and *at the same time* denying it because it
> was also produced by URNG.
Right. This conflict derives from the attribution of randomness. You are
attributing to the string. I am attributing it to the generators. The string
cannot be both. The generators are by definition distinct thus their randomness is
distinct even when they produce identical results.
> > You also have to defend the
> > notion that the strings "1", and "0" are always random because they cannot
> > ever be compressed.
>
> Hmm, the compression argument itself seems to have been compressed
> using a "lossy" compression method and therefore some information has
> been lost ;-) Optimal compression of strings is computed + O(1),
> you still need some Turing Machine (of size O(1))
> to decompress your compressed string. It seems to me you can not
> compress
> both "0" and "1" but one of them can be compressed using the null string
> as the input of your TM.
I doubt it. If you use the empty string to represent information you create an
encoding problem. If the decompressor is left recursive you get an infinitely long
prefix of nulls before any of the actual information appears. This approach does
not appear to be effective.
------------------------------
Date: Thu, 11 Nov 1999 07:43:37 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Mok-Kong Shen wrote:
> I know, though not exactly, that there is a pidgin English
> consisting of some 500(?) words that are assumed to be a 'minimal'
> vocabulary for communicating in the language. You might be
> interested in that.
I've heard the number 800 used as the minimal vocabulary required. I.e., with
the selected vocabulary one can live a normal life.
------------------------------
From: Boaz Lopez <[EMAIL PROTECTED]>
Subject: Password Policy
Date: Thu, 11 Nov 1999 04:40:35 -1000
I have 8 passwords to remember. So a Password Policy
was created to prepare for the day when I forget
my password.
Policy Draft
1 Use one passphrase as a master key to decrypt a list
of all other passwords.
2 Keep the encrypted list of passwords on a public website
so it can be accessed from anywhere in the world.
3 On the website, put a hint page to remind one about
the master passphrase.
It is easier to remember one master passphrase than 8 passwords.
------------------------------
From: "Alexander PUKALL" <[EMAIL PROTECTED]>
Subject: Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !!
Date: Thu, 11 Nov 1999 13:36:48 +0100
Why not cracked ??
Encryptor is a stream cipher with no salt key, then Encryptor is dead.
I think we could as to Jim Gillogly the master of this kind of ciphers what
is think about this.
To crack the cipher, you take only 10 to 30 encrypted files.
Assuming the password is the same and the encrypted files are text files :
You search for each byte of each file in column, for example :
Byte 1 file 1
Byte 1 file 2
Byte 1 file 3
.... in this column of byte 1, you search the most frequent byte. It will be
the
space in the plaintext
The second will be the E ...
When you have found the space, you XOR the Byte 1 value of file 1 with the
0x20 value ( space ), it gives you the output of the stream cipher for Byte
1.
You can verify this with other byte 1 in other files, it will be the same
because the output of the stream cipher is the same with the same password.
You can verify with XORing the Byte 1 and the value 0x45 ( E value )
You do this with all bytes of the file and this will give you the output of
the stream cipher. After you can crack directly all files encrypted with the
password which was used ( if the are <= in length with the files you used to
obtain the output of the stream cipher ).
I know that it's works because it's with this system i cracked Word 6.0
encryption file system.
We can ask to Jim Gillogly if you want :)
>Alexander PUKALL wrote:
>> I changed 6A->6B at offset 0x105 and the decryt text was : ( look the B )
>Hi.
>This only shows that the company in question needs to learn what binary
>permutation is, You have proved that it is lacking in security, You have
_not_ >cracked it. The same can be done with the passwords in Allaires
ColdFusion >webserver.
>(Allaire have been notified a while ago and they are dealing with it as we
>speak, but not for this reason..)
>Regards,
>Glenn Larsson
>Private Citizen
>Sweden
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Research suggestion?
Date: Thu, 11 Nov 1999 12:40:19 GMT
In article <80dkee$2hpe$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>, Peter Pearson
<[EMAIL PROTECTED]> wrote:
> >Rick Decker wrote:
> >>
> >> I have a student (senior double major in math, cs) who's
interested in
> >> doing a thesis in crypto. Problem is that I'm trained as a
topological
> >> graph theorist cum computer scientist and don't know much more
about
> >> the subject than what I need to teach it in my algorithms course.
> >>
> >> Anyone have a suggestion for a research project that would be
suitable
> >> for a semester-length project? My student is pretty quick, but the
> >> project need not lead to original results-- a new interpretation or
> >> tweak of an existing result would be satisfactory. The thesis is
> >> nominally in cs, but need not include a programming component.
> >
>
> He could try to look at "all or nothing" type of crypto systems
> such as scott16u compared to any of the short keyed AES systems
Yak yak yak yak.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: SkinD <[EMAIL PROTECTED]>
Crossposted-To:
comp.security.misc,comp.security.pgp.tech,alt.security.pgp,comp.mail.eudora.ms-windows
Subject: Re: S/MIME plug-in for Eudora? Strong Encryption
Date: Thu, 11 Nov 1999 12:49:36 +0000
>Why not just use PGP?
Because, to my knowledge, millions of internet users are already using
email programs which are able automatically to use S/MIME without the
need even to install a program or plug-in. I'm thinking of Netscape
Communicator. S/MIME would enable people to use encryption or signing
with me without them even particularly thinking about what they are
doing.
I like, and use, PGP but frankly can't ever see more than 0.001% of
internet users ever installing it or even understanding it once they
have done so. S/MIME can be used by morons.
WorldTalk abandoning this market for end-users does upset me because
it would force users of S/MIME to abandon a perfectly good email
program (Eudora) to use Netscape or Outlook Express. One might wonder
if Microsoft have paid WorldTalk off. Or is this all a part of a
conspiracy to really make people use 40bit encryption by default
because nothing better is EASILY available. Don't most people
normally take the line of least resistance?
Dominic
--
PGP key available from the key servers
Key ID: 0x11D34E3A
Fingerprint: 5F5D 23D7 143B E2A2 B165 B395 D1D9 8791 11D3 4E3A
------------------------------
From: "Alexander PUKALL" <[EMAIL PROTECTED]>
Subject: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED or not ?
Date: Thu, 11 Nov 1999 13:47:12 +0100
Why not cracked ??
Encryptor is a stream cipher with no salt key, then Encryptor is dead.
I think we could as to Jim Gillogly the master of this kind of ciphers what
is think about this.
To crack the cipher, you take only 10 to 30 encrypted files.
Assuming the password is the same and the encrypted files are text files :
You search for each byte of each file in column, for example :
Byte 1 file 1
Byte 1 file 2
Byte 1 file 3
.... in this column of byte 1, you search the most frequent byte. It will be
the
space in the plaintext
The second will be the E ...
When you have found the space, you XOR the Byte 1 value of file 1 with the
0x20 value ( space ), it gives you the output of the stream cipher for Byte
1.
You can verify this with other byte 1 in other files, it will be the same
because the output of the stream cipher is the same with the same password.
You can verify with XORing the Byte 1 and the value 0x45 ( E value )
You do this with all bytes of the file and this will give you the output of
the stream cipher. After you can crack directly all files encrypted with the
password which was used ( if the are <= in length with the files you used to
obtain the output of the stream cipher ).
I know that it's works because it's with this system i cracked Word 6.0
encryption file system.
We can ask to Jim Gillogly if you want :)
>Alexander PUKALL wrote:
>> I changed 6A->6B at offset 0x105 and the decryt text was : ( look the B )
>Hi.
>This only shows that the company in question needs to learn what binary
>permutation is, You have proved that it is lacking in security, You have
_not_ >cracked it. The same can be done with the passwords in Allaires
ColdFusion >webserver.
>(Allaire have been notified a while ago and they are dealing with it as we
>speak, but not for this reason..)
>Regards,
>Glenn Larsson
>Private Citizen
>Sweden
------------------------------
From: Juergen Thumm <[EMAIL PROTECTED]>
Subject: anno: open bcrypt - free file encryption
Date: Thu, 11 Nov 1999 13:56:10 +0100
open bcrypt does file encryption with a passphrase,
platform-independent, with zero installation effort,
using an rc4-compatible 128-bit symmetric cipher.
it runs under windows, sun, aix, hp/ux, os/390 and os/2;
with minor effort, it should run everywhere.
the sourcecode, buildscripts, documentation of the file format
and binaries are available at http://go.to/bcrypt
or http://members.tripod.de/privacy/
the tool supplies a brute-force slowdown mechanism,
which scales dynamically with the cpu power available at encryption;
plaintext attacks are disabled by a random key block,
and tampering is blocked by hashing of the whole file data.
comments about the tools' security, and especially
effort estimations about how much it would take
to brute-force break an encrypted archive with,
let's say, a well-chosen 8-character password,
would be greatly appreciated.
so far, i had no time myself to research performance data
and cost of up-to-date's md5 and sha hardware implementations,
and besides, as being the author, my estimation of this tool
would not really matter.
may the source be with you.
Juergen Thumm
------------------------------
** 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
******************************
