User talk:Shellreef

From Wikipedia, the free encyclopedia

Hello there, welcome to the 'pedia! I hope you like the place and decide to stay. If you need pointers on how we title pages visit Wikipedia:Naming conventions or how to format them visit our manual of style. If you have any other questions about the project then check out Wikipedia:Help or add a question to the Village pump. Cheers! --maveric149

Hi Shellreef. Congratulations on your contributions to chemistry so far, they have been of a very high quality. You might want to have a look at Talk:List of compounds and Wikipedia:Votes for deletion -- you caused a bit of a stir with List of compounds without articles. I'd appreciate your opinion on this matter. I may as well take the opportunity to plug my own project while I'm here: have a look at Inorganic table information and its talk page. -- Tim Starling 01:40 10 Jun 2003 (UTC)

Me again. Please don't create redirects from subtopics back to topics, like what you did for potassium hydroxide. Such redirects cause "loop links", which are very annoying. See wikipedia:Redirect. BTW, how about filling in your user page, or maybe, say, acknowledging this comment? EARTH TO SHELLREEF. EARTH TO SHELLREEF. COME IN SHELLREEF. PSHHHHHHHHH. :) -- Tim Starling 16:05 13 Jun 2003 (UTC)

Hi. Sorry about that. :) I'll get working on my user page ASAP (I've been studying for finals.) Jeff Connelly

No problem. I thought maybe you were schizophrenic, but studying for exams is a good excuse too :) I hope they went well. -- Tim Starling 10:13 16 Jun 2003 (UTC)

[edit] MITM edits

On the MITM page, you added something about the Interlock protocol. If I correctly understand, that protocol requires Alice and Bob to share a password. That password needs to be transfered using a channel that is not under MITM attack, so the Interlock protocol is not an exception to the paragraph you added it to. Please tell me it you disagree.

I see you removed the preposition 'possibly' that I used to describe chosen ciphertext attacks. But if Bob does not act apon the messages he decrypts, then the attacker will not be able to deduce anything about the plaintext, and no chosen cypher text attack will be possible.

Lastly you have incorrectly marked the change as minor. -- Nic Roets 17:02, 27 July 2005 (UTC)

Supposedly, the forced-latency interlock protocol can prevent MITM without a shared secret. See Defense Against Middleperson Attacks and Full-Duplex-Chess Grandmaster (was: anonymous DH & MITM). We must distinguish between a man-in-the-middle attack and an attack where Mallory "hijacks" a session with Alice for herself, without passing on the messages to Bob. Zooko says:
I certainly don't claim that the Interlock Protocol can prevent Mitch from playing a game with one person and also playing a game with a second person, but I do claim that it can prevent Mitch from pulling the "Full-Duplex-Chess Grandmaster" trick.
And Leichter clarifies:
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 can be sure that no third party can read their messages. That is: If Alice and Bob are anonymous, they can't say *who* can read the messages they are sending, but they might be able to say that, assuming that their peer is following the protocol exactly (and in particular is not releasing the shared secret) *exactly one other party* can read the message.
Note that here "shared secret" refers to the secret obtained from the anonymous DH key exchange. In summary, as far as I can tell, the forced-latency interlock protocol can prevent MITM attacks, but it makes no guarantee of the authenticity of the second party. For this reason, it is especially useful for preventing MITM attacks when one or both parties wish to be anonymous.
I have updated Interlock Protocol with the forced-latency modification. I have been unable to find any working MITM attacks on it (not of the hijacking kind, which it doesn't attempt to prevent) but if there are any I'd be willing to update the text.
I agree with you about chosen ciphertext attacks, but the sentence precluding the list already says "The MITM attack may include one or more of:", so the additional qualification is unnecessary in my opinion.
Thanks, Jeff Connelly 19:45, 5 August 2005 (UTC)
Who said anything about chess games or some anonymous communication ? We are concerned with the problem of secure communication between 2 predetermined parties. If that is not clear from the heading of the article, we need to change that. People reference this article when analysing real world protocols like TLS and enigma machines and realworld hardware such as telephone systems, couriers etc.
You say yourself that after improving the interlock protocol it still does not attempt to prevent certain MITM attacks ('hijacking'). Perhaps you need to explain in the article exactly what the protocol requires and achieves. -- Nic Roets 01:01, 8 August 2005 (UTC).
The protocol prevents MITM, not hijacking. I wouldn't consider hijacking MITM, since the attacker is not in the middle--he is at the other end, not in between two parties.
"the problem of secure communication between 2 predetermined parties" is the job of authentication, not MITM-prevention schemes. We are concerned with preventing a third party from reading, inserting, or modifying "messages between two parties without either party knowing that the link between them has been compromised."
Authentication and preventing MITM are often closely related. However, authentication has no meaning in anonymous communication, but it still makes sense to prevent MITM between two anonymous (non-predetermined) parties.
I have updated Interlock Protocol with more information. Let me know if you disagree. -- Jeff Connelly 08:37, 10 August 2005 (UTC)


Here is a picture to clarify things:

A <-----> Z <------> B    A nor B know of Z: this is a MITM attack
A <-----> Z               B is not talking at all, no one is in the middle: not MITM

With anonymous communication, A doesn't care whether she is talking to Z or B. It makes no difference, since by definition of anonymity, neither of them can be authorized. Could you really call an attack where no one is in the middle a man-in-the-middle attack? Maybe, but I don't believe this imprecision belongs in an encyclopædia. I could be way off base, but I haven't been convinced otherwise. -- Jeff Connelly 08:46, 10 August 2005 (UTC)

"I wouldn't consider hijacking MITM, since the attacker is not in the middle" This attack can be described as the attacker deleting every message that A is sending before they reach B and inserting messages to A in the correct fashion. So you are describing a sub attack and MITM is more general, just like MITM is a generalization of eavesdropping. Perhaps this hijacking subattack should be explicitly mentioned in the MITM page. Afterall, an encyclopædia should correctly explain technical terms that are at odds with the lay-man's interpretation.
"... is the job of authentication, not MITM-prevention schemes". If you have no reason to fear a MITM attack, you can just use DH. So I'd say that a complete MITM-prevention scheme would include some authentication scheme.
I think to resolve the issue we should drop the 'addisional transfer' section. Then after the subattacks section, we can have a something that resembles a theorem for '2 predetermined parties', namely that no matter how good your encryption / authenication scheme is, you will always need a transfer of the initial key material over a channel that is not under MITM attack. -- Nic Roets 23:10, 13 August 2005 (UTC)

[edit] Merger proposed: DSSP (programming) → Setun

It has been proposed to merge the content of DSSP (programming) into Setun. Since you have previously edited one of these articles, I thought you might be interested. You're welcome to participate in the discussion if you like. --B. Wolterding 07:50, 20 July 2007 (UTC)