Cryptography-Digest Digest #816, Volume #13 Tue, 6 Mar 01 08:13:01 EST
Contents:
Re: super strong crypto, phase 3 (Mok-Kong Shen)
Re: => FBI easily cracks encryption ...? (Matthew Montchalin)
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
(Mitch)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH) ("Mark Livingstone")
Re: PKI and Non-repudiation practicalities ("Lyalc")
Re: Monty Hall problem (was Re: philosophical question?) (John Rickard)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: super strong crypto, phase 3
Date: Tue, 06 Mar 2001 11:26:56 +0100
John Savard wrote:
>
> Mok-Kong Shen<[EMAIL PROTECTED]> wrote, in part:
>
> >It seems that you use a block cipher of size 1024 bits and
> >a key of 1024 bits. Do I get that right?
>
> No. Although the message is divided into blocks of 1024 bits, my
> example is built around a block cipher with a 128 bit block and a 128
> bit key. The same key is used to encipher eight blocks of the message,
> one of which is a new key, before switching. So it is closely based on
> Douglas Gwyn's proposal.
Thanks. The other question of mine was whether it might not
be better to vary keys but without transmitting any new key
informations online.
M. K. Shen
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 02:33:48 -0800
On Mon, 5 Mar 2001, Mxsmanic wrote:
|And even that isn't necessary. The spooks can just park a van across
|the street from your house and watch what you type on your screen.
|That would be a million times cheaper than trying to break your
|encryption the hard way.
As a matter of fact, that happened to me recently. I walked over to
the car (a van) across the street and asked them what they were doing,
and they showed me the screen that they were using. Rather brazen
of them, I guess. Of course, that doesn't prove to me it was *my*
computer they were scoping out. Could have been anybody's in the
area. And it still puzzles me what they think they are achieving
by going around telling people that happen to walk up and ask them;
it sure isn't very surreptitious. Isn't surveillance supposed to
be more effective if it is surreptitious?
------------------------------
From: Mitch <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
Reply-To: Mitch <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 10:20:35 +0000
On Mon, 05 Mar 2001 07:06:34 GMT, Vince Adams enlightened us all with:
>How do you say it in the UK? Go bugger yourself wanker <g>.
o will the gentleman banker please sample his wares
o Genesis 9:7
HTH
--
Mitch
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 03:45:02 -0800
"Douglas A. Gwyn" wrote:
>
> Anthony Stephen Szopa wrote:
> > How can we consider your less than considered opinion when you
> > clearly ignore the very post you are responding to: "in binary
> > append mode."
>
> In append mode you are *clearly* not overwriting existing data.
> I was trying to help you understand what you need to do to ensure
> the best shot at getting actual disk overwriting.
>
> > Secondly, the 156 sec 1GB overwrite does not pertain since he did
> > not even tell us anything about the code that was written that
> > carried out this operation.
> > Yet you seem to give his account all credibility not even knowing
> > this information.
>
> I don't need to know the details, since it was obvious from his
> post what was going on, namely caching.
>
> > And no, it wasn't the point. His exercise in futility is not the
> > point of this thread.
> > The point is whether or not Ciphile Software's OverWrite Security
> > program makes the 27 overwrites as claimed.
>
> If this thread had a recent point, it was that it is not as easy
> as you think to guarantee real overwrite of data sectors on disk.
>
> > Close but not quite. It is "r+b" What do you perceive now?
>
> Sorry, that's what I meant ("r+w" is not a standard mode).
>
> > Talk about refusing to listen? Geeeze.
>
> ? I was explaining what needs to be done to maximize the chance
> that real overwriting would occur. If that supports your cause,
> fine. I never *said* you didn't do that. What have you done to
> ensure that system block buffers get flushed to disk between
> overwrites?
I am not going to say you are entirely to blame.
But I programmed "r+b". I meant to say open file for update in
binary mode.
Okay. That is what you meant and this is what I meant and did
all along: "r+b" mode. It opens the file for update at the
beginning of the file.
In any event, I updated the OverWrite software by adding one simple
line of code that is only 8 characters long for each pass.
Now when you run it you can see it go to the hard drive 27 times
just by watching your hard drive LED access light and perhaps by
listening to your hard drive as well. Choose a file about 2 - 6
KB for starters. Depending on the file size it may access the hard
drive more than this: it appears that it works in multiples of 27
but they can get hard to count. Depending on the file size some
parts of multiple accesses for a single pass on larger files can
be pretty short.
I could see the hard drive access LED clearly lighting up 27 times.
I had to cup my hand over the LED to make it dark enough so I could
see it clearly. Can't hear much on my one system's hard drive but
I can sure hear it on my other system's hard drive.
You can download Ciphile Software's OverWrite Security Utility
(UPDATE) Version 1.1 at http://www.ciphile.com now.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 03:48:56 -0800
those who know me have no need of my name wrote:
>
> <[EMAIL PROTECTED]> divulged:
>
> >I would think it depends on your file system, too. For example, on a
> >CD-R file system, you can only write to each location once, so you
> >obviously *cannot* overwrite 27 times.
>
> even that is problematical -- consider udf based access. (which, quickly,
> allows you to treat a cd-r as if it were a read-write device. as you might
> quickly guess, each block can only be written once, so a re-write has the
> effect of associating new blocks with the file.) such a file overwrite
> program would succeed, in no case returning an error to the program, if
> there were a sufficient number of unassociated blocks when it began.
>
> >Only in straightforward implementations of a file system can you
> >*ensure* the same blocks get overwritten.
>
> nope, not even then. see the subthreads regarding block-level replacement
> by the hdd itself.
>
> >Douglas A. Gwyn wrote:
> >> if the file is opened
> >> for writing in the default mode, it gets truncated to 0 length and
> >> all its previous data blocks are returned to the block-buffer pool.
> >
> >Perhaps under UNIX. I thought this was a Windows program we were talking
> >about.
>
> windows isn't that much different, with respect to having a cache for that
> purpose.
>
> --
> okay, have a sig then
The softare is for hard drives and floppies. Might work on other
media possibly, like zip drives, for instance.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 03:58:05 -0800
Richard Herring wrote:
>
> In article <[EMAIL PROTECTED]>, Crypto Neophyte
>([EMAIL PROTECTED]) wrote:
> > On Sun, 4 Mar 2001 17:22:02 -0600, Anne & Lynn Wheeler wrote
> > (in message <[EMAIL PROTECTED]>):
>
> > > however, overwriting 27 times is a little harder since straightforward
> > > overwrite is likely to just be updating buffer records. frequently multiple
> > > overwriting passes consists of different combinations of ones
> > > & zeros with the intent of exercising the magnetic flux in different ways on
> > > the disk surface.
>
> > Ok, please help out a neophyte. I have a program called MACWASHER. The box
> > states that it overwrites files according to the DoD directive 5220.22-M.
>
> If the program does what it claims to (and I have no knowledge of
> that) it will be accessing the hardware at a lower level than
> Szopa's calls of the C library functions fopen()/fclose().
>
> > It
> > looks like from what I have read on this discussion that the above DoD
> > directive doesn't actually do what the DoD thinks it does.
>
> If that's what you think, you have severely misread something.
> The DOD directive presumably states that the program *shall* do
> something. If the program doesn't do what the DoD requires, it
> means that the program fails the directive, not that the
> directive is wrong.
>
> > In other words I
> > am not actually deleting the files and making them unrecoverable? When I say
> > unrecoverable I mean to a software based attack and not SEM data.
>
> No. The point here is not that it is impossible to do
> what you want, but it can't be done using high-level
> platform-independent library functions.
>
> --
> Richard Herring | <[EMAIL PROTECTED]>
here are the calls:
fopen in r+b mode
fprintf character by character
fclose that flushes all OS buffers associated with the stream. You
would think this would be enough to force a write.
Just to make sure I added one of ...
...the Colonel's secret spice codes of 8 characters in length in
each pass
Down load the UPDATE. You will see the hard drive accesses after
each pass. Larger file size makes for more hard drive accesses.
There can only be one reason for these hard drive accesses with the
code as described: a write to the hard drive.
------------------------------
From: "Mark Livingstone" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 2.6.3ia-cb (now supports CAST5 and BLOWFISH)
Date: Mon, 5 Mar 2001 17:07:33 +1000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Hi Jungle,
I think PGP should be viewed as being "bigger" than just NAI. There
has been the OpenPGP RFC2440 since November 1998 and Blowfish is
specifically mentioned as an approved symmetric algorithm in s9.2.
In fact, the RFC specifically allows for:
RSA
Elgamal
DSA
Elliptic Curve
ECDSA
DH
IDEA
3DES
CAST5
Blowfish
Safer-SK128
DES/SK
AES128
AES192
AES256
MD5
SHA1
RIPEMD160
MD2
Tiger192
Haval-5-160
There are also specific number set aside for experimental algorithms.
"jungle" <Use-Author-Address-Header@[127.1]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> 08 Feb 2001 in <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] wrote:
> > jungle wrote:
> > > > I just added another cipher to PGP 2.6.3ia - Blowfish
> > > > why? because it was easy :)
> > >
> > > and you are calling it PGP ?
> > > it is not PGP any more ...
> >
> > then PGP5, 6, 7 is not PGP too ! or is it ? ;-)
>
> PGP v5x, PGP v6x, PGP v7x are PGP,
> all have been produced by PGP
>
> additionally, they are not using B/F algo
>
> additionally, you are producing more harm to PGP than good,
> by creating additional, not needed incompatibility issues ...
>
> additionally, PGP is not "open product" or "public domain" product,
> despite the fact that source code is publicly available
>
> why don't you get simple approval from NAI / PRZ for what you are
> doing ?
> as of today, they are the owners of PGP software, don't they ?
>
> to sum all this up :
> as long as I'm concern, you can include in your software all what
> you like to include,
> but NAI / PGP PRZ may be supporting different opinion,
> [ PGP PRZ indicated this many years ego, isn't this correct ? ]
>
> ~~~
> This PGP signature only certifies the sender and date of the
> message. It implies no approval from the administrators of
> nym.alias.net.
> Date: Thu Feb 8 17:18:10 2001 GMT
> From: [EMAIL PROTECTED]
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQEVAwUBOoLU1E5NDhYLYPHNAQFmnwf+JMUi6wyOSoF/xu63SrZOGe/fntD5w6+y
> HQWgimwYeSWpqh3SB4l9U2xw1HDliRkMs7u4YFcRX++4kLh9U2BB/9R6I8qKWziK
> eoaYwJInwunlvb5skCYTvkhISTOt5fjC5/9e5pruUNgfRLGpG5jupV+viGuqyhsV
> iXYYpPzlMeM0l7RZa9Ymx6fBygzodra3/mJVVylbdg8YsJTrJya8Y/E+WxdtyhOk
> DpGpzOcEB3RBF4nk6beyP/GIH8KKFm8uhnY3us8jWLy+HPaAJyLghK4E4P1dR8+F
> hlBqK6KMK9c5XXtNK7QDjL8GNC04UD4UCy3PZR5tPVIP3JWLVb6V+A==
> =xfQu
- -----END PGP SIGNATURE-----
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOqM7MupKWuyElsBtEQLuRACcDZTvSX6JGsKy3QmOpsPEn9+ryTAAniVx
7plAMgC7lg2o5E16EQqpMjtS
=yI3z
=====END PGP SIGNATURE=====
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: PKI and Non-repudiation practicalities
Date: Tue, 6 Mar 2001 23:08:40 +1100
Anne & Lynn Wheeler wrote in message ...
>"Lyalc" <[EMAIL PROTECTED]> writes:
>
>> No one buys security. They do pay for things that improve their
business,
>> short and long term.
>> PKI merely replicates password based processing. Remember, the private
key
[snip]
>
>i would have said that public/private key authentication does a little
>bit better job than secret-key/pin authentication .... since it
>eliminates some issues with the sharing of a secret-key.
The difficulty in conventional PKI is ensuring the correct Root public key
is distributed, and not superceded or supplanted in the recipients system.
Otherwise, the "CA in the middle" (tm) attack occurs. This has similar
complexity and cost as the secret key distribution issues. And secret key
distribution is no longer as hard or expensive as it used to be.
>hardware tokens can be accessed with pin/secret-key and then do
>public/private key digital signatures for authentication ... but there
>is no "sharing" of the pin/secret-key.
True. Though PIN entry is still required, a point of compromise unless more
wrapping technology is used. Add appropriate 'wrapping technology' and you
end up with a new version of legacy systems called ATMs with new internal
encryption. A bit self-defeating, I think.
>taken to the extreme, biometrics is a form of secret key .... and
>while compromise of pin/secret-key in a shared-secret infrastructure
>involves issuing a new pin/secret-key ... current technology isn't
>quite up to issuing new fingers if a biometric shared-secret were
>compromised (aka there are operational differences between
>shared-secret paradigms and non-shared-secret paradigms ... even if
>both have similar pin/secret-key/biometrics mechanisms).
Exactly. A trusted, tamper-resistant Biometric verifier engine seems
required.
>in an account-based infrastructure that already uses some form of
>authentication (pins, passwords, mothers-maiden-name, #SSN, etc), it
>is relatively straight-forward technology upgrade to public/private
>key authentication ... w/o requiring business process dislocation that
>many PKIs represent.
Not sure I, or the GAO agrees with that in all cases. The recent GAO report
(Advances and Remaining Challenges to Adoption of Public Key Infrastructure
Technology, GAO-01-277) outlines some enormous cost and complexity
challenges. $170m merely to make a few legacy applications operate with PKI
seems a lot, when the PKI itself stills needs to be built.
I do agree that the cost need not be high with sensible use of Public Key
technology, but most conventional PKI has not yet reached that
understanding.
Lyal
>--
>Anne & Lynn Wheeler | [EMAIL PROTECTED] - http://www.garlic.com/~lynn/
------------------------------
From: John Rickard <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: 06 Mar 2001 12:41:27 +0000 (GMT)
Reply-To: [EMAIL PROTECTED]
In sci.crypt Joe H. Acker <[EMAIL PROTECTED]> wrote:
: My tests are contradicting to your test. They give a 50:50 result.
:
: Actually, I did not expect anyone to take this seriously, but as you
: must have implemented the algorithm in a wrong way,
Sounds a bit arrogant! Did you perform the simple test of making your
code print out the results (door with car, door initially chosen, door
opened, final choice, prize won) of each iteration so that you could
check that its behaviour looked reasonable?
: here is an
: inefficient implementation of Monty's algorithm in a dialect similar to
: VisualBasic, whereas Random(i) returns a PRNG random number between 0
: and i (inclusive):
Does it really?
--
John Rickard <[EMAIL PROTECTED]>
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 04:47:47 -0800
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > Wrong. It is possible to ensure that the same disk blocks will
> > be ovrwritten (unless a new bad block gets added to the remapping
> > table during the process), but you have to open the file in a
> > particular mode (r+w in stdio terminology); if the file is opened
> > for writing in the default mode, it gets truncated to 0 length and
> > all its previous data blocks are returned to the block-buffer pool.
>
> Even that doesn't really guarantee that the same blocks will be
> overwritten -- there are logged file systems that _always_ allocate
> new space when you write data. They typically use a garbage
> collector to delete blocks and add them to the free space when
> they're found to longer belong to any file, but some systems like
> this simply don't allow you to directly overwrite the blocks of a
> file regardless of the mode in which you open the file.
>
> --
> Later,
> Jerry.
>
> The Universe is a figment of its own imagination.
I am talking for only windows now.
Here is a test that I just carried out.
I took a blank floppy and I copied one file that was 859KB to it
then I copied another file to this same floppy that was 322KB.
Then I created an OverChk2.txt file to flag the process after just
two passes. This should be enough to prove my points.
Then I ran the original OverWrite Program Version 1.0 and overwrote
the larger 859KB file. After the second pass the OverChk2 flag file
was detected and the process ended.
I did a file compare on the 322KB file with its original file and
there were no differences.
I then used the Read Utility from the OAP-L3 (OAR-L3) software and
the file was overwritten completely with binary 170 just as it should be
after two overwrite passes.
Once the OverWrite program was loaded there were no hard drive
accesses. There were only continuous floppy drive accesses. You
could see the access light and hear the drive writing all the while.
You could even hear the distinct sound when the write head had to
track back to the beginning of the file to begin the second pass.
What does this show: the OS had no need to work in secondary cache
as evidenced from there being no hard drive accesses.
The OS did not utilize any cache because you could see and hear that
the floppy write process was continuous for two write passes.
There is no read instructions coded into the program. Just an
initial file seek to get the file length.
Since the 322KB file on the floppy was exactly as the original the
OS did not use any additional floppy disk space. The entire
operation was confined to the space bit for bit of the 859KB file.
So indeed a perfect byte for byte overwrite was executed with no
cache operations just a I described from the beginning.
I then ran the same test from scratch using a blank floppy using the
updated OverWrite program Version 1.1 and the results were the same.
Do any of you dispute this floppy drive test?
Try it yourself.
------------------------------
** 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
******************************
