Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #13 Sun, 4 Mar 01 19:13:01 EST
Contents:
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: super strong crypto, phase 3 ("Douglas A. Gwyn")
Re: => FBI easily cracks encryption ...? (Free-man)
Re: HPRNG (Darren New)
Re: OT: The Big Breach (book) available for download (Jim D)
Re: philosophical question? ("Douglas A. Gwyn")
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?) (Jim
D)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: The Foolish Dozen or so in This News Group (Darren New)
Fwd: Digital Envelope for email (Tony L. Svanstrom)
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: Question about double encryption ("Simon Johnson")
Re: The Foolish Dozen or so in This News Group (Anthony Stephen Szopa)
Re: The Foolish Dozen or so in This News Group (Anne & Lynn Wheeler)
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily cracks encryption
...?) (Joe H. Acker)
Re: OverWrite freeware completely removes unwanted files fromharddrive (Benjamin
Goldberg)
Re: Is BORG mental patient Linda Gore SSRIHater?? Re: Fake SSRIHATER ("Beeftain")
Re: OT: Legitimacy of Governmental Power (Was: Re: => FBI easily crack ...?)
([EMAIL PROTECTED])
Re: philosophical question? (Benjamin Goldberg)
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: super strong crypto, phase 3
Date: Sun, 04 Mar 2001 22:11:34 GMT
Steve Portly wrote:
> would it be cheaper to pay the terrorist or to pay the cryptoanalytic
> team? You mentioned that XOR was being used to produce cipher text so
> something is known about the algorithm already.
I assume that the complete general system is known to the
cryptanalysts, and that cryptanalysis *will* be performed.
These assumptions are necessary for any consideration of
"super strong" crypto.
> Statistical analysis might find some bias or pattern in
> 2 million bytes of cipher text that would give some
> additional information about the algorithm.
The algorithm is known. What various features of the
straw-man-phase-3 scheme are designed to do is to remove
all exploitable patterns. As I noted, it is not possible
to cryptanalyze an isolated block no matter what technique
might be used, because there is no way to distinguish a
valid key from an invalid one (the correct PT is random).
That means the only hope for the cryptanalyst is to attack
multiple blocks simultaneously, but since they use
different keys (unrelated to each other, if one chooses to
spend a little more bandwidth than I originally suggested)
it is hard to see how correlations might be established.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: super strong crypto, phase 3
Date: Sun, 04 Mar 2001 22:14:20 GMT
John Savard wrote:
> I don't think that masking every block by a constant quantity can be
> expected to improve security that much.
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.
--
From: [EMAIL PROTECTED] (Free-man)
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Sun, 04 Mar 2001 22:15:54 GMT
On Sun, 4 Mar 2001 19:29:12 -, "Randoman"
<[EMAIL PROTECTED]> wrote:
>
>Beretta <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Sun, 4 Mar 2001 13:10:01 +0100, "kroesjnov" <[EMAIL PROTECTED]> wrote:
>>
>>
>> >
>> >I am willing to trade some privacy for safety.
>>
>>
>> So basically, you are saying that you'll trade your privacy to be a sheep?
>I.e.
>> you'll give up your rights so that the goverment can play the role of
>> sheepherder?
>>
>
>I don't want police & intelligence services reading my email or files. But
>I do want them to read the communications of people who might plant a bomb
>on the next plane I take.
There is a better way to prevent terrorism. There is an alternative
to the police-state. Governments such as the US, China, Russia, etc.
should stop dropping bombs. Stop stomping on people. Stop their
systematic violations of human rights and freedom. There are many
angry people on this planet who have very good reasons for being
angry. And many of them want to retaliate.
Even governments that don't drop bombs engage in the widespread
use of violence and coercion against peaceful people. More freedom
is t
Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #12 Fri, 29 Sep 00 14:13:00 EDT
Contents:
Timing Attacks ([EMAIL PROTECTED])
Re: Newbie question to practical brute-force analysis (Roger Gammans)
Re: Non-Repudiation mechanism ("Kevin Crosbie")
Re: CPU's aimed at cryptography (Mike Rosing)
Re: Which is better? CRC or Hash? ("Tomas Rosa")
Re: Newbie question to practical brute-force analysis (Jim Gillogly)
AES annoucement due Monday 2nd October (David Crick)
From: [EMAIL PROTECTED]
Subject: Timing Attacks
Date: Fri, 29 Sep 2000 16:55:25 GMT
Hi all,
I would like to point your attention to this article that i have co-
written with Prof Kit Dodson from UMIST in MAnchester, UK on Timing
Attacks:
http://www.ma.umist.ac.uk/kd/PREPRINTS/rsatim.ps
I would your thoughts and feedback on the content of this paper.
Thank you very much for your help.
Brice Canvel.
P.S. : Could people email any comments/suggestions they have to
[EMAIL PROTECTED], thank you.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Roger Gammans)
Subject: Re: Newbie question to practical brute-force analysis
Date: Fri, 29 Sep 2000 17:18:00 GMT
In article <[EMAIL PROTECTED]>, Jim Gillogly wrote:
>
> The second step is to look carefully at the ciphertext and
>see if you can determine anything from statistical properties such
>as character frequency, repeated strings, periodic behavior, and
>range. Look especially closely at the beginning of the file, in case
>it's one of the cryptosystems that leaves tracks so that it can
What sort of differences would one expect to see in the output
of different modern block & stream ciphers?
In the case of block ciphers, presumably repeated blocks give away
codebook mode and and block length (Detected via say auto-correlation),
but are there other simple tricks and idiosyncrasies in the output you
can look for?
TTFN
--
Roger
Think of the mess on the carpet. Sensible people do all their
demon-summoning in the garage, which you can just hose down afterwards.
-- [EMAIL PROTECTED]
--
From: "Kevin Crosbie" <[EMAIL PROTECTED]>
Subject: Re: Non-Repudiation mechanism
Date: 29 Sep 2000 17:22:00 GMT
More comments.
"Lyalc" <[EMAIL PROTECTED]> wrote in message
news:Yw%A5.12937$[EMAIL PROTECTED]...
> comments inline
>
> Kevin Crosbie wrote in message <8r00gi$[EMAIL PROTECTED]>...
> >Layal,
> >
> >Comments below:
> >
> >
> >"Lyalc" <[EMAIL PROTECTED]> wrote in message
> >news:rpyA5.7514$[EMAIL PROTECTED]...
> >> Sigh...
> >>
> >> What happens when a valid user gets 2 or more valid certificates (as
per
> >the
> >> bogus cert attack described)?
> >
> >Well the user can only have one valid cert registered in my database,
they
> >can't apply for a second as long as there is one in existence in the
> >database. If they manage to get a second using an insider's help, it
> won't
> >match the PKCS#7 signer certificate, and I can say that foul play has
> >occured. I'm not sure of the legal aspects of this.
>
>
> A race condition - the first one to get a certificate is designated the
> 'real' identity, regardless of acual identity
This system is dependant on an initial authentication mechanism. We can
(I'm not sure if we do yet) restrict to one logon session per user. That
destroys the race condition... the only problem is if the user gets their
authentication mechanism stolen... not a race condition, rather a security
condition.The restriction of one logon session per user is really only
an issue if there is a possibility of the user getting their authentication
mechanism stolen... in which case, anyone can masquerade as the user, even
for signing purposes... which is still really pointing to the fact that if
you let your authentication mechanism get stolen, then you are allowing
people to pose as you.
>
>
> >> Smartcards need a 'secure' reader that incorporates a keypad or
biometric
> >> entry device, especially if you want to move beyond an expensive
> >duplication
> >> of a password mechanism towards something that has some amount of legal
> >> validity.
> >
> >What are the current legal guidelines regarding this form of security at
> >present (password/browser cert/Smartcard)?
>
>
> No one really knows, as it hasn't been well tested (or maybe never tested
at
> all yet) since most jurisdictions have gone a technology neutral,
"approved
> standards" route, the latter having not yet been ratified
Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #11 Wed, 17 May 00 09:13:01 EDT
Contents:
Re: Skipjack implementation in C (RogerStaub)
Re: homophones (UBCHI2)
Re: Is OTP unbreakable? ([EMAIL PROTECTED])
Re: Skipjack implementation in C (RogerStaub)
Re: Crypto & UNICODE??? (Marcin Jaskolski)
Re: Creating a good key-shedule (Tom St Denis)
Re: Crypto & UNICODE??? (John Savard)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: Interesting differentials in BREAKME (Tom St Denis)
Re: Definition of "Broken" Cipher (Nicol So)
Re: zeroknowledge.com and freedom.net - Snake oil?
([EMAIL PROTECTED])
Re: bamburismus (John Savard)
From: RogerStaub <[EMAIL PROTECTED]>
Subject: Re: Skipjack implementation in C
Date: Wed, 17 May 2000 07:47:14 -0400
"Douglas A. Gwyn" wrote:
>
> /*
> SKIPJACK implementation in Standard C
>
> last edit: 25-Jun-1998 [EMAIL PROTECTED]
>
> Derived from Markus G. Kuhn's Ada 95 implementation.
>
> This is a C89 implementation of the SKIPJACK block cipher algorithm
> as specified in version 2.0 of NSA's SKIPJACK specification dated
> 1998-05-29 <http://csrc.nist.gov/SJ_Encryption/skipjack-kea.htm>.
>
> ASSUMES width of type "unsigned char" is 8 bits.
> */
>
> /*
> Interface specification:
> */
> #define SJ_Keysize 10 /* to match NSA spec (80 bits) */
>
> /* Encryption/decryption is performed for a single 64-bit (8-byte)
> block. */
>
> voidSJ_Encrypt ( const unsigned char *Key, const unsigned char
> *Plaintext,
> unsigned char *Ciphertext
>);
>
> voidSJ_Decrypt ( const unsigned char *Key, const unsigned char
> *Ciphertext,
> unsigned char *Plaintext
>);
>
> int SJ_Selftest ( void ); /* returns nonzero iff passed test */
>
> /*
> Implementation:
> */
>
> static const unsigned char F[256] =
> {
> 0xA3, 0xD7, 0x09, 0x83, 0xF8, 0x48, 0xF6, 0xF4,
> 0xB3, 0x21, 0x15, 0x78, 0x99, 0xB1, 0xAF, 0xF9,
> 0xE7, 0x2D, 0x4D, 0x8A, 0xCE, 0x4C, 0xCA, 0x2E,
> 0x52, 0x95, 0xD9, 0x1E, 0x4E, 0x38, 0x44, 0x28,
> 0x0A, 0xDF, 0x02, 0xA0, 0x17, 0xF1, 0x60, 0x68,
> 0x12, 0xB7, 0x7A, 0xC3, 0xE9, 0xFA, 0x3D, 0x53,
> 0x96, 0x84, 0x6B, 0xBA, 0xF2, 0x63, 0x9A, 0x19,
> 0x7C, 0xAE, 0xE5, 0xF5, 0xF7, 0x16, 0x6A, 0xA2,
> 0x39, 0xB6, 0x7B, 0x0F, 0xC1, 0x93, 0x81, 0x1B,
> 0xEE, 0xB4, 0x1A, 0xEA, 0xD0, 0x91, 0x2F, 0xB8,
> 0x55, 0xB9, 0xDA, 0x85, 0x3F, 0x41, 0xBF, 0xE0,
> 0x5A, 0x58, 0x80, 0x5F, 0x66, 0x0B, 0xD8, 0x90,
> 0x35, 0xD5, 0xC0, 0xA7, 0x33, 0x06, 0x65, 0x69,
> 0x45, 0x00, 0x94, 0x56, 0x6D, 0x98, 0x9B, 0x76,
> 0x97, 0xFC, 0xB2, 0xC2, 0xB0, 0xFE, 0xDB, 0x20,
> 0xE1, 0xEB, 0xD6, 0xE4, 0xDD, 0x47, 0x4A, 0x1D,
> 0x42, 0xED, 0x9E, 0x6E, 0x49, 0x3C, 0xCD, 0x43,
> 0x27, 0xD2, 0x07, 0xD4, 0xDE, 0xC7, 0x67, 0x18,
> 0x89, 0xCB, 0x30, 0x1F, 0x8D, 0xC6, 0x8F, 0xAA,
> 0xC8, 0x74, 0xDC, 0xC9, 0x5D, 0x5C, 0x31, 0xA4,
> 0x70, 0x88, 0x61, 0x2C, 0x9F, 0x0D, 0x2B, 0x87,
> 0x50, 0x82, 0x54, 0x64, 0x26, 0x7D, 0x03, 0x40,
> 0x34, 0x4B, 0x1C, 0x73, 0xD1, 0xC4, 0xFD, 0x3B,
> 0xCC, 0xFB, 0x7F, 0xAB, 0xE6, 0x3E, 0x5B, 0xA5,
> 0xAD, 0x04, 0x23, 0x9C, 0x14, 0x51, 0x22, 0xF0,
> 0x29, 0x79, 0x71, 0x7E, 0xFF, 0x8C, 0x0E, 0xE2,
> 0x0C, 0xEF, 0xBC, 0x72, 0x75, 0x6F, 0x37, 0xA1,
> 0xEC, 0xD3, 0x8E, 0x62, 0x8B, 0x86, 0x10, 0xE8,
> 0x08, 0x77, 0x11, 0xBE, 0x92, 0x4F, 0x24, 0xC5,
> 0x32, 0x36, 0x9D, 0xCF, 0xF3, 0xA6, 0xBB, 0xAC,
> 0x5E, 0x6C, 0xA9, 0x13, 0x57, 0x25, 0xB5, 0xE3,
> 0xBD, 0xA8, 0x3A, 0x01, 0x05, 0x59, 0x2A, 0x46
> };
>
> #define G( k, i, h, l ) \
> h ^= F[l ^ k[i]]; \
> if ( ++i >= SJ_Keysize )i = 0; \
> l ^= F[h ^ k[i]]; \
> if ( ++i >= SJ_Keysize )i = 0; \
> h ^= F[l ^ k[i]]; \
> if ( ++i >= SJ_Keysize )i = 0; \
> l ^= F[h ^ k[i]]; \
> if ( ++i >= SJ_Keysize )i = 0;
>
> #define G_Inverse( k, i, h, l ) \
> l ^= F[h ^ k[i]]; \
> if ( --i < 0 ) i = SJ_Keysize - 1; \
> h ^= F[l ^ k[i]]; \
> if ( --i < 0 ) i = SJ_Keysize - 1; \
> l ^= F[h ^ k[i]]; \
> if ( --i < 0 ) i = SJ_Keysize - 1; \
> h
Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #10 Mon, 27 Dec 99 17:13:01 EST
Contents:
Re: HD encryption passphrase cracked! (Matthew Montchalin)
Re: Are PGP primes truly verifiable? (wtshaw)
Re: Employing digits of pi ("Dann Corbit")
Re: Employing digits of pi (Matthew Montchalin)
Re: how good is RC4? (Jim Gillogly)
Re: how good is RC4? (Bill Unruh)
Re: HD encryption passphrase cracked! (Guy Macon)
Re: Disbelief about Numbers Stations (Jim)
Re: HD encryption passphrase cracked! (Bill Unruh)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: Why doesn't RSA use n=pqr ? (was Re: Are PGP primes truly verifiable?) ("Craig
Clapp")
Re: Employing digits of pi (Mok-Kong Shen)
Homophones (Mok-Kong Shen)
Re: Disbelief about Numbers Stations ("Mark McCarthy")
Re: Employing digits of pi (Mok-Kong Shen)
Re: Why doesn't RSA use n=pqr ? (was Re: Are PGP primes truly verifiable?)
([EMAIL PROTECTED])
Re: Are PGP primes truly verifiable? ([EMAIL PROTECTED])
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: misc.misc
Subject: Re: HD encryption passphrase cracked!
Date: Mon, 27 Dec 1999 12:07:24 -0800
On 27 Dec 1999, Keith A Monahan wrote:
|P.S. FYI, I have since wiped my harddrive using over 25 passes of the
|standard all zeros, all ones, 0101, and pseudo-random data.
Have you ever opened up your hard drive and pulled out the magnetic
medium with a pair of tweezers? Sure, they say that microscopic
particles of dirt get into the hard drive, substantially compromising the
storage capabilities, but if you really wanted to eradicate every last
trace of the data, and yet still be able to use the medium (that is the
important part), you can swipe a kitchen magnetic over and around and
around the medium before replacing it again. Of course, after doing
something like that, you'll have to do a low-level format of the medium
all over again before you can use the medium. And mirabile dictu, for
ordinary hard drives (120 megs+), you haven't ruined that much of the
medium.
|The exceeds the DOD recommendation and exceeds the magical number of 17,
|which AFAIK, is the maximum number of writes that can be recovered.
H They must be assuming the user is not so paranoid that he
won't take the drive apart and perform some basic (described above)
security measures...
|I looked for the paper reference, but can't find it.
|
|P.P.S. Dr. Dobbs Journal, Essential books on cryptography, is pretty cool.
The ultimate in security is writing your own DOS for your own HD, and
then using your own medium, &c.
--
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: Are PGP primes truly verifiable?
Date: Mon, 27 Dec 1999 14:29:26 -0600
> E = m c^2. Einstein = Man of the Century. Why the squaring?
>
It's part of the formula, not an embellishment. Since c is the speed of
light, it is *slightly* significant.
--
Only a little over a year left to go in this centrury
Knowing this, figure that a year from now, we will
resale of the hoopla we are getting ready to see now.
--
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: Employing digits of pi
Date: Mon, 27 Dec 1999 12:27:40 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The following is related to some stuff I posted quite a time back
> but not discussed in this special setting as far as I can remember.
>
> It is known that the digits of pi can be computed starting from
> any arbitrarily chosen position. Let n indices giving such starting
> positions be given. One obtains with these n subsequences of pi.
> Now add the corresponding digits of the n subsequences modulo 10
> (or the base, if this is not 10), resulting in a digit sequence
> which we call R.
>
> Questions: Can we do any inference on R? If yes, how does the
> complexity of the task increase with n?
This is just a one-time-pad. I think the deep digits are more expensive
than the early ones to compute, even with the clever hex algorithm.
Therefore, I think it is probably a rather expensive one-time-pad and other
methods would be better. Also, the digit sequence is well known out to a
great distance, so testing against using pi would be as simple as sliding a
segment of digits along until it fits. Further, it would be easy to attack
in parallel. Imagine one million machines, each with a segment of pi digits
from different positions in the sequence. It does not sound very secure to
me.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis
Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #9 Tue, 29 Jun 99 08:13:04 EDT
Contents:
Re: Converting arbitrary bit sequences into plain English texts (Mok-Kong Shen)
Re: one time pad (Coen Visser)
Re: Secure link over Inet if ISP is compromized. ("Douglas A. Gwyn")
Re: PIII Random Number Generator? (Mok-Kong Shen)
Re: PIII Random Number Generator? ("Douglas A. Gwyn")
Re: PIII Random Number Generator? (Mok-Kong Shen)
Re: How do you make RSA symmetrical? ([EMAIL PROTECTED])
Re: Secure link over Inet if ISP is compromized. (Keith A Monahan)
Re: Tough crypt question: how to break AT&T's monopoly??? ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox (Coen Visser)
Re: Why mirrors invert left-to-right (was: Kryptos article) (Nicol So)
Re: PIII Random Number Generator? ([EMAIL PROTECTED])
Re: Quasigroup engryption ([EMAIL PROTECTED])
Re: Block Ciphers and Crpytanalysis ([EMAIL PROTECTED])
Re: Why mirrors invert left-to-right (was: Kryptos article) ("Douglas A. Gwyn")
Re: Moores Law (a bit off topic) ([EMAIL PROTECTED])
Re: trapdoor one way functions ([EMAIL PROTECTED])
Re: How do you make RSA symmetrical? (Gergo Barany)
Re: Hamming Weight ([EMAIL PROTECTED])
Re: Hamming Weight ([EMAIL PROTECTED])
Re: crypt basics ([EMAIL PROTECTED])
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.cbm
Subject: Re: Converting arbitrary bit sequences into plain English texts
Date: Tue, 29 Jun 1999 12:43:43 +0200
Matthew Montchalin wrote:
>
> But I thought that what was really clever was the idea that Boris Kazak
> wrote, namely, where any given passage of ordinary text will ordinarily
> be given in lowercase, but uppercase characters will represent bytes that
> are 'on.' The state of Bits 4 and 6 of each such lowercase character
I said that Boris Kazak's suggestion is very nice. There are two
advantages over my original approach: (1) the file size expansion
factor is only about 8 instead of quite a bit more, (2) the ensemble
of sentences can now really constitute a sensible piece of text
instead of a collection of sentences with numerous repetitions and
without much connections with one another. In fact one can publish
that way the binary executable file of a strong crypto through
encoding it in the text of a book of, say, Charles Dickens. Any
reader, including those in the much feared unfriendly countries, can
easily write two filter programs, one for retrieving the strong
crypto, the other for enjoying reading the English classic.
It may thus be advisable now for the bureaucrats to think of laws to
forbid English books in general in order to suppress the progress
of the science of cryptology. Anyway, several thousand years ago
there was one emperor who ordered the burning of books as a means
to prevent there being educated people coming up who could think of
ideas of overthrowing his empire (overthrown only shortly thereafter).
Finally it may be of interest to note that Boris Kazak's method is
analogous to e.g. amplitude modulation in signal processing. It has
the virtue of being extremely simple to implement (though there
are some people, I believe, who use to equate simplicity to poor
quality in science).
M. K. Shen
=
http://www.stud.uni-muenchen.de/~mok-kong.shen/ (Updated: 12 Apr 99)
--
From: [EMAIL PROTECTED] (Coen Visser)
Subject: Re: one time pad
Date: 29 Jun 1999 10:53:44 GMT
[EMAIL PROTECTED] (Patrick Juola) writes:
>
>The major weakness of the OTP is that it requires that the key
>be as long as the message and sent securely over a channel.
>If you have a secure channel of sufficient capacity to take the
>key, it will also (by definition) take the message -- so why
>are you bothering with using an OTP?
I like to add that "secure" (as in secure channel) is not an absolute value.
OTPs can be usefull if you have more than 1 channel of communication each of
which has a security value less than 1 (absolute security).
Regards,
Coen Visser
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Secure link over Inet if ISP is compromized.
Date: Tue, 29 Jun 1999 10:59:20 GMT
Gene Sokolov wrote:
> ... If Alice sends Bob her public key or starts DH key exchange
> procedure, how does Bob know the data comes from Alice and not her
> compromized ISP?
How does Alice even know there is a human being at the other end
of the apparent link, let alone Bob? If Bob introduced himself
to Alice via the link, how does she know who he is? This issue
involves deep questions of identification, authentication, and
trust. It is evident that it cannot be solved without use of
some trusted agent.
--
From: Mok-Kong Shen <[EMAIL PROTECTED]
Cryptography-Digest Digest #798
Cryptography-Digest Digest #798, Volume #8 Fri, 25 Dec 98 22:13:03 EST
Contents:
Re: Meet in the middle attack? (JPeschel)
Re: On living with the 56-bit key length restriction (wtshaw)
Re: Stego in jpeg files (Ross Presser)
Re: Make Fast Random Number Generator? (Paul Crowley)
Re: biometrics (David A Molnar)
Common Modulus Attack on RSA ("Max")
Re: HELP! Who can decrypt this? ("Michael Scott")
Re: Session keys in Elliptic Curve (David Brownridge)
Re: Common Modulus Attack on RSA (Ian Goldberg)
Re: Questions about Binary Files in C++ (fungus)
Re: Questions about Binary Files in C++ (fungus)
Re: Session keys in Elliptic Curve (Mr. Tines)
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Meet in the middle attack?
Date: 22 Dec 1998 18:04:55 GMT
>Gramps <[EMAIL PROTECTED]> writes:
>What is a meet in the middle attack? I have books on crypto, but they do
>not define that attack. I can guess what it is from the name, but my
>guesses often are wrong.
>From the "Journal of Craptology"
"Meet in the Middle v.i. Plan for covert rendezvous."
Thus, it follows that a "meet in the middle attack" is the
wife showing up with her lawyer.
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto
Subject: Re: On living with the 56-bit key length restriction
Date: Tue, 22 Dec 1998 12:30:58 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Ah, but that wouldn't be the point. I'd like to repeat the point (for
> emphasis) that the crypto export law is silly, and the official reasoning
> is flawed- e.g. the law is supposedly to prevent criminals/terrorists from
> getting their hands on 128 bit crypto. So by definition law abiding people
> won't push the button if it's illegal for them to access it.
It is becoming increasingly useless to try to be law abiding if laws are
silly, contradictory, and perhaps, even unknown or ill-defined; this is
what really undermines respect for the law. People come to not bother
what it says any more; and, the cause for such an attitute is government's
trivialization of its own power. Saying is it the law is insufficient for
a majority of people these days, that is evident in recent headline
events.
--
What goes around, comes around.
You reap what you sow.
Do unto others as you would have them do unto you.
The wheels of the gods grind most slowly, but exceedingly fine.
People in glass houses should not cast stones.
Let those who are without sin cast the first stone.
Judge not that ye be judged.
--
From: [EMAIL PROTECTED] (Ross Presser)
Subject: Re: Stego in jpeg files
Date: Wed, 23 Dec 1998 17:10:57 GMT
On Wed, 23 Dec 1998 14:32:05 GMT, [EMAIL PROTECTED] (R. Knauer)
wrote:
>On Wed, 23 Dec 1998 06:36:53 -0600, "Steve Sampson"
><[EMAIL PROTECTED]> wrote:
>
>>Why are you using two backslashes in the URL?
>>
>>Have you ever gone to any web site using backslashes?
>
>Bill Gates personal web site is rumored to use backslashes.
>
>Bob Knauer
>
>"Laws to suppress tend to strengthen what they would prohibit.
>This is the fine point on which all the legal professions of
>history have based their job security."
>--Frank Herbert
---BEGIN AWFUL JOKE---
Then there's O.J. Simpson's web site:
http:\\/\//\/escape.com
(say it out loud)
---END AWFUL JOKE---
remove NOSPAM to reply by email
--
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Make Fast Random Number Generator?
Date: 23 Dec 1998 10:01:23 -
[EMAIL PROTECTED] (Robert Davies) writes:
> Jim Trek <[EMAIL PROTECTED]> wrote:
>
> >Does anybody here make a fast random number generator or have the
> >capability to design and build one that will provide 2 million or
> >more bits per second for a PCI slot or a universal serial bus?
>
> The Tundra generator goes at 20,000 bytes per second, but it
> plugs into an ISA slot. You could put 4 of them in a single
> PC and run them at double speed to get 1,280,000 slightly biased
> slightly correlated bits per second. Quite expensive.
Eek. For what application is a fast CPRNG fed by a slower random
number generator unsuitable?
--
__
\/ o\ [EMAIL PROTECTED] http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul CrowleyUpgrade your legacy NT machines to Linux /~\
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: biometrics
Date: 25 Dec 1998 03:55:08 GM
