Cryptography-Digest Digest #801, Volume #13 Sun, 4 Mar 01 21:13:01 EST
Contents:
Re: Random numbers from your sound card ("CMan")
Re: super strong crypto, phase 3 (John Savard)
Re: Dummy question about DES (John Savard)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Anthony
Stephen Szopa)
Re: The Big Breach (book) available for download ("Ridge Cook")
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily cracks encryption
...?) (nemo outis)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Benjamin
Goldberg)
Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER (Johan M.
Olofsson)
Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER (Johan M.
Olofsson)
Re: OverWrite freeware completely removes unwanted files fromharddrive ("Tom St
Denis")
Re: => FBI easily cracks encryption ...? ("Open FleshWound")
Re: The Foolish Dozen or so in This News Group (Paul Rubin)
Re: Again on key expansion. (Paul Crowley)
----------------------------------------------------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Random numbers from your sound card
Date: Sun, 4 Mar 2001 18:19:45 -0700
I will repeat...
Add a few of those ridiculous AOL CD's that are sent in the mail by the
millions. Just suspend them in front of a fan or drop them from stings into
a fish tank with all those bubbles pushing them around. Then use your web
cam and some whitening software like Yarrow to get all the random data you
could ever possibly need. You could have entropy coming out of you ears!!
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
>
> > Also, it could be intresting to try to do the same stuff with TV
> > cards, it should give much more data and thus speed the whole
> > thing up, not having a TV card and any knowledge about the APIs
> > used with them, it's problematic for me to test this out, but
> > you're welcome.
>
> You can create massive quantities of unreasonably volatile data for less
than
> $100. At the pet store buy an aquarium with an over-large pump and extra
air
> stones for under $50. With this equipment you can create a high speed
version of
> the lava lamp. At the computer store buy a parallel port webcam for under
$40.
> With the extra $10 buy a bright light and shine it on the tank (you want
reflection
> of the light not transmission, so put it on the same side of the tank as
the
> camera.
>
> If you have extra cash buy a mirror the size of the tank and put it
opposite the
> camera and the light. If you are rich buy two mirrors the size of the
long side of
> the tank, with which you make a hall-of-mirrors, and move the camera &
light to the
> end of the tank.
>
> Yes, you need to fill the tank with water and plug in the air pump.
>
> Operating the webcam at video speeds gives an unreasonably large volume of
volatile
> bits. Of course an adversary can chill the output with a clothes pin on
the air
> line, but for raw TRNG it works for me.
>
> Your Randomness May Vary. ;-)
>
>
>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: super strong crypto, phase 3
Date: Mon, 05 Mar 2001 01:17:00 GMT
On Sun, 04 Mar 2001 22:14:20 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>It's meant to prevent any attack based on analysis of a single
>block. Changing masks can be used, but one doesn't want to
>base the masks on any sort of potentially analyzable algorithm.
Well, although one certainly could send a fresh mask every now and
then, repeatedly encrypting a mask by some algorithm before each use,
as opposed to just using the same mask each time for the same number
of times, does not seem to me to be making things worse.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dummy question about DES
Date: Mon, 05 Mar 2001 01:14:11 GMT
On Sun, 04 Mar 2001 16:34:47 GMT, [EMAIL PROTECTED] (Jan
Panteltje) wrote, in part:
>If I have a des system with a secret key, is it in any way possible
>to find out the key if I can send data (challenges) to that system
>and read the reply?
DES is believed to be resistant to chosen-plaintext attacks. None is
known that provides a significant advantage over brute force against
simple known plaintext.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Sun, 04 Mar 2001 17:20:53 -0800
Benjamin Goldberg wrote:
>
> Szopa, you are an utter moron. Didn't you read what I wrote?
>
> A sucessful close operation merely means that the entry in the list of
> open files is removed.
>
> Sure, your program "closes" sucessfully.
>
> What does that have to do with disk writes?
>
> You call the fclose() instructioction, which in turn calls close() on
> the file descriptor. It's removed from the list of open files. The
> dirty pages remain in cache. (The OS will write them out, eventually,
> but nothing has yet happened to make this urgent.) You open the file
> again. This creates a new entry in the list of open files, and returns
> an index to that list (the file descriptor). IIRC, This becomes the
> _fildes element of the (FILE*) struct. You write to the file. The OS
> says to itself, hey, I still have some dirty pages in cache for that
> file, and so your write() operation modifies the contents of those
> pages. You call close again. It successfully removes the entry from
> the list of open files. It therefor returns a 'sucess' value. etc,
> etc.
>
> At no point is close returning sucess when it actually failed; however,
> at no point does sucess imply an actual hardware write operation.
>
> --
> The difference between theory and practice is that in theory, theory and
> practice are identical, but in practice, they are not.
Check this out.
"Closes a stream.
fclose closes the named stream. All buffers associated with the
stream are flushed before closing. System-allocated buffers are
freed upon closing. Buffers assigned with setbuf or setvbuf are
not automatically freed. (But if setvbuf is passed null for the
buffer pointer it will free it upon close.)"
AND
"Remarks
The fclose function closes stream. _fcloseall closes all open
streams except stdin, stdout, stderr (and, in MS-DOS�, _stdaux
and _stdprn). It also closes and deletes any temporary files
created by tmpfile. In both functions, all buffers associated
with the stream are flushed prior to closing. System-allocated
buffers are released when the stream is closed. Buffers assigned
by the user with setbuf and setvbuf are not automatically released."
Tell us: when an OS flushes its buffers associated with an output
stream what does the OS do to make sure that the data in those buffers
is not lost since there is an immediate write command just before the
fclose command?
Here is the code sequence:
write to disk (this commands to write the data waiting in the
associated buffers to disk.)
fclose() (this will among other things flush the associated output
stream buffers)
So if the write operation has not taken place yet the buffers are now
going to be flushed, don't you think the OS better hurry up and write
the data contained in the buffers to the disk?
What you are saying is that the OS knows that the file is going to be
subsequently and immediately reopened and overwritten and therefore it
knows that it does not need to and does not flush the buffers.
If it knows so much you would also agree that it must know enough not to
close the file either. Isn't this consistent with your theory of low
level OS / hardware operation?
Or are you saying that although it knows it does not need to close the
file and that all this hanky panky is being done for operation
optimization that it goes ahead and dose close the file and does not
flush the buffers, perhaps just to spite me.
Don't you think you are about to have a nervous breakdown?
Well?
Prove to us who the "utter moron" is, again, please.
You can start by explaining to all of us what it means to FLUSH the
buffers.
------------------------------
From: "Ridge Cook" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: The Big Breach (book) available for download
Date: Mon, 05 Mar 2001 01:22:48 GMT
Thanks Sam-
Have heard only faint rumblings in the US, I'll take a look tonight.
FYI, found a very interesting site which would have tie ins with the book.
www.iwar.org
Yours-
Ridge
=========
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:QJso6.9210$[EMAIL PROTECTED]...
> The book Big Breach (by R.Tomlinson, ex-MI6) is available for download at
> the URLs below.....It's caused a lot of controversy in England, so is
> probably worth a read ;)
>
> Just so happens to have been released a week after I ordered my copy :(
>
> --
> Regards,
>
> Sam
> http://www.scramdisk.clara.net/
>
>
>
> Acrobat PDF
> Zipped - http://thebigbreach.com/download/bbpdf.zip
> Unzipped - http://thebigbreach.com/download/bbpdf.pdf
>
> MS Word
> Zipped - http://thebigbreach.com/download/bbword.zip
> Unzipped - http://thebigbreach.com/download/bbword.doc
>
> Text
> Zipped - http://thebigbreach.com/download/bbtxt.zip
>
>
>
------------------------------
Crossposted-To: alt.security.pgp,talk.politics.crypto
From: [EMAIL PROTECTED] (nemo outis)
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily cracks
encryption ...?)
Date: Mon, 05 Mar 2001 01:23:37 GMT
Think or thwim, right?
I'm not talking about the current political situation inGermany; I'm talking
about how easily and quasi-legally a constitution can be subverted,
*particularly if contains repressice mechanisms.* Those mechanisms can easily
be turned to sinister purposes. It seems that the constitution you describe
contains the seeds of its own destruction. All it needs is the catalyst
provided by the right (or wrong!) people at the right time.
The constitution of the old USSR would bring tears to your eyes it was so
lofty and noble. Only problem: it was utterly ignored.
Regards,
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Joe H. Acker) wrote:
>And think yourself. But think...
>
>Regards,
>
>Erich
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 01:23:55 GMT
Anthony Stephen Szopa wrote:
[snip]
> Source #1:
>
> "The disk cache is also used for write operations. The Windows NT
> file system (NTFS) doesn't write data to the hard disk immediately.
> It waits for system idle time so as not to impact the responsiveness
> of the system. Data writes are stored in the memory cache until
> they are written to disk. Often, especially in transaction-oriented
> systems like databases, write data in the cache will be superseded
> by new changes before being written from the cache to the hard disk
> meaning that the write cache has completely eliminated the need to
> write that data to disk."
Ahh, you're finally beginning to learn.
> Source #2:
>
> "fclose
>
> Syntax
>
> #include <stdio.h>
> int fclose(FILE *stream);
>
> Description
>
> Closes a stream.
>
> fclose closes the named stream. All buffers associated with the
> stream are flushed before closing. System-allocated buffers are
> freed upon closing. Buffers assigned with setbuf or setvbuf are
Curious. What are "system-allocated" buffers? Are they buffers the
library (and, indirectly, the program) has allocated, and associated
with the FILE* object, or are they device-driver buffers?
When writing to FILE* objects, you use printf, fprintf, fwrite, etc, to
put data into a buffer which is pointed to by the FILE* object, and when
that buffer gets full (or when fflush is called), the stdio library uses
write() to send the data to the file descriptor.
It makes perfect sense for fclose to cause the data in the buffer
mentioned above to write()n to the file descriptor, just before the file
descriptor is close()d.
However, the operating system also keeps buffers. Nothing is said about
fclose() affecting the OS buffers.
> not automatically freed. (But if setvbuf is passed null for the
> buffer pointer it will free it upon close.)
>
> Return Value
>
> fclose returns 0 on success. It returns EOF if any errors were
> detected."
> ------------------------------------------------------------------
>
> Source #3:
>
> "fclose, _fcloseall
>
> Closes a stream (fclose) or closes all open streams (_fcloseall).
>
> int fclose( FILE *stream );
> int _fcloseall( void );
>
> Function Required Header Compatibility
> fclose <stdio.h> ANSI, Win 95, Win NT
> _fcloseall <stdio.h> ANSI, Win 95, Win NT
>
> Return Value
> fclose returns 0 if the stream is successfully closed. _fcloseall
> returns the total number of streams closed. Both functions return
> EOF to indicate an error.
>
> Remarks
> The fclose function closes stream. _fcloseall closes all open
> streams except stdin, stdout, stderr (and, in MS-DOS�, _stdaux
> and _stdprn). It also closes and deletes any temporary files
> created by tmpfile. In both functions, all buffers associated
> with the stream are flushed prior to closing. System-allocated
> buffers are released when the stream is closed. Buffers assigned
> by the user with setbuf and setvbuf are not automatically released."
Same thing. What buffers are being talked about here? Program level
buffers, or OS level buffers? It sounds like program level buffers to
me.
> You cannot get away with half truths or unsupported statements or
> retelling poorly understood accounts.
hahahahhahaha. And what exactly is it your doing? Except for Source
#1, what buffers are being flushed is quite ambiguous. If you
understood the stdio library, and the difference between what a FILE* is
and a filedes_t is, you would conclude that it's program-level buffers
which are getting flushed. "System-allocated" in this context, means
things which were allocated when you did fopen (as opposed to tihngs you
allocated with malloc, and then used with setbuf or setvbuf).
> This matter is still up in the air. No one has nailed it down yet.
> The matter being: even when using fclose(), repeated writes ARE NOT
> done due to utilization of cache optimizations.
>
> Now, as I said, I close the file using the fclose() function after
> each overwrite pass.
>
> As indefinitive as the above three sources are, they are all rather
> vague and ambiguous, it does seem arguable since that when fclose()
> is used since all buffers associated with the stream are flushed,
> etc. that a forced physical write seems highly plausible under these
> circumstances.
Nope. It only appears that way to someone who doesn't understand that
there are stdio buffers, and device driver buffers, and even buffers
inside the hdd itself. Fclose only dumps the stdio buffers, by using
write(). It doesn't do a thing for the other levels.
> Not one of the sources above makes this clear one way or the other.
> Nor has any of you.
We have, we have. fclose doesn't do anything to flush out the OS
buffers. It does write() out it's data from the FILE* buffer to the
filedes, and then calls close(), and does a bit of other library level
cleanup. But write() and close() don't force hardware writes.
> What I would like to know is if there is a way to flag a physical
> write operation to the hard drive when it actually takes place?
Try looking up sync() or fsync(). A word of warning, though: Many of
the M$ implementation of these are flawed. Since there is no
programatic way to observe any difference between a successful, properly
implemented, fsync, and a noop, fixing this is, for M$, a very very LOW
priority.
> Staring at the hard drive access LED is not very reliable or
> scientific.
>
> I am still waiting for some DEFINITIVE source with DEFINITIVE
> documentation to decide this matter one way or the other in
> specific cases.
>
> I think making a determination regarding the fclose() could settle
> this matter if it is proven that issuing an fclose() will force a
> write operation.
Fclose forces a write() and a close(). But neither write() nor close()
force a hardware write operation.
> If this cannot be proven then we are still unsure. I know someone
> knows. We must find this someone. And have them give us some sort
> of acceptable proof.
Anyone who has worked on (or looked at) the stdio source can
definitively tell you that fclose() causes a write() and a close().
However, what you really want is for someone to tell you that write() or
close() force hardware writes. They don't.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: Johan M. Olofsson <[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,dk.snak.mudderkastning,rec.scouting.issues
Subject: Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER
Date: 4 Mar 2001 19:26:12 -0600
Beeftain wrote:
> "Johan M. Olofsson" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> > Beeftain wrote:
> >
> > > "Johan M. Olofsson" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> > > > Beeftain wrote:
> > > >
> > > > > "alexplore" <alexplore@alexplore> wrote in message
>news:97jbuk$if6$[EMAIL PROTECTED]...
> > > > > >
> > > > > > Beeftain <[EMAIL PROTECTED]> wrote in message
> > > > > > news:97j635$1sli$[EMAIL PROTECTED]...
> > > > > > > "alexplore" <alexplore@alexplore> wrote in message
> > > > > > news:97j1m4$687$[EMAIL PROTECTED]...
> > > > > > > >
> > > > > > > > Beeftain <[EMAIL PROTECTED]> wrote in message
> > > > > > > > news:97j0ii$1jf5$[EMAIL PROTECTED]...
> > > > > > > > > Pippelip gokkelok!
> > > > > > > >
> > > > > > > > You must be mentally ill like Linda Gore!
> > > > > >
> > > > > > Linda Gore is a mental patient on the "crazies groups"...
> > > > > > Very mentally ill... married 4 times... does a lot of
> > > > > > "psychiatric medications"... for 23 years in fact...
> > > > > > that and fucking drunks and posting about how to stuff their
> > > > > > limp dicks up her cunt.
> > > > > >
> > > > > > "Diagnossing" her son.... sees that he needs a lot of psychiatric drugs
> > > > > > too...
> > > > > >
> > > > > > Disgusting piece of shit! Someone out there will be husband #
> > > > > > 5 sooner or later.... always a horny asshole that will fuck anything...
>Ask
> > > > > > Igor Chudov and Yelena Purdunkova about that :)
> > > > >
> > > > > Who are they?
> > > > >
> > > > > > > Well, Al Gore _is_ mentally ill...
> > > > > >
> > > > > > Not so much as his wife "Tipper" (hell kind of name is THAT!)
> > > > >
> > > > > She discovered these Parental Advisory-stickers. It's narrow-minded.
> > > > >
> > > > > > > not very less than George Bush.
> > > > > >
> > > > > > at least his wife ain't eating head-drug pills like "Tipper" :)
> > > > > > or Igor Chudov...
> > > > >
> > > > > No, but any wife of Bush must be brainwashed. Bush is a f...... maniac.
> > > > >
> > > > > Which group are you writing in?
> > > >
> > > > All of them, of course.
> > >
> > > The original, then.
> >
> > Beats me. I'm reading in soc.org.kkk like most good Democrats.
>
> Is this a place for fascists or anti-fascists? People against KKK?
Al Gore campaign workers.
------------------------------
From: Johan M. Olofsson <[EMAIL PROTECTED]>
Crossposted-To:
alt.support.depression.medication,soc.culture.russian,soc.org.kkk,dk.snak.mudderkastning,rec.scouting.issues
Subject: Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER
Date: 4 Mar 2001 19:27:04 -0600
c_h_r.i.s wrote:
> "Beeftain" <[EMAIL PROTECTED]> wrote:
> >"Johan M. Olofsson" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> >> Beeftain wrote:
> >>
> >> > "Johan M. Olofsson" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> >> > > Beeftain wrote:
> >> > >
> >> > > > "alexplore" <alexplore@alexplore> wrote in message
>news:97jbuk$if6$[EMAIL PROTECTED]...
> >> > > > >
> >> > > > > Beeftain <[EMAIL PROTECTED]> wrote in message
> >> > > > > news:97j635$1sli$[EMAIL PROTECTED]...
> >> > > > > > "alexplore" <alexplore@alexplore> wrote in message
> >> > > > > news:97j1m4$687$[EMAIL PROTECTED]...
> >> > > > > > >
> >> > > > > > > Beeftain <[EMAIL PROTECTED]> wrote in message
> >> > > > > > > news:97j0ii$1jf5$[EMAIL PROTECTED]...
> >> > > > > > > > Pippelip gokkelok!
> >> > > > > > >
> >> > > > > > > You must be mentally ill like Linda Gore!
> >> > > > >
> >> > > > > Linda Gore is a mental patient on the "crazies groups"...
> >> > > > > Very mentally ill... married 4 times... does a lot of
> >> > > > > "psychiatric medications"... for 23 years in fact...
> >> > > > > that and fucking drunks and posting about how to stuff their
> >> > > > > limp dicks up her cunt.
> >> > > > >
> >> > > > > "Diagnossing" her son.... sees that he needs a lot of psychiatric drugs
> >> > > > > too...
> >> > > > >
> >> > > > > Disgusting piece of shit! Someone out there will be husband #
> >> > > > > 5 sooner or later.... always a horny asshole that will fuck anything...
>Ask
> >> > > > > Igor Chudov and Yelena Purdunkova about that :)
> >> > > >
> >> > > > Who are they?
> >> > > >
> >> > > > > > Well, Al Gore _is_ mentally ill...
> >> > > > >
> >> > > > > Not so much as his wife "Tipper" (hell kind of name is THAT!)
> >> > > >
> >> > > > She discovered these Parental Advisory-stickers. It's narrow-minded.
> >> > > >
> >> > > > > > not very less than George Bush.
> >> > > > >
> >> > > > > at least his wife ain't eating head-drug pills like "Tipper" :)
> >> > > > > or Igor Chudov...
> >> > > >
> >> > > > No, but any wife of Bush must be brainwashed. Bush is a f...... maniac.
> >> > > >
> >> > > > Which group are you writing in?
> >> > >
> >> > > All of them, of course.
> >> >
> >> > The original, then.
> >>
> >> Beats me. I'm reading in soc.org.kkk like most good Democrats.
> >
> >Is this a place for fascists or anti-fascists? People against KKK?
>
> NORMAL PEOPLE AGAINST HEADCASES AND PSYCHIATRIC MED JUNKIES
> LIKE LIKDA GORE THE PROZAC WHORE. EXCEPT DESIPRAMINE OF COURSE
> I TAKE 200MG/DAY. MY HARD-ONS LAST FOR DAYS
You need a woman.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite freeware completely removes unwanted files fromharddrive
Date: Mon, 05 Mar 2001 01:28:38 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Closes a stream.
>
> fclose closes the named stream. All buffers associated with the
> stream are flushed before closing. System-allocated buffers are
> freed upon closing. Buffers assigned with setbuf or setvbuf are
> not automatically freed. (But if setvbuf is passed null for the
> buffer pointer it will free it upon close.)"
These are "buffers in the C lib" not in the OS. The C lib doesn't talk
directly to the HD, the OS does. Obviously you have never worked on a nix
platform. You can here the HD going at random times...
Tom
------------------------------
From: "Open FleshWound" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sat, 3 Mar 2001 03:01:09 -0700
"Frodo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>
> Jim Taylor <[EMAIL PROTECTED]> wrote:
> >
> > Sometimes I wonder about these groups. Are you all drug
> dealers or
> > something? What would be so bad about the FBI or NSA, with
> considerable
> > effort and expense, being able to decrypt a PGP message?
> Aren't they the
> > good guys trying to protect _us_ against spies, terrorists and
> organized
> > crime?
>
> Sometimes. Other times they're trying to slander people they
> consider subversive, as J. Edgar Hoover did to Martin Luther
> King and John Lennon.
John Lennon was subversive ...
>
> --
> But history reveals that time and again, the FBI, the military
> and other law enforcement organizations have ignored the law and
> spied on Americans illegally, without court authorization.
> Government agencies have subjected hundreds of thousands of law-
> abiding Americans to unjust surveillance, illegal wiretaps and
> warrantless searches. Eleanor Roosevelt, Martin Luther King Jr.,
> feminists, gay rights leaders and Catholic priests were spied
> on. The FBI used secret files and hidden microphones to
> blackmail the Kennedy brothers, sway the Supreme Court and
> influence presidential elections.
> --
>
> http://www.geocities.com/CapitolHill/9564/goats.html#constitution
> http://www.geocities.com/CapitolHill/9564/prvsntch.html
>
> > If they had an encrypted message in their hands detailing a
> plan to
> > nuke your city, none of you would want them to be able to
> decrypt it?
>
> Under those specific circumstances, I think they should be
> permitted to decrypt it.
> But they can't. They don't have the capability.
And what happens when someone or group
nukes the city whithout conversing via email,
encrypted or otherwise ?
McVeigh didn't use encryption ...
The World Trade Center blew up without the use of encryption ...
Ted Kazinsky didn't use encryption ...
WACO burned without the use of encryption ...
etc ...
>
> > As long as the cost for decrypting a PGP message is too high
> to go looking
> > for petty crimes, so what if they could decode one if they
> wanted to? They
> > would never let the cat out of the bag that they had the
> ability for even
> > someone like Hanssen, so I think all your porno is safe.
>
> > Don't get me wrong, I use and like PGP, but it's not the NSA
> and FBI that I
> > worry about. I simply want to keep some things private from co-
> workers, ISP
> > employees and the like, and there's no doubt that PGP works
> very well for
> > that.
>
> In Germany the Nazis came first for the Communists; and I didn't
> speak up because I wasn't a Communist.
> Then they came for the Jews, and I didn't speak up because I
> wasn't a Jew.
> Then they came for the trade unionists, and I didn't speak up
> because I wasn't a trade unionist.
> Then they came for the Catholics, and I didn't speak up because
> I was a Protestant.
> Then they came for me, and by that time there was no one left to
> speak for me.
>
> Pastor Martin Niemoller
>
>
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: 04 Mar 2001 18:01:46 -0800
David Hopwood <[EMAIL PROTECTED]> writes:
> No, this time it's not Bill's fault. Write-behind caching is the
> expected default behaviour on any reasonable operating system (and
> besides, the disk controller still caches even if the operating system
> does not).
And the disk DRIVE still caches if the controller does not, and it may
flush its caches to places on the media where software can't reach, but
forensic data recovery can.
------------------------------
Subject: Re: Again on key expansion.
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Mon, 05 Mar 2001 01:54:53 GMT
[Note: The procedure described in John Kelsey, Bruce Schneier, Chris
Hall, and David Wagner: "Secure Applications of Low-Entropy Keys",
http://www.counterpane.com/low-entropy.html, has been referred to as
"Schneier's method" in this discussion. This is partly my fault and
it's very unfair on the other authors! So I've searched-and-replaced
"Schneier" with "SALEK" throughout, even in text not by me.
Hope this doesn't cause offense...]
"Cristiano" <[EMAIL PROTECTED]> writes:
> > > I have thought about to use the elliptic curve (as posted in other
> message),
> > > but I have not received any comment...
> > What's the advantage of this method over the method described by
> >SALEK?
> If "strength" of SALEK and "entropy" of Benjamin are the same
> thing, with SALEK's method I need 2^(13+1) iterations to add 13
> bits of entropy, with my method I need only 16 iterations. In my new
> implementation (with miracl), SALEK's method takes 1.26 s, my
> method takes only 0.079 s (about 16 times faster). Moreover, a single
> iteration of a brute force attack will takes (in my implementation)
> only 76 micro seconds for the SALEK's method and 5 ms for my
> method: to try 1,000,000 keys with the former it will takes only 76 s,
> but with the latter it will takes 1h23m!
Eh? There's only one procedure in SALEK: take a passphrase and hash
it repeatedly. It's the same procedure whether you're stretching a
passphrase for the first time, or stretching a passphrase entered by a
user before testing whether it's the correct passphrase. Thus, if
you're using the same implementation on the same hardware, it can't
take 1.26 seconds in one instance and 76 microseconds in another.
The strength gained by either method is measured by how long it takes
to test if a particular passphrase is the correct one. This is the
time taken for a single iteration of a brute force attack, and *also*
the time before a user knows if they've entered the correct
passphrase. The "t" parameter should be scaled until this time is
about a second, so the user isn't annoyed by waiting. Two methods
that both take a second offer the same strength.
The only time this isn't so is if the attacker can find a "shortcut"
way to stretch the key. SALEK is accompanied by a proof that if the
hash function is strong then there is no such shortcut. Finally,
SALEK is simpler to describe, analyse and implement.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
