Cryptography-Digest Digest #537, Volume #10 Wed, 10 Nov 99 07:13:04 EST
Contents:
Re: Bracking RSA Encryption. Is it possible. (Tom St Denis)
Re: NOVA Program (Sundial Services)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Can the SETI@home client be protected? (Guy Macon)
Re: Passwords - the weak link ([EMAIL PROTECTED])
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Can the SETI@home client be protected? (Volker Hetzer)
Re: Encryption Placement ("Lassi Hippeläinen")
Re: Signals From Intelligent Space Aliens? Forget About It. (Gurripato)
S/MIME plug-in for Eudora? Strong Encryption (SkinD)
multiple valid passphrases? ("Craig Inglis")
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Wed, 10 Nov 1999 05:49:33 GMT
In article <8080ps$10f$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have a big problem. I have a lap top sniffer on a small unix LAN and
> have managed to read packages. The packages are in RSA Encryption. I
> have timed the time it takes to encrypted the e mials. To try to get
an
> idea as what the private key is . Brute force attacks on the code off
> line are impossible to brake. Have come to the conclusion that RSA
> encryption is unbrakable and it is a waiste of time using sniffer as I
> cannot brake encryption. Putting the crimminality of it asside the
> question is can RSA code be broken. I do not think it can and is good
> security against sniffer attacks.
> KM jr what you think.
First, like the egg, you can break it by hand if you hold it properly.
[my cool saying I just thought of, and I am proud of it.]
Second, his name is Kevin Mitnick not Kelvin.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 09 Nov 1999 23:08:16 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: NOVA Program
Certainly a nicely produced program, lavishly produced in fact. It was
quite a nice touch how they had actors precisely re-creating the motions
leading up to the historical photographs. (The fact that so many of the
scenes were intentionally blurred and sepia-toned got a bit tedious
after a while.)
It is interesting to see how the later stories of the Bletchley Park
saga are bringing out more and more of the human side, both British and
German, of what it was like to be there. The story of the blood-stained
intercept was absolutely stunning in its bluntness.
It was exceptionally interesting to see the interview with the radioman
of the U-150. They seemed to want to be sure you understood, and HE
certainly wanted you to understand, that he did not abandon his duty
when ordered by his captain to "abandon the papers and get out." As
usual, the story of German codebreaking (B-Dienst) still remains untold.
All in all, it's a very nice addition to the library of videography on
the subject. The people involved in producing it (and the web-site as
well) should be justifiably proud of their work.
========================================================================
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:[EMAIL PROTECTED] (PGP public key available.)
> Got Paradox/Delphi database headaches? ChimneySweep{tm} can help, FAST!
> http://www.sundialservices.com/cs3web.htm
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 23:04:45 PST
In article <809rli$ogv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>
>In article <809h4h$[EMAIL PROTECTED]>,
>Guy Macon <[EMAIL PROTECTED]> wrote:
>> High stats cheater protection is already in place. The SETI@home team
>> takes any result that in any way looks odd and sends it to several
>> other participants in different parts of the world. In addition,
>> right now each work unit is sent out and processed an average of 2.8
>> times. This is because the horde of PCs are processing data faster
>> than the Arecibo radiotelescope can generate it.
>
>Sounds like you're in a great position to detect cheaters, then.
>Randomized cross-checking is a powerful technique.
>
>Why don't you track reputation using long-term client identities?
>New clients should be considered relatively untrusted; but if a client
>has built up a good name over time and shown itself to consistently
>answer correctly, you start trusting it more.
>
>Inject a small percentage of fake positives into the data you send
>out to new clients, and also send the same data to a randomly-chosen
>trusted client or three (and possibly to your own, known-good local
>implementations). If the new client's answer differs from the trusted
>client's answers, trash the new guy. If the new guy consistently
>detects the fake positives, you can upgrade his reputation over time.
>
>The better the reputation of the client is, the less often you need to
>send copies of the same data to other clients and cross-check results.
>Moreover, when you have new data to process, you can send it
>preferentially to the most-trusted of the available clients, first.
>This should help improve total throughput, which allows for even more
>extensive cross-checking.
>
>Also, you can stop publishing stats for clients with a less-than-stellar
>reputation! This should nearly eliminate the incentive to cheat: if you
>won't get your name high up in the stats list, why bother cheating?
That is a GREAT idea! I was concerned abouty the fact that a false
positive is easy to detect, but false negatives aren't. It also solves
another problem, which is hiuge numbers of clients wanting more work to
do than the SETI tteam can give them. Instead of sending out 60%
duplicated work units, SETI could send out 50% dupes and make the balance
a set of diagnostic work units with known results. This will increase
the confidence that any patches are indeed giving correct results.
units
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Can the SETI@home client be protected?
Date: 09 Nov 1999 23:23:36 PST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>
>[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>
>>Sppedups of the client are good for bragging
>>rights only: the telescope can't shovel data into the pool of PCs
>>any faster no matter how fast the client software gets.
>
>Oh, yes: that reminds me: for a while, there was a problem in that
>everybody was getting the same data blocks over and over. I know my
>computer (at work; I eventually had to remove the client to keep my
>computer stable) did two blocks, and sent them, but wasn't credited
>for either, so I assume they were both duplicates (my computer was a
>slow 100 MHz Pentium, and for the second block, the computer wasn't
>left running for a number of evenings due to a risk of electrical
>storms).
The same block situation was a bug in the server which may have also
caused you to lose credit, but SETI@home credits duplicate work.
>If at the present time, you have more than twice as many people
>running SETI@home out there as are actually needed, simply checking
>the second copy of a processed block recieved against the first -
>after taking care that the data is distributed out in an even way -
>could help to increase the level of confidence that nothing fishy is
>going on, and detect any clients that are producing invalid results.
>(If you don't save returned uninteresting data sets, just noting their
>date and time and frequency, you can always just save a checksum as
>well.)
The data I get from SETI@home is about 350K and the data sent back
transfers too fast at 56K for me to see the counter. My 500Mhz
Pentium III Xeon takes about 4 hours to process a work unit. The
total of all of my computers have completed 378 work units in 11063
hours. or roughy 30 hours per work unit.
>Since the blocks are going out from tape, and in to tape - your
>budget, doubless, prevents you from having the disk capacity of
>AltaVista - there may be obstacles in the way of such an approach.
They have gotten some big contributions by hardware makers, so
they probably are saving all results. They are certainly saving
the tapes - future scientists may wish to analyse it with different
techniques.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Passwords - the weak link
Date: 09 Nov 1999 23:50:48 PST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Raddatz Peter) wrote:
>Actually, I did the math too, but I also know that most people be hard
>pressed to use a password longer than 10 characters...
>also, that most people would not use a random combination of chars such
>as "~g1H&,*P|k" because very few people can actually remember the
>sequence ...
>So, most people, especially those manager types, would choose common
>words and/or number combinations, either all capitalized or starting
>letter only capitalized. That narrows the field considerably.
>I don't mean to be argumentative... just making a point.
I use pass *phrases* whenever possible. Things that are easy to
remember but hard to guess like this one:
~"What~About~The~Autodidactic~Dwarf~Stuck~To~The~Heliostat?~
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 09:05:25 +0100
Don Taylor wrote:
>
> > : The main trouble with a scheme like that is to have the general
> > : public accept a standard (or defecto standard) of numerical coding.
> > : On the other hand, the Unicode gives coding of Chinese 'words' in
> > : two bytes. So there is already a precedence case.
>
> > I suspect the *main* problem is finding a dictionary that actually
> > compresses text at all.
>
> I am not being critical here or questioning the position that anyone
> is taking.
>
> But if someone would like to point at a modest sized collection
> of words that they think would be representative of the content
> of messages that would be sent, preferably with some estimated
> frequencies, particularly for the short words, then I would be
> willing to try to produce an algorithm using that dictionary
> that I think would have acceptable compression.
>
> If people are particularly concerned about plural forms of words
> and are concerned about the compression of words that would not
> appear in this dictionary then they should include some frequency
> data for those cases.
>
> Given that information I think that given a bit of time to work
> on this I can deliver such a compressor. I would need to see
> the information first, but my guess is that the resulting
> compressor would be very competitive with any of the general
> compressors available today, when used on the agreed upon
> general style and form and frequwncy of text messages.
Here my suggestion for taking care of plurals and past participles.
Let the oridnary English dictionary entries have even number of
codes. Then the plural of a noun is coded with the code of
sigular plus 1. Analogously one deals with the past participle
of verbs. This way one uses up of course one bit, but the coding
scheme is extremely simple. As I said previously, for such numerical
coding the compression is already so good that one need not
(at least in the first experimental phase) consider the aspect of
word freqeucies. Note: (1) Since the numbers are of fixed size
(16 bits or more), higher frequency words are coded with the
same size as low frequency ones, so frequencies don't help in
rendering the output file smaller. The only significance of frequency
here is to choose which words are to be included in the dictionary at
all for a fixed limit of the dictionary size (the rarely used words
not in the dictionary can be introduced through an appropriate rule,
e.g. through a code that specifies verbatim copying), (2) The above
claimed efficiency is evident, if one consider here, say, the word
'choose' that is 6 bytes long and is coded to the constant 2 bytes,
resulting a ratio of 3:1 (does anyone happen to know much better
results from Huffman compression of ASCII?). So there is in my
opinion neither need nor (probably even) possibilities of optimizing
the numerical encoding scheme. As I mentioned, Unicode of Chinese
is one such scheme. I am not aware of optimization in that
through word frequency considerations. As also mentioned, the
practical problem will be one of acceptance, i.e. which dictionary
with the numerals (one can straightforwardly assign ascending
numbers from page 1 onwards) is considered by the majority to be a
'standard' for common use.
M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Wed, 10 Nov 1999 10:30:38 +0100
Guy Macon wrote:
>
> All of this discussion has gotten me thinking. When I download software
> from Microsoft, a message box comes up talking about signatures (It
> may be "VeriSign" or some such; I don't remember exactly) and whether I
> should always trust content from Microsoft. Is this technique also
> not very good at finding pacted versions?
This works by chacking code against a signature hardcoded into windows.
You could probably try to get your client certified by windows, but
I don't think it will prevent a user from patching a piece of code after
windows has accepted it.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
------------------------------
From: "Lassi Hippeläinen" <"lahippel$does-not-eat-canned-food"@ieee.org>
Subject: Re: Encryption Placement
Date: Wed, 10 Nov 1999 11:49:03 +0200
The difference is in trading management, performance, and security.
The higher the encryption is placed, the more efficient it can be made.
It can even use application-dependent tricks, e.g. encrypt only
essential information. Security is also better, because encrypted
information doesn't appear outside the application instance.
Lower layer encryption is far easier to manage and much more scalable.
It is transparent to the users, and doesn't burden their hosts with the
calculations. And security is also better, because the users can't leak
the keys. They don't even have them.
If there were a single correct configuration, it would be in general use
by now...
-- Lassi
Benjamin Valenti wrote:
>
> I am aware that there are three OSI layers where encryption is
> implemented: application, network, and data-link layers. What are the
> differences between each? What are the reason for choosing one over
> another? What are the advantages and disadvantages to using one or the
> other? If there is a source online, I haven't found it and could use
> some help. Please help me or at least point me in the right direction.
> Thank you!
>
> --
>
> Benjamin Valenti
> _________________________________
> BOOZ · ALLEN & HAMILTON INC.
> National Security Team
> 3190 Fairview Park Drive
> Falls Church, VA 22042
> P: 703/289-5260
> F: 703/289-5825
>
> ------------------------------------------------------------------------
>
> Benjamin Valenti <[EMAIL PROTECTED]>
> Consultant, I
> Booz · Allen & Hamilton
> National Security Team
>
> Benjamin Valenti
> Consultant, I
><[EMAIL PROTECTED]>
> Booz · Allen & Hamilton
> National Security Team
> 3190 Fairview Park Drive Room 748;Falls Church;VA;22042;United States Fax:
>703/289-5825
> Home:
>703/536/5898
> Work:
>703/289-5260
> Additional Information:
> Last Name Valenti
> First Name Benjamin
> Version 2.1
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Crossposted-To: alt.military,talk.politics.misc,talk.politics.crypto
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Wed, 10 Nov 1999 09:44:20 GMT
On Tue, 09 Nov 1999 21:07:24 -0800, Andrew Carol
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, Anthony Stephen Szopa
><[EMAIL PROTECTED]> wrote:
>
>> Let us not fool ourselves, the Earth is obviously the most import piece
>> of real estate in this solar system and possibly in this part of the
>> galaxy. It is just as obvious that to announce this fact to the rest of
>> the galaxy is quite stupid.
>
>Perhaps you are unaware that there is a shell of rather noticable
>signals from the earth that is currently 90 light years across? We
>have written signs in the form of TV, radio, RADAR, etc signals which
>any intelligent race in the way could read for the last several
>decades.
>
>Something about the barn door being closed after the horse has left
>comes to mind....
>
>Oh well...
Not to speak that you can´t just hide a planet. Recently,
scientists have discovered planets orbiting nearby stars. A more
advanced alien civilizacion might be able to detect Earth from its
gravitational pull on the Sun or from direct observation. They need
only find out the 24-hour cicles on our light output.
It´s funny. We have shifted our space alien view from the
friendly neighbor next star (ET, Close Encounters, 2001) to the
here-they-come-take-cover Independence Day and the like. Is it just a
necessity for the gun industry to justify more arms race? Or ET just
got tired of paying huge phone bills?
------------------------------
From: SkinD <[EMAIL PROTECTED]>
Crossposted-To:
comp.security.misc,comp.security.pgp.tech,alt.security.pgp,comp.mail.eudora.ms-windows
Subject: S/MIME plug-in for Eudora? Strong Encryption
Date: Wed, 10 Nov 1999 10:26:12 +0000
X-no-archive: yes
This message was headed
WorldSecure Client Ver3.0 - To REGISTERED users, Help
but I got no reply. Perhaps unsurprising really but here's one final
try.
========
This is a bit of a shot in the dark but here goes.
I have an un-registered evaluation copy of WorldSecure Client so that
I can send signed or encrypted email from Eudora Pro. I use it for
non-commercial purposes. I know that MS Outlook or Netscape
Communicator will enable me to send S/MIME email free or charge but I
do not want to change my email program.
I have telephoned WorldTalk to purchase WorldSecure Client so that I
can enter a Registration Name and Registration Number to enable me to
use the program beyond the 30 day limit. I telephoned the number
listed on the registration page within the program (800) 454 4674, But
they WILL NOT sell it to me. They used to sell it but they are now
only interested in selling multiple-site licences for a minimum of 20
users. The helpful person at their sales dept said he'd like to sell
it but his employers are no longer even interested in individual
users.
This leaves me with an email program I will not change and an S/MIME
plug-in which works great but I cannot buy the plug-in.
This is frankly ridiculous.
Is there any registered user out there who would be prepared to email
me a valid Reg Name and Reg Number? I know this breaks the 'rules'
but if I could pay WorldTalk I would gladly do so. They don't want to
know.
I ask this as someone having used the internet for 4 years and having
frequently registered and paid for shareware. I have always been more
than happy to play by the rules but this time I am stumped. I have
tried to be honest!
PS: I know about the S/MIME Everywhere initiative under which I can
get a 'crippled' copy of the program free or charge but I don't want
to be stuck with a 'crippled' version.
Regards
Dominic
[EMAIL PROTECTED]
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: PGPfreeware 6.0.2i
mQENAjGZ8gEAAAEIAJt1OufnOaIgdYkGRQH3jJqcG2d5zo5vVlRsBGNN5EOx+yb0
VgRX6ZNcZPGDlby0KcQ5zwg/qdVnoPLjdF96tsZTAcZSeD7EUDUrFfMhYPyrL/jC
xq4ENqzSNsbyu727tntY6EZbpVXtSciRO0KEFB+qPx6SnfMSSRFDsTnqitbwT1za
LvsU1dl+aknLrovm3vw1SLEB/0Tb7TGEhWw4N5FgLa6HMoY2/yBGKDec7llgQwB3
xMBk6pk94ITuGBlCxO+SD882iecI7aHtiugF3BeBY1juY5AqdZzIQta5ShPow2DQ
HXM0JW2gyBwdeU1DWpVHz46xEtpInrl/i/CdMt0ABRG0F3NraW5EIDxza2luZEBw
b2JveC5jb20+iQEVAwUQOCcx5565f4vwnTLdAQF4qAgAmUf4VoQmr1ueKUXkzBe8
djxI4RsBfkAhDA20rYKW36fH/7/tRmxgotJQeyjSuSlY4ndOlT6FKAlGEt3LPugC
9f8sZrvwtuWQzLC+R//uA2QkAKG7vMEhLdp5iPi7SPt126dYtJho94RR/J7X97iX
hoQd/IoCbqBygKcRp/TRNK1PJ6i3qt+1RjPdSaikvi5b6twLGBhXohmIaeARQJjv
SXXc5W1FzdDhOkikqjYSzXcmxmPKeb9qcInWXP6E5cI6naWv5D8VZAqeh10Iexho
AGY219cczVFet4YPsZJxVD9DRChip/MB9SOBsiyxLXU/SgQBQhuTYX+SmKoq9FO6
wA==
=045u
=====END PGP PUBLIC KEY BLOCK=====
------------------------------
From: "Craig Inglis" <[EMAIL PROTECTED]>
Subject: multiple valid passphrases?
Date: Wed, 10 Nov 1999 10:28:16 -0000
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...
H() is a crypto hash function
E[K](X) means X encypted with key K
D[K](X) means X decypted with key K
K=random
for p = 1 to number of passphrases
K=H(K,passphrases[p])
next p
output E[K](0)
for p = 1 to number of passphrases
output E[H(passphrases[p])](K)
next p
output E[K](plaintext)
... and then decrypt ...
P=H(passphrase)
for p = 1 to number of passphrases (or end of data :-)
K=D[P](input[p])
if D[K](input[0]) == 0 then
output D[K](ciphertext)
exit for
end if
next p
... so a couple of questions...
is there any inherent problems or weaknesses in
doing this (assuming there are no abnormally
weak or low entropy pass phrases in the list)?
there is a storage overhead of hash length multiplied
by the number of passphrases... is there a more
efficient way of doing this??
Regards,
Craig.
------------------------------
** 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
******************************
