Bletchley Park restoration

[Moderator's note: I posted on this earlier, but I really do want to see Bletchley Park maintained... :) --Perry] IBM and PGP have donated $100,000 to help restore and maintain Bletchley Park as a museum. This money is intended to get others involved - millions more will be needed. Details

More man-in-the-middle'd SSL sessions on the way

From an article about WAN optimization appliances in Computerworld: In some markets, such as health and finance, [hiring] a managed provider [who will do the encryption "outside" your routers] isn't a good option for another reason: Because data is optimized in an unencrypted state

Re: SecurID and garage door openers

| | Speaking of two-factor authentication, can anyone explain how servers | | validate the code from a SecurID token in the presence of clockskew? | | Does it look backwards and forwards in time a few minutes? | | Yes, it rolls forward and back 3-5 cycles. The server maintains a | list of what t

On the difficulty of detection on-line fraud

Not cryptography, but ultimately what we talk about here often comes down to protection that actually works *for people*. Also a good counter to arguments of the form "if only people were more careful" -- Jerry From:[EMAIL PROTEC

Re: PKI too confusing to prevent phishing, part 28

| | | Summary: some phishes are going to SSL-secured sites that offer up | their own self-signed cert. Users see the warning and say "I've seen | that dialog box before, no problem", and accept the cert. From that | po

Re: Java: Helping the world build bigger idiots

| > One thing to consider is that an idiom like this solves an annoying problem. | > Consider a linear search through an array: | > | > for (i = 0; i < lim; i++) | > { if (a[i] == target) | > { | > break; | > } | > } | > /

Re: Java: Helping the world build bigger idiots

| It used to be that checking bounds on certain collections was less | efficient than waiting for the out of bounds exception. I think Joshua | Bloch discusses this in his book. | | I've also seen this in generated code where you aren't sure of the | nature of the object you're indexing and thus d

Re: Clearing sensitive in-memory data in perl

[Moderator's note: forwarded on Jerry's behalf -- he's having mail problems.] | >>So wouldn't the world be a better place if we could all agree on a | >>single such library? Or at least, a single API. Like the STL is for C++. | >> | > | > | > Yes, absolutely, but who is going to do it? | | One co

Re: Query about hash function capability

| Hi all, | | My question relates to hash functions in general and not specifically | cryptographic hashes. I was wondering if there exists a group of hash | function(s) that will return an identical result for sequentially | similar yet rotate/shift wise dissimilar input: | | ie: input1 : abcdef

Re: [Clips] Escaping Password Purgatory

| > Computer Hardware Software | > Escaping Password Purgatory | > David M. Ewalt, 08.03.05, 3:00 PM ET | > | > ... "I think I have passwords for | > over 47 different applications both internal and external that I access, | > and I've acquired those IDs and passwords over several years," says Way

Re: ID "theft" -- so what?

| Jerrold Leichter wrote: | > It's also clear that they don't expect customers to look closely at, or | > question, their bills. If they did, they'd make sure that meaningful merchant | > names appeared on the bills, or at least were available if you called to ask |

Re: ID "theft" -- so what?

| one of the "business processes" is that somebody calls their issuing | bank and disputes a charge by a specific merchant on such & such a date. | the issuing bank eventually provides notice to the merchant (giving the | account number, date, and purchase details). the merchant then looks for | a

Re: ID "theft" -- so what?

| an analogy i've used recently with respect to userid/password paradigm, | is that account numbers are being concurrently used for both the userid | function (requiring security *integrity* but not security | *confidentiality*) as well as the password function (requiring strong | security *confide

Re: ID "theft" -- so what?

| Date: Wed, 13 Jul 2005 16:08:20 -0400 | From: John Denker <[EMAIL PROTECTED]> | To: Perry E. Metzger <[EMAIL PROTECTED]> | Cc: cryptography@metzdowd.com | Subject: Re: ID "theft" -- so what? | ... | Scenario: I'm shopping online. Using browser window #1, I | have found a merchant who sells what

Re: payment system fraud, etc.

| Jerrold Leichter <[EMAIL PROTECTED]> writes: | > In doing this calculation, be careful about the assumptions you make | > about how effective the countermeasures will be. The new systems | > may be more secure, but people will eventually come up with ways to | > break the

Re: Why Blockbuster looks at your ID.

| > Credit card fraud has gone *down* since 1992, and is actually falling: | > | > 1992: $2.6B | > 2003: $882M | > 2004: $788M | > | > We're on the order of 4.7 cents on the $100. | > | > http://www.businessweek.com/technology/content/jun2005/tc20050621_3238_tc024.htm | > The article also menti

Re: Optimisation Considered Harmful

| >Suppose you have something that is inadvertently an | >oracle - it encrypts stuff from many different users | >preparatory to sending it out over the internet, and | >makes no effort to strongly authenticate a user. | > | >Have it encrypt stuff into a buffer, and on a timer | >event, send out th

Re: Optimisation Considered Harmful

| A brief altercation this evening with CERT over the recent hyperthread caching | issues has brought something that's been simmering at the back of my brain to | the forefront. | | The recent hyperthread/cache key recovery trick, followed by DJB's related | (IMO) symmetric key recovery, and prece

Re: AES cache timing attack

| > It's much harder to see how one could attack a session key in a properly | > implemented system the same way. You would have to inject a message into | > the ongoing session. However, if the protocol authenticates its messages, | > you'll never get any response to an injected message. At bes

Re: AES cache timing attack

| Uhh, that wasn't really what I was after, that's pretty much textbook stuff, | what I wanted was specifically advice on how to use block ciphers in a way | that avoids possibilities for side-channel (and similar) attacks. I have some | initial notes that can be summarised as "Don't let yourself

RE: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

| >They also sold a full solution for encrypted Ethernet - KDC, encrypting | >Ethernet adapters, associated software. None of this stuff went anywhere. | >People just weren't interested. | | That wasn't quite the case for the Ethernet encryption. What happened there | was that they had a complete

RE: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

| ...It is not that nobody ever thought of encrypting tapes, it is that there | has been no uptake on the idea because the management overhead costs | outweighed the perceived benefit. The big vendors didn't bother offering it | because they didn't think they could make money, and the start-ups

Re: analysis of the Witty worm

| | The paper itself (there's a link in the article) has several more items | | of interest to this list. Especially interesting is the effective | | cryptanalysis of the PRNG used by the worm. Implicit in many of the | | analyses, though not a focus of the paper, is the amount of information

Re: analysis of the Witty worm

| Readers of this list may be interested in an analysis of the Witty | worm's spread by Kumark, Paxson, and Weaver. An article summarizing | the paper is at http://www.zdnet.co.uk/print/?TYPE=story&AT=39200183-39020375t-1025c | A tentative conclusion is that the worm was probably written by

Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout "Algorithm hiding" ?)

| Perry makes a lot of good points, but then gives a wrong example re Amex site | (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL | Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of | the few companies that actually responded seriously to my

Re: Papers about "Algorithm hiding" ?

| Hi, | | you most probably have heard about the court case where the presence | of encryption software on a computer was viewed as evidence of | criminal intent. | | http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm | http://news.com.com/Minnesota+court+takes+dim+view+of

Re: Secure Science issues preview of their upcoming block cipher

| Jerrold Leichter writes: | >They don't claim that: | > | > This cipher is ... provably just as secure as AES-128. | > | >I can come up with a cipher provably just as secure as AES-128 very quickly | | Actually, I think Adam is totally right. | | Have you lo

Re: Secure Science issues preview of their upcoming block cipher

| Really? How does one go about proving the security of a block cipher? They don't claim that: This cipher is ... provably just as secure as AES-128. I can come up with a cipher provably just as secure as AES-128 very quickly (Actually, based on the paper a while back on many altern

Re: Do You Need a Digital ID?

| Jerrold Leichter wrote: | > I don't think the 3-factor authentication framework is nearly as | > well-defined | > as people make it out to be. | > | > Here is what I've always taken to be the core distinctions among the three | > prongs: | > | > Somethi

Re: Do You Need a Digital ID?

ignature" applications, is also ever used in authentication applications | where the human doesn't observe and read the contents, then the attacker just | supplies a valid document masguerading as authentication bits (which the human | won't be reading and/or understanding). | | note

Re: Do You Need a Digital ID?

| if a re-issued a new token/card (to replace a lost/stolen token/card) is | identical to the lost/stolen token/card ... then it is likely that there is no | "something you have" authentication involved (even tho a token/card is | involved in the process) ... and therefor the infrastructure is just

Non-repudiation

With all the discussion we've seen on this topic, I'm surprised no one has mentioned "Non-Repudiation in Electronic Commerce", by Jianying Zhou. I haven't read this book, but Rob Slade gave it a good review in a year-old RISKS that I happened to stumble across. Any comments from list members?

Re: I'll show you mine if you show me, er, mine

| >Briefly, it works like this: point A transmits an encrypted message to point | >B. Point B can decrypt this, if it knows the password. The decrypted text is | >then sent back to point A, which can verify the decryption, and confirm that | >point B really does know point A's password. Point A the

Re: Can you help develop crypto anti-spoofing/phishing tool ?

| Jerrold Leichter wrote: | > "N-version programming" - which is what you are proposing here - can | > increase | > your level of trust against random errors[2], but its of no use at all | > against | > a deliberate attack. | | I heartly disagree. If the N-outputs are

Re: Can you help develop crypto anti-spoofing/phishing tool ?

| [1] This is also my solution to the famous trust paradox proposed by Ken | Thompson in his " Reflections of Trusting Trust". Trust is earned, not | given. To trust Ken's code, I would first ask two or more programmers (who | I choose) to code the same function and submit their codes to tests. If

Re: Is 3DES Broken?

| > > No, I meant CBC -- there's a birthday paradox attack to watch out for. | > > | > | > Yep. In fact, there's a birthday paradox problem for all the standard | > chaining modes at around 2^{n/2}. | > For CBC and CFB, this ends up leaking information about the XOR of a couple | > plaintex

Re: Is 3DES Broken?

| > >>I think you meant ECB mode? | > | > >No, I meant CBC -- there's a birthday paradox attack to watch out for. | > | > Yep. In fact, there's a birthday paradox problem for all the standard | > chaining modes at around 2^{n/2}. | > | > For CBC and CFB, this ends up leaking information about t

Re: how to tell if decryption was successfull?

| [newbie here] | | I was wondering how can one tell if some data was successfully decrypted. | Isn't there an assumption going on about what the cleartext data should be? | Text? Image? ZIP file? Ziped jpeg? Another cyphertext? rot-13? Without some additional information, there's no way to tell a

Re: entropy depletion

| > | > random number generator this way. Just what *is* | > good enough? | | That's a good question. I think there is a good answer. It | sheds light on the distinction of pseudorandomness versus | entropy: | | A long string produced by a good PRNG is conditionally | compressib

Re: entropy depletion (was: SSL/TLS passive sniffing)

| > You're letting your intuition about "usable randomness" run roughshod | > over the formal definition of entropy. Taking bits out of the PRNG | > *does* reduce its entropy. | | By how much exactly? I'd say, _under the hypothesis that the one-way | function can't be broken and other attacks fai

Re: Cryptography Research wants piracy speed bump on HD DVDs

| To add a postscript to that, yesterday's LAWgram | reported that $10 DVD *players* are now selling | in the US. The economics of player-id-watermarking | are looking a little wobbly; we can now buy | a throwaway player for the same price as a | throwaway disk. | | http://www.theinquirer.net/?a

Re: SSL/TLS passive sniffing

By an interesting coincidence, the article below appeared in the on-line Computerworld today. -- Jerry Universities grapple with SSL-busting spyware Marketscore could be used to intercept sensitive in

Microsoft Passport fades away

>From Computerworld: Microsoft Scales Back Passport Ambitions Microsoft's decision to reposition its .Net Passport identification system comes as Monster.com is dropping support for the authentication service. http://www.computerworld.com/newsletter/0,4902

Re: Printers betray document secrets

| It turns out that their techniques aren't all that useful. | Changing laser printer cartridges changes the results. | You might find that two documents were printed | by the same printer, but it doesn't give you the | options for tracking it down that manual typewriters did. Actually, they say th

RE: "Approximate" hashes

| nilsimsa | Computes nilsimsa codes of messages and compares the codes and finds | clusters of similar messages so as to trash spam. | | What's a nilsimsa code? | | A nilsimsa code is something like a hash, but unlike hashes, a small change | in the message results in a small change in the nilsims

Re: More problems with hash functions

| > However ... *any* on-line algorithm falls to a Joux-style attack. An | > algorithm with fixed internal memory that can only read its input linearly, | > exactly once, can be modeled as an FSM. A Joux-style attack then is: Find | > a pair of inputs M1 and M1' that, starting from the fixed ini

Re: More problems with hash functions

| Bear writes: | > One interesting idea which I came up with and haven't seen a way | > past yet is to XOR each block with a value computed from its | > sequence number, then compute the hash function on the blocks in | > a nonsequential order based on the plaintext of the blocks | > in their n

Re: More problems with hash functions

| > It strikes me that Joux's attack relies on *two* features of current | > constructions: The block-at-a-time structure, and the fact that the state | > passed from block to block is the same size as the output state. Suppose we | > did ciphertext chaining: For block i, the input to the compre

Re: On hash breaks, was Re: First quantum crypto bank transfer

| > Alternatively, how anyone can have absolute confidence in conventional | > crypto | > in a week when a surprise attack appears against a widely-fielded | > primitive | > like MD5 is beyond me. Is our certainty about AES's security really any | > better today than was our certainty about RIPEM

Re: First quantum crypto bank transfer

| > ... the comments I've seen on this list and elsewhere have been much | > broader, and amount to "QM secure bit distribution is dumb, it solves | > no problem we haven't already solved better with classical | > techniques." | | Most of the comments on this list are more nuanced than that. Perhap

Re: More problems with hash functions

It strikes me that Joux's attack relies on *two* features of current constructions: The block-at-a-time structure, and the fact that the state passed from block to block is the same size as the output state. Suppose we did ciphertext chaining: For block i, the input to the compression function i

Re: First quantum crypto bank transfer

| > The press will always focus on things people understand, and which | > seem to have short-term relevance. If you're objecting to researchers | > blowing their own horns ... well, that's the way the world works. | > It's certainly been the way physics has had to work since it became | > impossib

Re: First quantum crypto bank transfer

| Not quite correct, the first bank transfer occurred earlier this year, | in a PR event arranged by the same group: | | | | However, I still don't believe that quantum cryptography can buy you | anything but research funding (and probably e

Re: dual-use digital signature vulnerability

| note that some of the online click-thru "contracts" have been making | attempt to address this area; rather than simple "i agree"/"disagree" | buttons ... they put little checkmarks at places in scrolled form you | have to at least scroll thru the document and click on one or more | checkmar

Re: dual-use digital signature vulnerability

| the issue in the EU FINREAD scenario was that they needed a way to | distinguish between (random) data that got signed ... that the key owner | never read and the case were the key owner was actually signing to | indicate agreement, approval, and/or authorization. They specified a | FINREAD

Re: EZ Pass and the fast lane ....

| ...unless people are willing to go very hi-tech in their toll evasion | maneuvers, implementing, say, thin see-through LCD screens placed over their | license plates that turn opaque at a push of a button A local TV station here in the NY area did a show about a lower-tech version of the same

Re: EZ Pass and the fast lane ....

| > another purpose -- preserving the privacy of drivers by using more | > complicated protocols. However, as the benefit of such systems is to | > people who are unlikely to have much voice in the construction of the | > system, and who are also unlikely to be willing to pay more money to | > gain

Re: EZ Pass and the fast lane ....

| > No mention is made of encryption or challenge response | > authentication but I guess that may or may not be part of the design | > (one would think it had better be, as picking off the ESN should be duck | > soup with suitable gear if not encrypted). | | From a business perspective, it ma

Re: Is finding security holes a good idea?

| Thor Lancelot Simon <[EMAIL PROTECTED]> writes: | | > On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote: | >> Roughly speaking: | >> If I as a White Hat find a bug and then don't tell anyone, there's no | >> reason to believe it will result in any intrusions. The bug has to | > | > I

Re: Passwords can sit on disk for years

| >Tal Garfinkel (related to Simpson?) is a Stanford PHD student who has put | >together a working model for tracking tainted data stored in RAM in various | >popular applications. | | Hmm, one part of the article isn't quite accurate: | | Operating systems such as Windows and Linux have no facil

RE: voting

| "privacy" wrote: | [good points about weaknesses in adversarial system deleted] | | > It's baffling that security experts today are clinging to the outmoded | > and insecure paper voting systems of the past, where evidence of fraud, | > error and incompetence is overwhelming. Cryptog

Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

| Non-repudiation applied to digital signatures implies that the definition | states that only one person possibly had possession of the private signing | key and was conscious about the fact that it was used to sign something. There is absolutely *no* cryptographic or mathematical content to this

Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]

Now that we've trashed non-repudiation ... just how is it different from authentication? In both cases, there is a clear technical meaning (though as with anything in mathematics, when you get right down to it, the details are complex and may be important): To produce an authenticator/non-repudia

RE: Walton's Mountain notaries

| I might be - and it would be interesting to find out. However, that does | not necessarily mean that anyone you could find to witness your signature | also has the knowledge to tie you to that particular Dan Geer so carefully | documented in the genealogy site. | | I have people who can testify

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

| David Wagner writes: | | > To see why, let's go back to the beginning, and look at the threat | > model. If multiple people are doing shared development on a central | > machine, that machine must have an owner -- let's call him Linus. Now | > ask yourself: Do those developers trust Linus? | >

Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project

(The use of memory speed leads to an interesting notion: Functions that are designed to be differentially expensive on different kinds of fielded hardware. On a theoretical basis, of course, all hardware is interchangeable; but in practice, something differentially expensive to calculate on an x86

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

| Rick Wash wrote: | >There are many legitimate uses of remote attestation that I would like to | >see. For example, as a sysadmin, I'd love to be able to verify that my | >servers are running the appropriate software before I trust them to access | >my files for me. Remote attestation is a good

Re: I don't know PAIN...

| On Dec 27, 2003, at 10:01 AM, Ben Laurie wrote: | >> "Note that there is no theoretical reason that it should be possible | >> to figure out the public key given the private key, either, but it so | >> happens that it is generally possible to do so" | >> So what's this "generally possible" busine

Re: I don't know PAIN...

| > "Note that there is no theoretical reason that it should be | > possible to figure out the public key given the private key, | > either, but it so happens that it is generally possible to | > do so" | > | > So what's this "generally possible" business about? | | Well, AFAIK its always possible,

Re: Repudiating non-repudiation

Ian's message gave a summary that's in my accord with how courts work. Since lawyers learn by example - and the law grow by and example - here's a case that I think closely parallels the legal issues in repudiation of digital signature cases. The case, which if I remember right (from hearing abou

Re: example: secure computing kernel needed

| >>> We've met the enemy, and he is us. *Any* secure computing kernel | >>> that can do | >>> the kinds of things we want out of secure computing kernels, can also | >>> do the | >>> kinds of things we *don't* want out of secure computing kernels. | >> | >> I don't understand why you say that. Y

Re: Difference between TCPA-Hardware and other forms of trust

| > | means that some entity is supposed to "trust" the kernel (what | > | else?). If two entities, who do not completely trust each other, are | > | supposed to both "trust" such a kernel, something very very fishy is | > | going on. | > | > Why? If I'm going to use a time-shared machine, I have

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

| > Which brings up the interesting question: Just why are the reactions to | > TCPA so strong? Is it because MS - who no one wants to trust - is | > involved? Is it just the pervasiveness: Not everyone has a smart card, | > but if TCPA wins out, everyone will have this lump inside of their | >

Re: example: secure computing kernel needed

| When it comes to the PC's operating system, | there is apparently no economic way to achieve | what you suggest - ensuring that it hasn't | been tampered with - so few bother to worry | about it. If more security is desired, the | preferred method is to bypass the PC's OS | completely. ...which

Re: origin of SHA 224 initial hash values

| I don't know about 224 and there isn't any 128 but for SHA-1 (160) the | initial values seem to be just an obvious pattern... BTW, it hadn;t occured to me until now, but the 160-bit SHA-1 was presumably designed to go with the 80-bit Clipper encryption!

Re: Additional Proposed Hash Function (Forwarded)

| > | > NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard | > | > that will specify an additional hash function, SHA-224, that is based on | > | > SHA-256. The change notice is available at | > | > http://csrc.nist.gov/publications/drafts.html. NIST requests comments for |

Re: safety of Pohlig-Hellman with a common modulus?

| Is it safe to use Pohlig-Hellman encryption with a common modulus? | That is, I want various parties to have their own exponents, but share | the same prime modulus. In my application, a chosen plaintext attack | will be possible. (I know that RSA with common modulus is not safe.) The question

Re: Additional Proposed Hash Function (Forwarded)

| > NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard | > that will specify an additional hash function, SHA-224, that is based on | > SHA-256. The change notice is available at | > http://csrc.nist.gov/publications/drafts.html. NIST requests comments for | > the change not

Re: lockable trapdoor one-way function

| Does anyone know of a trapdoor one-way function whose trapdoor can be locked | after use? | | It can be done with secure hardware and/or distributed trust, just delete | the trapdoor key, and prove (somehow?) you've deleted it. | | It looks hard to do in "trust-the-math-only" mode... You're going

Re: Are there...

| As David Wagner points out, encryption with a public key (for which the | private key has been discarded) would seem to work. There's something seriously wrong here, however. There are many close, but not identical, definitions, of a one-way hash. While none of them explicitly say so, many *use

Re: A-B-a-b encryption

| > it came up lately in a discussion, and I couldn't put a name to it: | > a means to use symmetric crypto without exchanging keys: | > | > - Alice encrypts M with key A and sends it to Bob | > - Bob encrypts A(M) with key B and sends it to Alice | > - Alice decrypts B(A(M)) with key A, leav

Re: Cryptography as a component of security

| I listened to yet another talk on computer security, which | incorporated security. It got me to thinking two things: | | o Pseudo-random implies pseudo security. | | If you're re-keying by running the old key through a pseudo-random | function without adding any new entropy, then you're not r

Re: NCipher Takes Hardware Security To Network Level

| ... An extreme example of this is the use of formal methods for | high-assurance systems, as required by FIPS 140-2 level 4. Why is it in | there? Because ... the Orange Book ('85) had it in there at the highest | levels. Why was it in there? Because the proto-Orange Book ('83) had it in | th

Re: Software protection scheme may boost new game sales

| I've not read the said article just yet, but from that direct quote "as | the copy degrades..." I can already see the trouble with this scheme: | their copy protection already fails them. They allow copies to be made | and rely on the fact that the CDR or whatever media, will eventually | degrad

Re: Open Source (was Simple SSL/TLS - Some Questions)

| Maybe the solution should be this: You can distribute the binary without | any source code whatsoever, and use this toolkit, unrestricted, in | whatever manner you choose, provided that EITHER you distribute the | source code for the whole product in a form which allows the user to | reconstruct

RE: Simple SSL/TLS - Some Questions

| From: Jill Ramonsky <[EMAIL PROTECTED]> | > From: Ian Grigg [mailto:[EMAIL PROTECTED] | > | > The only question I wasn't quite sure of | > was whether, if I take your code, and modify it, | > can I distribute a binary only version, and keep | > the source changes proprietary? | | You can't

Re: Protocol implementation errors

| >This is the second significant problem I have seen in applications that use | >ASN.1 data formats. (The first was in a widely deployed implementation of | >SNMP.) Given that good, security conscience programmers have difficultly | >getting ASN.1 parsing right, we should favor protocols that us

Re: how to defeat MITM using plain DH, Re: anonymous DH & MITM

[Using multiple channels on the assumption that the MITM can't always get all of them.] This is starting to sound like some very old work - to which I don't have a reference - on what was called the "wiretap channel". Basic idea: Alice and Bob wish to talk; Carol can listen in to everything, but

Re: anonymous DH & MITM

| From: Tim Dierks <[EMAIL PROTECTED]> | | I'm lost in a twisty page of MITM passages, all alike. | | My point was that in an anonymous protocol, for Alice to communicate with | Mallet is equivalent to communicating with Bob, since the protocol is | anonymous: there is no distinction. All the conce

Re: anonymous DH & MITM

| Date: Fri, 03 Oct 2003 17:27:36 -0400 | From: Tim Dierks <[EMAIL PROTECTED]> | To: Jerrold Leichter <[EMAIL PROTECTED]> | Cc: Cryptography list <[EMAIL PROTECTED]> | Subject: Re: anonymous DH & MITM | | At 03:28 PM 10/3/2003, Jerrold Leichter wrote: | >From: Tim

Re: anonymous DH & MITM

| From: Anton Stiglic <[EMAIL PROTECTED]> | From: "Jerrold Leichter" <[EMAIL PROTECTED]> | > No; it's false. If Alice and Bob can create a secure channel between | > themselves, it's reasonable to say that they are protected from MITM | > attacks if they

Re: anonymous DH & MITM

| From: Tim Dierks <[EMAIL PROTECTED]> | >No; it's false. If Alice and Bob can create a secure channel between them- | >selves, it's reasonable to say that they are protected from MITM attacks if | >they can be sure that no third party can read their messages. That is: | >If Alice and Bob are ano

Re: anonymous DH & MITM

| Date: Fri, 3 Oct 2003 10:14:42 -0400 | From: Anton Stiglic <[EMAIL PROTECTED]> | To: Cryptography list <[EMAIL PROTECTED]>, | Tim Dierks <[EMAIL PROTECTED]> | Subject: Re: anonymous DH & MITM | | | - Original Message - | From: "Tim Dierks" <[EMAIL PROTECTED]> | | > | > I think it's a

Re: Reliance on Microsoft called risk to U.S. security

| >> "Can be relied on to _only_ deliver text" is a valuable and important | >> piece of functionality, and a capability that has been cut out of too | >> many protocols with no replacement in sight. While I agree with the sentiment, the text/code distinction doesn't capture what's important. Is H