Cryptography-Digest Digest #128, Volume #13       Thu, 9 Nov 00 06:13:01 EST

Contents:
  Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile   (Anthony 
Stephen Szopa)
  Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile   (Anthony 
Stephen Szopa)
  Re: OT Re: Updated XOR Software Utility (freeware) Version 1.1 from  (Anthony 
Stephen Szopa)
  Re: Updated XOR Software Utility (freeware) Version 1.1 from  (Anthony Stephen Szopa)
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Dido Sevilla)
  Re: Does PGP sdk 1.7 have Prime Number Generator or Checking Functions? (Dido 
Sevilla)
  Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile   (Richard 
Heathfield)
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Richard Heathfield)
  Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile   (Richard 
Heathfield)
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Paul Schlyter)
  Re: Authentication and taking credit (was Re: Protocol) (Paul Crowley)
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (David Formosa (aka ? 
the Platypus))
  RSA security ("Martin Otten")
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Tim Tyler)
  Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Tim Tyler)

----------------------------------------------------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile  
Date: Wed, 08 Nov 2000 21:35:40 -0800

Scott Craver wrote:
> 
> Richard Heathfield  <[EMAIL PROTECTED]> wrote:
> >
> >Mr Szopa's program is 315392 bytes in size after decompression. No
> >source code is provided. I know I'm not the only one to think this to be
> >the height of lameness.
> 
>         That's a pretty big increase between versions.  Wow.  And
>         all it does is XOR?
> 
> >So, perhaps not unnaturally, I wondered (purely in the spirit of scientific
> >enquiry, as befits a sci. newsgroup) if it were possible to write an
> >even lamer program. I tried hard. But did I succeed?
> 
>         [snip]  Amazing. Maybe you should run speed tests.
> 
>         The funny thing about Mr. Szopa's utility is that, before he
>         posted it, we were only suspicious of his algorithm, and his animosity
>         towards people who wanted to analyze his algorithm.  Now, he
>         accidentally gives away that his skills as a programmer might be a
>         problem too, by making an unbeatably HUGE binary to perform one of the
>         simplest operations on two files, *and* somehow making the first
>         version unable to XOR files in different directories.  I didn't even
>         know that this kind of deficiency was possible with the full-blown
>         canned File Open dialog boxes in Win32 and MFC.
> 
>         But the really funny part is his apparent air of superiority as
>         a result, despite very obvious size and performance difference between
>         his and others' software.
> 
>                                                                         -S


Are you are a confirmed fool?

Would only fools believe you?

What?

Here's what:

"despite very obvious size and performance difference between his 
and others' software."

Correct me if I am wrong:  where has anyone posted performance specs
between my XOR software and others, and are they material?  For 
instance, how many milliseconds difference is there between mine 
and some other program XORing a 3MB file?

I read a book once on the CIA.  Here is how they work.  They get 
some news agency they pay off in one country to post a bogus story. 
Then they have American news services pick up on it and start 
spreading it around in the US.

I hope you and your friends are having lots of fun.

Your routine is too pat.  It shows.

Don't people in these news groups think there are people who post 
in these news groups who have agendas:  commercial, political, etc.?

------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile  
Date: Wed, 08 Nov 2000 21:42:06 -0800

Scott Craver wrote:
> 
> Anthony Stephen Szopa  <[EMAIL PROTECTED]> wrote:
> >Scott Craver wrote:
> >>
> >>         We just *told* you.  It's a huge binary, not open, and
> >>         only runs on a single platform.
> >
> >You know why it is as large as it is.  Don't complain to me.  This
> >is the nature of the modern GUI interface.
> 
>         Um, no, it is not the GUI's fault.  Other people have tried
>         and failed to make a GUI program bloated as yours.  Others
>         have written much smaller utilities with GUIs.
> 
>         Bloat is almost always a result of bad programming, not of
>         an API.  Certain OS's and APIs do contribute more bloat,
>         but for the amazing record-breaking huge programs the bloat
>         comes from programmers who just don't know or care how to
>         keep a program from getting huge.  Extra unneeded resources,
>         leaving in all the debugging info, no attempt at
>         optimization, et cetera.
> 
> >Why do you need it open source?  It does what it is intended to do
> >and what it is claimed to do and does no more than it is supposed
> >to do and you can prove this by using it
> 
>         NO.  While I trust that you are not providing an evil
>         trojan horse (or accidentally distributing a 70KB binary
>         with 230KB of viruses attached,) it is NOT EVER the case
>         that merely using the program proves it works as
>         specified.
> 
>                                                         -S

You know all the facts?

We don't think so.  After all, how could you?

So what exactly are you trying to prove?

You've proved it:  you're not very smart to think we are not as 
smart as you.

------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: OT Re: Updated XOR Software Utility (freeware) Version 1.1 from 
Date: Wed, 08 Nov 2000 21:46:50 -0800

"Trevor L. Jackson, III" wrote:
> 
> Anthony Stephen Szopa wrote:
> 
> > By the way, Gore hasn't lost yet.  11/8/00  11:35 am PST
> 
> Hmmm.  I think this explains quite a bit.


This is a perfect example of the BS in this and many many other 
posts in this news group.

How could a statement of fact explain anything except the facts it
confirms?

You are a real laugh.

Ha ha ha...

You're expression is almost as funny as, "Very interesting."

Remember that one.

Ha ha ha.

------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from 
Date: Wed, 08 Nov 2000 21:52:19 -0800

Tom St Denis wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> > Scott Craver wrote:
> > >
> > > Anthony Stephen Szopa  <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> I, like you, marvel at how poor the programming had to have been
> such that
> > > >> 1.0 couldn't open up files in 2 different directories. :-)
> > >
> > > >With all your (all those in this news group) experience in
> > > >programming and encryption and aesthetics, it is I and not most of
> > > >you with the ideas and the software products and the strategy and
> > > >the GOOD will to get these fully functional products out to the
> > > >public.
> > >
> > >         You can't read.  Others have already written this utility
> and
> > >         made it available to the public.  I mean, even the source
> code.
> > >
> > >         And it's such a dinky little utility too.  Who's going to
> download
> > >         hundreds of kilobytes of executable code to perform a
> simple XOR?
> > >
> > >         Could someone please submit Mr. Szopa's executable to
> bloatbusters?
> > >         It's not like 7MB large, but it is huge for its intended
> purpose.
> > >         And the fact that, somehow, the first version couldn't open
> files
> > >         in separate directories (despite all the functionality
> available
> > >         in file open dialogs) really makes it funny.
> > >
> > >                                                                 -S
> >
> > Am I doing things just so you can rant and rave and waste all your
> > time?
> 
> Well I am sorry but an "xor utility" is not particularly usefull.
> 
> Tom
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.


You can do no more than what you can imagine yourself doing.

------------------------------

From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Thu, 09 Nov 2000 13:55:45 +0800

Tom St Denis wrote:
> 
> Perhaps you missed the boat, OTP's are not practical solutions!
> 

There are applications for which OTP's can be useful.  The only reason
why OTP's are not practical is the extremely onerous key distribution
problem involved in their use.  But some applications where, for
instance, data gets protected statically, e.g. files on your hard disk
with keys kept on removable media (kept in a secure location of course),
and for applications where only short messages need to be infrequently
transmitted, thus the key distribution operation is not so hard, e.g. by
exchanging removable media physically for example.

--
Rafael R. Sevilla <[EMAIL PROTECTED]>         +63 (2)   4342217
ICSM-F Development Team, UP Diliman             +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481

------------------------------

From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Does PGP sdk 1.7 have Prime Number Generator or Checking Functions?
Date: Thu, 09 Nov 2000 14:14:23 +0800

"P.C. Teo" wrote:
> 
> Does PGP sdk 1.7 have Prime Number Generator or Checking Functions?
> 

If you need this functionality, try the openSSL library.  AFAIK, there
is a big prime number generator there.  The cryptographic library
included in GNU Privacy Guard includes these functions as well, IIRC.

--
Rafael R. Sevilla <[EMAIL PROTECTED]>         +63 (2)   4342217
ICSM-F Development Team, UP Diliman             +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481

------------------------------

Date: Thu, 09 Nov 2000 07:37:48 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile  

"Trevor L. Jackson, III" wrote:
> 
> Richard Heathfield wrote:
> 
> > Mr Szopa's program is 315392 bytes in size after decompression. No
> > source code is provided. I know I'm not the only one to think this to be
> > the height of lameness. So, perhaps not unnaturally, I wondered (purely
> > in the spirit of scientific enquiry, as befits a sci. newsgroup) if it
> > were possible to write an even lamer program. I tried hard. But did I
> > succeed? That's for the scientific community to judge. (I was going to
> > save this till April 1st, but the moment seems ripe.)
> >
<snip>
> >
> > So, my question is: have I succeeded in outlaming the lamer? Only you
> > can decide.
> 
> Let's not be premature.  You've alluded to certain operational situations in which 
>data
> destruction may occur.  Have you fully investigated this behavior?  Are you able to 
>tell us
> what behavior to expect when the output file is the same as one or both of the input 
>files?

I'm delighted to be able to tell you that I haven't investigated this.
As a genuine snake-oil merchant, I can therefore tell you with a clear
conscience that I have no evidence that data destruction will occur in
this circumstance.

> 
> Also, how well does the repeat-shortest-file feature work when the shortest input 
>file has
> zero length?

It works extremely well. In fact, it works so well it doesn't want to
stop. That's quality for you!

> 
> Does the software check for input files that are all zero?  This check does not 
>offer an
> efficiency improvement, but it does make additional bloat available if you warn the 
>user
> about the insecurity of the output.

That's very true... I'll consider it for version 3.

> 
> If your program is more destructive or has more /witless/* features than his then 
>you have
> a good case for an affirmative response to your query.

Excellent. But it wasn't easy. Leaving the error checking out of the
file reading and writing was no easy thing for me. :-)

(Actually, I can't help thinking there might be a useful cryptographic
role for SNA-Coil (provided I back out the lameness add-ins, of course).
I'm not sure what that role might be, because it sure as hell isn't
encryption!)

-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

Date: Thu, 09 Nov 2000 07:42:21 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware

Tom St Denis wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   d <[EMAIL PROTECTED]> wrote:
> > Command line One Time Pad utility. Options: pad generation, randomness
> > testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
> > source and DOS executable included.
> >
> > Free download at <http://www.vidwest.com/otp/>
> >
> > Your bug reports/other feedback will be gratefully received.
> 
> Perhaps you missed the boat, OTP's are not practical solutions!


Are you sure about that? Sure, they are not practical solutions in
/many/ circumstances, but there are surely /some/ circumstances where
they could usefully be employed. I'm thinking particularly of "secret
agent behind enemy lines" scenarios.


-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

Date: Thu, 09 Nov 2000 07:51:14 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile  

Scott Craver wrote:
> 
> Richard Heathfield  <[EMAIL PROTECTED]> wrote:
> >>
> >>         [snip]  Amazing. Maybe you should run speed tests.
> >
> >I did (having first sorted out a test machine that I didn't mind
> >reinstalling from scratch if need be). They're about the same. Mr
> >Szopa's may even have a slight edge (I didn't spend any time trying to
> >make mine quick, after all). For speed, I have an ISO C version on the
> >Web.
> 
>         Does your program do the XOR a byte at a time or a long int
>         at a time?

A byte at a time. I was going for the lamest possible program, remember.

>         More importantly, does it fwrite and fread in
>         units of bytes, or larger?

Mine reads in bytes. I suspect that this is of much less importance,
because of buffering.

>         I'm interested in what Mr. Szopa's
>         program is actually doing, and if it's reading in units of
>         bytes rather than larger chunks there could be a major speed
>         difference.

I think your interest is misplaced, to be honest. And so is mine. Let's
just accept that it's snake oil, and move on, shall we?


-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: 9 Nov 2000 08:40:36 +0100

In article <[EMAIL PROTECTED]>,
Dido Sevilla  <[EMAIL PROTECTED]> wrote:
>Tom St Denis wrote:
>> 
>> Perhaps you missed the boat, OTP's are not practical solutions!
>> 
>
>There are applications for which OTP's can be useful.  The only reason
>why OTP's are not practical is the extremely onerous key distribution
>problem involved in their use.  But some applications where, for
>instance, data gets protected statically, e.g. files on your hard disk
>with keys kept on removable media (kept in a secure location of course),
>and for applications where only short messages need to be infrequently
>transmitted, thus the key distribution operation is not so hard, e.g. by
>exchanging removable media physically for example.

If you use a OTP, the key will be as large as the data you want to
protect.  Now, if you want to protect data on your disk using OTP,
storing the keys on "removable media kept in a secure location", then
you might as well transfer your sensitive data to that removable media
instead and store it in a safe location: the encrypted data will be
inaccessible without the OTP key on the removable media anyway, and if
you lose that key, you might as well have lost your data.  Right?

The best use of a OTP is if you meet someone with whom you'll later need
to exchange sensitive data: then exchange a OTP key, to later be used
to encrypt that sensitive data.

Using OTP to encrypt your local harddisk is quite useless.


-- 
================================================================
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch

------------------------------

From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Authentication and taking credit (was Re: Protocol)
Date: Thu, 09 Nov 2000 09:23:40 GMT

rosi wrote:
> >David Wagner wrote:
> >>
> http://gatekeeper.dec.com/pub/DEC/SRC/technical-notes/abstracts/src-tn-1998-
> 007.html

>     Since you two have obviously read it as well, I would like to ask: Does
> it seem to
> you that different levels of semantics are mixed up good? Any opinions would
> be
> appreciated.

What he's basically saying is that some authentication protocols have
this property: it's hard for me to pretend to be you, but it's not so
hard for me to tamper with *your* session so that you unwittingly
pretend to be me.  If what you're doing during your session is
submitting the prize-winning entry to a competition, I can steal the
credit.

I'm arguing that this is best solved on a different protocol level than
authentication.  But I'm not sure this is the same as saying that
different levels of semantics are "mixed up good"!  And I certainly
think the issue is well worth raising and discussing.

Incidentally, I wrote earlier that there's no point in trying to prevent
credit-stealing if your protocol isn't encrypted, but that isn't quite
true.  For example, a protocol that committed to a message with a hash
before sending it could also defeat credit-stealing.
-- 
  __
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/

------------------------------

From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Reply-To: [EMAIL PROTECTED]
Date: Thu, 09 Nov 2000 10:34:42 GMT

On 9 Nov 2000 08:40:36 +0100, Paul Schlyter <[EMAIL PROTECTED]> wrote:

[...]

>If you use a OTP, the key will be as large as the data you want to
>protect.  Now, if you want to protect data on your disk using OTP,
>storing the keys on "removable media kept in a secure location", then
>you might as well transfer your sensitive data to that removable media
>instead and store it in a safe location:

You could use it for secret splitting.  Encrypt the disks and place
them in sperate secure locations.



-- 
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

------------------------------

From: "Martin Otten" <[EMAIL PROTECTED]>
Subject: RSA security
Date: Thu, 9 Nov 2000 11:50:49 +0100

Hello,

I want to use RSA for encryption. The problem is this encryption must be
very fast ( I have to do it 20 times a second for packets about 256 byte,
and this should not take more than 1% of a modern CPU). The security must
not be very strong, since an encrypted session is only <25 minutes long,
after this time the security of the data is no longer needed. So i want to
choose the smalles needed bit length for the key to get a good performance.
My question : how many bits must my RSA key have, to proof an attack with
normal hardware ( no Cray or 256 station linux cluster) for 60 minutes ?
Would 64 bit be enough ?

Thank you,
Martin





------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Nov 2000 10:44:14 GMT

Paul Schlyter <[EMAIL PROTECTED]> wrote:

: [...] if you want to protect data on your disk using OTP,
: storing the keys on "removable media kept in a secure location", then
: you might as well transfer your sensitive data to that removable media
: instead and store it in a safe location: the encrypted data will be
: inaccessible without the OTP key on the removable media anyway, and if
: you lose that key, you might as well have lost your data.  Right?

There's a bit of a difference - the OTP solution requires an attacker to
get hold of two physically separated objects in order to read your
information.

You could encrypt with many OTPs and place them in different locations
to cause an attacker more problems.

I'm not sure I'd recommend doing any of this - but using an OTP is a bit
different from putting your HDD in a safe.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Free gift.

------------------------------

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Reply-To: [EMAIL PROTECTED]
Date: Thu, 9 Nov 2000 10:50:19 GMT

d <[EMAIL PROTECTED]> wrote:

: Command line One Time Pad utility. Options: pad generation, randomness
: testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
: source and DOS executable included.

: Free download at <http://www.vidwest.com/otp/>

: Your bug reports/other feedback will be gratefully received.

If you want a feature suggestion, add a (possibly OTP-based?) signature
routine.  Without authenticity, OTPs are vulnerable to active attackers.

Also, I'm not sure about the market for: "For a reliable and timely
source of randomness, /unique/ CDROMs containing over 5 billion
statistically random bits, delivered in tamper-proof seals."

You may have to present yourself as a trusted agency to sell very many of
these.  You will know where you shipped each CD to.
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Florist: Petal pusher.

------------------------------


** 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
******************************

Reply via email to