Cryptography-Digest Digest #819, Volume #13 Tue, 6 Mar 01 10:13:01 EST
Contents:
Re: PKI and Non-repudiation practicalities (Mark Currie)
Re: AES and DES ("Tom St Denis")
Re: Monty Hall problem (was Re: philosophical question?) (Joe H. Acker)
Re: OT: The Big Breach (book) available for download (p)
Re: AES and DES (SCOTT19U.ZIP_GUY)
Re: Monty Hall problem (was Re: philosophical question?) (Joe H. Acker)
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
Re: The Foolish Dozen or so in This News Group (Eric Lee Green)
Re: => FBI easily cracks encryption ...? ("John Niven")
----------------------------------------------------------------------------
Subject: Re: PKI and Non-repudiation practicalities
From: [EMAIL PROTECTED] (Mark Currie)
Date: 06 Mar 2001 14:09:29 GMT
In article <Gt4p6.4064$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>
>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.
>
PKI also introduces more complexity WRT certificate validation and revocation.
On many user payment platforms it is impractical to cope with certificate
validation checking including CRL syncronisation. In order to address this, the
PKI industry has provided support such as certificate validation servers and
OCSP responders. However these in turn require trust relationships with the
user platform hence introducing another level of complexity.
>>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.
>
Best would be to incorporate all three elements: what you have (portable secure
hardware); what you know (pin/passphrase); what you are (biometric). These
elements can be provided in both a shared secret key system as well as in a
public key system. The main difference is that the public key based system adds
the potential to provide non-repudiation which was the main subject of my
original post. There are many issues that can be debated around key
management in symmetric and asymetric systems as can be seen from above
discussions. However, a shared secret key system can never support
Non-repudiation by its very nature (sharing). An Asymmetric key system at least
provides support at the cryptography level, but as mentioned in my original
post, it only solves part of the problem.
Mark
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: AES and DES
Date: Tue, 06 Mar 2001 14:19:49 GMT
"Latyr Jean-Luc FAYE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi
>
> As I told in my previous submission, I am begining in Crypto.
> I red some stuff about AES that will replace DES.
> Can somebody explain me the differecences and the advantages.
> A brief dicuss or some useful links with this informations.
> Regards
AES is advanced :-o
I would suggest you read up on background before becomming politically
influenced. Hmm Bruce Schneier has a wickedly cool list of papers available
check out his site (http://www.counterpane.com/labs.html). I would also
pick up a copy of his book or the HAC (the url for HAC has been posted about
2^2000 times this month so it's easy to find).
Tom
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 6 Mar 2001 15:29:40 +0100
John Rickard <[EMAIL PROTECTED]> wrote:
> 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!
Sorry, it wasn't meant to be arrogant at all.
>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?
Nope, I will check my code and let any of you know wether it contains an
error or not. Let me assure you that I will be the first who admits that
I was wrong and my program is crap, if this indeed should be the case. I
feel rather discomfort with maintaining my argument, but haven't yet
encountered good arguments against it. Also, any of you is free to
translate my code into another language.
Because it's a bit off-topic on sci.crypt, I have transfered the
discusion to sci.math.
Greetings,
Erich
------------------------------
Subject: Re: OT: The Big Breach (book) available for download
From: p <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss
Date: Tue, 06 Mar 2001 06:52:56 -0800
those URLs for d/l-ing the big breach... can they pls be reposted?
TIA,
potlatch
--
"Now you know," the bird said, "that what you thought was disaster was in
fact good news to me. And how the message, the suggestion of how to behave
in order to free myself, was transmitted to me thru you, my captor." And he
flew away...
> From: [EMAIL PROTECTED] (Jim D)
> Organization: At Home
> Reply-To: Jim D
> Newsgroups:
> alt.security.pgp,alt.security.scramdisk,comp.security.pgp.discuss,sci.crypt
> Date: Sun, 04 Mar 2001 22:14:51 GMT
> Subject: Re: OT: The Big Breach (book) available for download
>
> On Sun, 4 Mar 2001 14:59:56 -0000, "Sam Simpson" <[EMAIL PROTECTED]> wrote:
>
>> 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 ;) ^^^^^^^
>
> Presumably also in Scotland and Wales. But perhaps not
> so much...
>
> --
> ___________________________________________
>
> Posted by Jim Dunnett
>
> George Dubya Bushisms No 6:
>
> CIA? Howdja spell that?
>
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES and DES
Date: 6 Mar 2001 14:51:13 GMT
[EMAIL PROTECTED] (Latyr Jean-Luc FAYE) wrote in
<[EMAIL PROTECTED]>:
>Hi
>
>As I told in my previous submission, I am begining in Crypto.
>I red some stuff about AES that will replace DES.
>Can somebody explain me the differecences and the advantages.
>A brief dicuss or some useful links with this informations.
>Regards
>
>Latyr
>
>
>
A good place to learn about crypto is to read certain books
like the puzzle palace and the code breakers. Encryption is fun
since it is one of the black arts where government is always trying
to mislead the people. You should never fully trust one source for
your data or encryption needs. If I was you I would read various
sources. However as weak as many systems tend to be if you use
systems in series that add no information you would go a long ways
to haveing a more secure system. I only know of 2 systmes that don't
add information to a file. Matts version of Rijndeal adds no information
and does the right kind of compression as a first pass. You could use
his coded. Followed by one of mine like scott16u or scott19u. After
that then you could use one of the methods the so called crypto gods
claim is safe such as BLOW FISH or TWO FISH or what ever smelly product
people talk you into.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 6 Mar 2001 15:51:06 +0100
John Rickard <[EMAIL PROTECTED]> wrote:
> 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!
Sorry about that, it wasn't meant to be.
> : 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?
You are right, my random() function was flawed. I have corrected it and
now my app does output 1/3 for not switching, and 2/3.
CONCLUSION: I was entirely mistaken and my argument is completely wrong!
I'd like to thank all of the patient people who continuously tried to
explain the correct solution to me. At least I have learned a lot from
this thread, and maybe my mistakes and my faulty argument will help in
future discussions, when other newbies like me try to challenge the
Monty Hall problem. :)
Thanks a lot for pointing me into the right direction!
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 6 Mar 2001 08:50:37 -0600
On Tue, 06 Mar 2001 03:45:02 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>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
Please note that the hard drive LED for SCSI drives does not do what
you think it does. It lights up whenever there is SCSI bus activity to
the drive, whether or not the drive is actually engaged in reading or
writing at a given time. For example, if a track is already in the
drive's internal buffer, all operations take place upon the buffered
track, not upon the actual disk media. The disk media does not get
written to until it rotates around to the "dirty" sectors, which could
be a few milliseconds even with the fastest hard drives. For small
files in fast machines, this means that you're operating entirely upon
the SCSI drive's internal buffers, even disregarding OS-level buffering.
I do not know enough about IDE hardware to tell you what it does. I do
know that all modern IDE drives include a buffer, but whether it is
used in the same manner or not is not something I know about. (Unlike
you, I do not make sweeping statements about subjects that I am not
knowlegable about).
Your particular OS may or may not have disk I/O buffering. Windows 95
did not, as far as I know, except as a third-party add-on. Windows 98
supposedly does. I say "supposedly" because I have not noticed it
doing anything -- I get better I/O performance out of Windows 98 by
attaching to a Samba fileshare on a Linux server and letting Samba
handle disk buffering. All versions of Windows NT and Windows 2000
have a VMS-style disk I/O buffering scheme that is somewhat similar to
the classic Unix-style disk I/O buffer scheme as described in the
"Bach Book" or the Linux source code, except with more
optimizations. In addition, NTFS is a semi-transactional journalling
filesystem that probably does not do what you think it's doing --
i.e., it is probably doing the journalling that I mentioned (does not
write the replacement data to the old sector, but rather, writes it to
a different sector, then does a "commit" to release the old sector
only after it has verified that the replacement block is properly on
disk). Since I do not have the source code to NTFS I cannot verify that
this is what NTFS does, but this is what journalling filesystems do, and
Microsoft claims that NTFS is a journalling filesystem.
In any event, if you run your software on Windows 95 you may indeed get
the effect you desire. That does not help people who run it on Windows NT
or Windows 2000, and it may or may not help people who run it on Windows 98+.
And will not help people who are trying to erase smaller files on SCSI
drives (where the blocks in the file fit inside the drive's buffer cache).
It may not even help people trying to erase smaller files on IDE drives,
though I'm not familiar enough with how IDE drives work to tell you
(I know a very slight bit about how ATAPI works -- ATAPI is SCSI-like
extensions to IDE -- but only in the context of IDE tape drives, which
is not useful here).
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Reply-To: [EMAIL PROTECTED]
Date: 6 Mar 2001 08:54:29 -0600
On Tue, 06 Mar 2001 04:47:47 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]
> wrote:
>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.
Floppy drive access is not cached under Windows 9x, and never will be
due to the fact that you can hit the eject button at any time and
Windows has to make sure that you have a consistent filesystem. So
your program does operate the way you think it does, when operating
upon floppies under Windows 9x.
This may not be true with later versions of Windows 9x and hard
drives, though, and *DEFINITELY* is not true with Windows NT or 2000
when operating upon hard drives, where you may not even be writing back
to the same sectors.
--
Eric Lee Green [EMAIL PROTECTED] http://www.badtux.org
AVOID EVIDENCE ELIMINATOR -- for details, see
http://badtux.org/eric/editorial/scumbags.html
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: "John Niven" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 6 Mar 2001 15:05:32 -0000
> Europeans have always tolerated police forces that demand that
> each and every citizen "register" his/her residence with the
> ...
Ah, excuse me for interrupting, but I'm a "foreigner" (a New Zealander)
living in Scotland. I've never been required to register with the police.
The closest I've come is reporting my passport lost. I guess I'm probably
on a government file from when I applied for a visa (several years ago), but
if the government know my current address it's through other mechanisms.
> ... police. Americans never have.
Not entirely true, though I'd concede that the US Government cited "National
Emergency" to justify registration by, and internment of, numerous citizens
of Japanese and German ancestry. Horst Feistel invented Lucifer (DES) for
IBM, but during the Second World War was placed under house arrest.
Just a clarification. My personal two-cents-worth is that most (but not
all) governments tend to be as bad as each other. The "better" governments
tend to be the smaller ones, that don't have quite so much opportunity to
play politics.
John
--
John Niven
(Reply through newsgroup)
"Fogbottom" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <97vs2f$2pchu$[EMAIL PROTECTED]>
> "kroesjnov" <[EMAIL PROTECTED]> wrote:
> >
> > > > I am willing to trade some privacy for safety.
> > >
> > > I'm not.
>
> > > Unfortunately, all of them are also more likely than a
> terrorist bombing
> > > your school or a nut invading your country.
> >
> > How many razi`s have taken place in your country in the last
> couple off
> > years? When was the last time they purged your country from
> all the black
> > people? When was the last time they threw everybody in prison
> who was
> > against Clinton? When was the last time they purged the
> schools, from those
> > who performed less then a C ?
> >
> > And when is the last time they bombed a building in your
> country? When is
> > the last time, some luney started blasting away at a school?
> When is the
> > last time, your country was at war?
>
> You're right - my country has been a asfe place to live for the
> past few years.
> And strong encryption, probably unbreakable by the FBI and NSA,
> has been available to the citizens of my (and nearly every
> other) country druing that time.
>
> So banning encryption is obviously unnecessary for "national
> security".
>
> > I think this illustrates what is most likely to happen, don`t
> you think?
>
> Obviously not.
>
> > > > Afcourse they keep a mild track on everybody. To
> > > > not do that, would be making it impossible to detect
> > > > "the bad guy" among the good guys, you know that,
> > > > and I know that.
>
> Europeans have always tolerated police forces that demand that
> each and every citizen "register" his/her residence with the
> police. Americans never have. It's a fundamental difference
> between Americans and much of the rest of the world.
>
> > > There aren't any bad guys, until they do something bad.
> >
> > Yes, that is indeed true.
> > But there is always something like patern matching, to see who
> is most
> > likely to do something like bombing a building (I am just
> afraid to use the
> > word 'bad' by now, you know that? ;).
> > And no, these systems aren`t fool proof, but you know where I
> am getting
> > at... I hope...
>
> Certainly.
> Americans don't tolerate that sort of behavior from their police
> forces.
>
> > Move to The Netherlands, and you won`t have to :)
>
> But you *will* have to register your residence with the police.
> In America, only convicted criminals released on parole have to
> do that.
>
> > This is indeed also true.
> > But yet there are paterns wich can be recognized, and can be
> linked to
> > criminal behaviour. Although this person may not be entirely
> bad, he/she is
> > doing something wrong, and this mather should be looked into.
>
> The SD and KGB and Gestapo would all agree with you.
>
> Very few Americans would.
>
> Again, that's a fundamental difference between Americans and
> most of the world.
>
>
------------------------------
** 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
******************************
