Re: [OTR-dev] mpOTR project
Ximin Luo: On 18/12/13 13:08, Jacob Appelbaum wrote: Ximin Luo: On 17/12/13 20:56, Jacob Appelbaum wrote: Ximin Luo: However, *even if you achieve it*, I would still strongly propose that we stop calling it deniability or off-the-record, for the misleading-users reasons I detailed elsewhere. Generally speaking, we discuss protocols in terms of repudiation and non-repudiation. The word deniable is a mapping of common understanding with the less than common meaning of the word repudiation. I'm fine with equating repudiable/deniable; my complaint was instead directed at using these labels without any sort of qualifier. There are lots of non-cryptographic information leaks, which make certain forms of OTR transcripts non-repudiable in a court. Such as? Adium logging OTR plain text to the disk doesn't count here. Why doesn't it count - because it can happen for plaintext too? That is the whole point. If you want to deny things in court, you have to be more strict. What is the point of being able to deny an OTR transcript, when you can't deny other evidence? It doesn't count because a key point for OTR is to ensure that the plaintext on your disk is the best that anyone can get when you use OTR. That is to say that we do not augment the logs with signature data. The OTR'ed transcripts are just like transcripts that were not OTR. Most logging programs don't even note if the transcripts were the product of an OTR chat or not, for example. If you just provide your own USB drive with a log and claim it's the plaintext, that is not convincing. But if you seize the physical computer with its plaintext logs, that is more convincing. Convincing of what? I can create logs for chats that we haven't had - I can even put them in the right folder structure. That doesn't pass the sniff test for proof - it is circumstantial evidence without cryptography. It is a text file on a computer. Likewise, anyone can forge an OTR transcript, but if you have ciphertext snarfed off the network by some top secret surveillance program, and you compromise one of the endpoints to recover the session key, that is more convincing. For the record, I have not seen evidence that OTR is broken by any surveillance program. Perhaps it's not feasible to provide strong deniability in that sense. I also understand that forgeable transcripts (OTR-deniability) are necessary for strong deniability. But by itself, I don't see it as anything to boast about. Previous to OTR, people used PGP and IM programs, if they did anything at all, I might add. Consider the improvement? As I mentioned elsewhere, no reduction in deniability (compared with plaintext chat) is more appropriate. However, to call OTR simply deniable, repudiable, off-the-record or any similar thing, implies that it has an *advantage* in this area over plaintext chats, when it does not. The OTR (SOUPS, etc) papers very clearly says these things. OTR does have an advantage over plaintext chats - they are encrypted and when someone sniffs them, even if they are unauthenticated, that someone is locked out of the content of the conversation. That is confidentiality, which is separate from deniability. It enhances deniability only insofar as it's an additional layer the attacker needs to break through. If someone breaks your confidentiality, e.g. if your partner is compromised, your level of deniability is back to the plaintext case. So no reduction in deniability is accurate. It is also confidentiality and confidentiality provides some deniability in this case. This is confusing but deniability in the social sense is fuzzy. By contrast, the (theoretical[1]) plausible-deniability property of a censorship-resistant publishing platform like Freenet *does* have an advantage over plaintext storage - since the node operator doesn't have the keys to decrypt the documents he is hosting, he cannot be held responsible for them. That is a red herring if there ever was one, Ximin. How is that a red herring? I'm just comparing use of language. There are a few reasons. One is that we do not know if a person will be held responsible. In some jurisdictions, a government may request a decryption or the production of a key and failing to do so is a crime in itself. Another is the difference between a chat between n parties and keeping some ciphertext around for a long time. You can treat me like an outsider who doesn't know all the contextual literature and connotations of deniability. I'm not treating you like an outsider, I'm asking you to read the documents about the topic because you are a member of the larger anonymity, security and privacy community. I have other connotations from the general society, then I come and read the OTR homepage which has that word. What am I going to think? That you may deny the specifics of a conversation. If you visit a website that claims to be encrypted
Re: [OTR-dev] mpOTR project
Ximin Luo: However, *even if you achieve it*, I would still strongly propose that we stop calling it deniability or off-the-record, for the misleading-users reasons I detailed elsewhere. Generally speaking, we discuss protocols in terms of repudiation and non-repudiation. The word deniable is a mapping of common understanding with the less than common meaning of the word repudiation. SILC exists for group chats if you want an encrypted multi-party chat protocol with non-repudiation (in a court, from a forensics perspective, etc etc). If people are going to re-invent SILC, why not ensure that they don't make the same mistakes? All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] mpOTR protocol phases and research questions
George Kadianakis: (PS, maybe one day courts will *have* to take deniability seriously. This might happen with time as technology gets even more important and even more deniability-related cases get investigated. Or it might happen if people try to *force* the courts to take deniability seriously by forging conversations of people that the courts want to protect. In any case, I wouldn't be surprised if deniability is never taken seriously for important cases like the one you cited.) Deniability is an important property. Any group chat protocol without deniability is sure to be a disaster for some person at some point. To make this discussion clearer I think two properties we specifically need to discuss when we discuss deniablity are repudiation and non-repudiation[0]. Courts *do* take digital signatures seriously. In some US States, digital signature laws make it a legally binding signature. With long term identity keys, we see that Thus if there is a chat protocol that uses signatures in a way that ensures non-repudiation, I believe we have case law, as well as actual digital signature law that makes such non-repudiation legally binding. It also seems clear that it would be hard to explain that either or any person in the chat could have forged it. If signatures may be checked by a third party after the fact, especially signatures that may only produced by the person in question, those signatures *will* be used against people. We know that something as lame as text logs will be used against people - we should strive to ensure that we don't cryptography enhance the logs and make such a task easier. With non-repudiation, transcripts and chat room fragmentation become a serious social as well as a serious security problem. Some multi-party chat protocols likely have this problem already and we shouldn't encourage more protocols to have this flaw. All the best, Jacob [0] https://en.wikipedia.org/wiki/Non-repudiation ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] git mirror, bug tracker, etc
Hi, I've been thinking a lot about git repos, taking patches, doing continuous integration, reproducible builds, bug tracking and so on. Ideally, I'd like one place where people will send us code - as well as where they may report issues. It seems that no one likes or uses Source Forge; I can't really blame them. I also dislike the interface provided by SF... If I had a git mirror on github for OTR code (libotr, pidgin-otr) and other related projects, would people use it? Would they prefer gitorious? Ideally, I'd be able to track a bug report in a way that users will find worthwhile. At the moment, people are contacting me on jabber or irc but the history of the bug reporting is lost. Thoughts? All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] /me bug
Heya, There exists an information leak in Pidgin/Pidgin-OTR where Pidgin doesn't allow Pidgin-OTR to encrypt a specific message before it is sent to the network. Specifically on IRC networks, users who emote through the use of a message such as `/me thinks this is a bug` - will leak the full text of their /me command. This is annoying and it would be nice if Pidgin didn't treat /me messages in this way. It appears that around the same time as learning about this bug, I found a bug report with a fix for Pidgin itself. If there are any Pidgin/Pidgin-OTR users on this list who also use IRC with Pidgin, it would be great to see if the following patch fixes the behavior of /me on irc: https://developer.pidgin.im/ticket/15750 This could also be fixed inside of Pidgin-otr - though I think the right place is inside of Pidgin itself. It would be useful if IRC using Pidgin-OTR developers could test the patch attached to ticket 15750 on the Pidgin bug tracker. Useful questions to answer: Does it solve the /me info leak for you? Does it cause any adverse issues? Does it make sense to put this into Pidgin-OTR? All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Simplifying OTR Deniability
Gregory Maxwell: On Sun, Jul 28, 2013 at 11:46 PM, Arlo Breault arlo...@gmail.com wrote: https://whispersystems.org/blog/simplifying-otr-deniability/ I'm a bit confused by It’s true that by publishing old MAC keys, anyone is capable of modifying the ciphertext of a previously observed message. However, even if that person can guess the plaintext and is capable of making predictable modifications to the ciphertext via a malleable encryption scheme, they still can’t demonstrate valid plaintext to anyone else without the cipher keys (and if they had those, they would be able to calculate the MAC keys anyway). What’s more, since the initial OTR key exchange is signed and transmitted through an unobservable channel (an “outer” ephemeral key exchange), it’s not actually possible for anyone to produce what appears to be a conversation with you. In the context of the fact that libotr actually ships with tools for creating these not actually possible transcripts. Indeed - for those looking - the code for this is in libotr.git/toolkit. Debian and Ubuntu offer binary packages as well: http://packages.debian.org/sid/libotr2-bin In particular, you can just _make up_ an AES key, modify the transcript to say whatever you want assuming that AES key and you get a completely plausable transcript which you know the AES key for that appears to be between the named parties. Am I missing here or is the above quote some really scary commentary to be coming from someone who claims to be 'improving' OTR? I had similar thoughts. Though I generally dislike plain old DSA - I think switching to a very different design and claiming the old properties of the protocol is a bit off the mark. Specifically, it is the case that Moxie's new protocol may offer similar features to OTR - though this remains to be studied, understood and so on. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] RFC standardisation
Paul Wouters: On Tue, 9 Jul 2013, Peter Saint-Andre wrote: I also spoke with Paul about this about a month ago but sadly I can't make IETF since I need to be present earlier at ohm2013, I hope to work on the RFC with Paul there. Will you be there Peter? I will not be at ohm2013 because that appears to overlap with the IETF meeting in Berlin. I'm flying out of Berlin on Friday afternoon, land in Amsterdam at 4pm, and will rent a car to be at ohm for 7pm to speak at the Hugh Daniel memorial crypto session. I've written most of the dane-otr draft, and will work with Peter in Berlin on the main OTR spec. Depending on timing, I'll be in Berlin and happy to help. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Fwd: Re: [xmpp] Proposed XMPP Charter Update
Peter Saint-Andre: Hey folks, there is still interest among IETF participants in seeing an OTR RFC published (Stephen Farrell is one of the Security Area Directors). As mentioned, Paul and I have talked about this, and I recall recent discussion on this list about it (did someone volunteer to work on an Internet-Draft?) but I can't put my finger on the right message. I would be very happy to help work on this with whoever is interested. Peter I'd be interested in working on an information RFC for how OTR works today. I have previously discussed it with Ian and he seemed to encourage such work. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] mpOTR redux - now in git
Nadim Kobeissi: Jacob, as it stands you are currently plagiarizing from the Cryptocat Project. You have not asked for our permission to take our content and list it as your own, and you have not properly credited any of the contributors to the specification or mentioned its original source. The wiki where it was hosted did not credit me or any of the other authors after it was taken out of the CryptoCat git. I'm one of the original authors of the document, I'm not sure why you think that you own my work product? Nor am I sure why you think you own the work of everyone else who wrote the document and thought it would be handled in good faith. If you feel that there are missing credits, I'm happy to add them - the point is to make a living document simply about the mpOTR specification. I'm happy to talk further off list but I don't think this list is productive or relevant to development of OTR. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] mpOTR redux - now in git
Meredith L. Patterson: I don't mean to speak for Nadim here, but I suspect at least some of his concern stems from the redaction of the endnotes in section 10 of the document on the Cryptocat wiki[1], which read Special thanks to Jacob Appelbaum, Joseph Bonneau, [c], to your version[2], which reads This document was authored by a number of anonymous contributors. You were credited, Jake, and it is disingenous and derailing of you to attempt to claim that Nadim did not credit you or think[s] that you own [your] work product. As the academics among us on this list are well aware, plagiarism is a serious concern. I personally have seen far too many instances of plagiarism or likely plagiarism swept under the rug -- including the one that led me to quit my PhD -- to be comfortable with seeing this matter resolved behind closed doors; I would prefer to see it dealt with right here where you brought it up by failing to properly credit Nadim's work. Hi Meredith, I believe you are mistaken and looking at the CrytoCat specification located here: https://github.com/cryptocat/cryptocat/wiki/Multiparty-Protocol-Specification The mpOTR specification that I co-authored is a totally different document and has no attributions whatsoever in the wiki history or in the wiki page itself: https://github.com/cryptocat/cryptocat/wiki/mpOTR-Specification Comparing the first two documents and the mpOTR spec in git should clearly indicate that they are different documents. In fact, the current git repo that I am managing actually properly credits everyone that I remember as even having discussed the topic, including Nadim! Once, we did have some attribution in git history (commits, etc) but it was lost when Nadim moved it to the wiki. Ironically, no one was credited in the CryptoCat document except for Nadim. As I have said previously, I am a co-author of that document and I have never signed a copyright assignment to the CryptoCat project. So, if someone is going to claim plagiarism, claiming to own the document wholesale is pretty unreasonable. In any case, Nadim has just declared his contributions under the AGPL: https://github.com/ioerror/mpOTR/issues/2#issuecomment-13589031 I have thus documented it in the git repository. Again, if something is missing, I'm happy to add it. I do believe that I have added everyone that has made contributions and who was comfortable being credited in public on such a document. And again, lets please take this off of the OTR-dev list - it is sure to be annoying to everyone! All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] [libotr PATCH] Missing opdata when sending message fragments
David Goulet: Hi, I've attached a patch to this email that fixes a problem we've been having in irssi-otr which is that the opdata parameter is always NULL for the inject_message callback with fragments. (FYI, git format-patch was used for the patch). Thanks, I've merged this into a branch (ioerror/pending-patches) for Ian to review. I've tested this patch by talking with a third party client (xmpp-client) and a patched libotr client using bitlbee and another with xmpp-client/irssi. It appears to improve things as before it was applied, I wasn't able to start an OTR session with the other client and stay in sync. Could those who are impacted by this bug go into some details on their clients, how they were broken and how this patch fixed things? It would be good to have this in writing somewhere. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] memory leak in pidgin-otr
Andreas Schlick: Hello, the attached patch fixes what I think is a memory leak and an incorrect call to free() (the message provided by pidgin was allocated by g_strdup() and should be freed by g_free()). Thanks, I've merged this into a branch (ioerror/memory-leak-patch) for Ian to review. Ian and I were both curious about how this didn't cause a crash on Windows. I suspect it is because free() and g_free() somehow behave differently? In any case, I believe that it is correct to g_free() the old message, and then g_strdup() for the message. It also seems reasonable that we should free the old message and set message to newmessage with g_strdup. If nothing else, we should always be using g_* for consistency. It would be nice if any of the Windows users on this list could test these changes to ensure that it doesn't crash or if it did leak memory, to explain why free() doesn't crash whereas we think g_free() would every time? All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Pidgin-otr end conversation
David Goulet: Hi, I'm wondering why pidgin-otr is not notifying the peer when ending a private conversation which seems to be recommended by using otrl_message_disconnect(). Do you see an outgoing message in the pidgin debug menu? I noticed that with irssi-otr -- piding-otr IRC. Do they see any messages from you at all once you end the chat? It's not a critical issue at all but just asking if there is a reason behind this behavior. A trace on both sides should reveal things. All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
Thibaut VARENE: On Mon, Oct 1, 2012 at 7:24 PM, Paul Wouters p...@cypherpunks.ca wrote: On Mon, 1 Oct 2012, Thibaut VARENE wrote: I'm about to upload pidgin-otr 4.0.0 to debian unstable, and it debian already ships libotr-4? Did they add a libotr3 package? Did libotr5, per soname. other OTR software get ported to 4.x already? Or will it just break? libotr5 has been in experimental for a month now. If packages haven't been updated, they'll break, since libotr5 conflicts with libotr2. They'll need a rebuild against the new library package anyway. I think this has already been discussed but... I think this is a rather terrible idea without hearing from most, if not all, of the app developers. I'd suggest that libotr2 and libotr5 are both in the archive and that they *conflict* as Debian packages. We should try to convince the developers to release new versions but if they can't or don't - an older libotr2 package shouldn't simply revert all communications to plaintext. A broken package will probably cause that kind of issue and that is _far_ worse than OTRv3 handshakes... Is there a list of packages that will be broken by this change? Has anyone reached out to those developers? All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] DSA, RSA, ECDSA, etc
Hi, I've been thinking a lot about something written by Nate Lawson on the subject of breaking DSA: http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost-was/ To recap what Ian and most others know - if the RNG goes badly, a single message signed with DSA will leak enough information for an attacker to recover the private key. The theory goes that the RNG won't go badly and so, we're all good. I am not a fan of this strategy. Nate's suggestion is to make the k DSA related to the message - I like this idea. It suggests that if we make k related to the message but still entropic, the chances of things going bad by chance is more throughly negated. One way might be to take a MAC over the message and to take some random bits and ensure that k is derived from the two. Another way is perhaps to take a time stamp hashed with k and then hashed with the MAC of the message. Clearly some cryptographers like Nate have come up with a good way to fix the repeating k problem when the RNG goes badly but such changes are not in libgcrypt... So - a few things come up for me - one is that DSA as it is used in OTR could be dangerous if things go badly with the RNG, we could fix DSA but then we're not really DSA, we're a modified DSA (random k vs deterministic k) - at best with a semi-deterministic k ( k = H( MAC(message), H(random bits + time stamp))) or however it might be called. So is modified DSA better? Do we really care about NIST and their thoughts on the subject when there is a real problem to be dealt with? Is one of the choices better than the other? I think so. I think a totally random K with a bad RNG is deadly, so we could try to detect such a bad RNG but well, who does that? And how shall it be done anyway? It seems that no one really has answered those questions in the Free Software world. The best anyone came up with was some blacklists after the RNG was found to be broken - hardly useful people who are already in trouble. But what is the right way to ensure that k has some safety without being weaker by being predictable? I imagine a lot of OTR conversations start with pretty well known plaintext such as hi or hello or some variant. So a hash or a MAC over that message as part of k isn't really well, unpredictable. I guess this is an open question but one that as it is left unanswered, I worry that it could open people up to problems. I think it would take an active MITM to even begin to collect the data needed for starting to try to attack the messages. That is unless alice is being attacked by bob, her frequent chatting partner - then a conversation is all that it would take - I think. This of course leads me to ECDSA - which unless I'm totally off base would have the exact same issue. So if we want to move to ECDSA at some point - which seems pretty great - what happens? Do we want to tackle the k problem? I wonder then if the right answer is to extend libotr to use RSA - certainly on devices with likely crappy entropy under load and certainly in say, web browsers with highly suspect RNG properties... My first thought is that it would be good to hack up a patch for libgcrypt to have a sign() function in dsa.c that has a k with some relation to the message. I would say that using that would be good if someone like Nate or Ian felt that it would protect against a bad RNG bug, like the Debian bug or such as the recent Usenix security paper by Nadia. My second thought is that it would be interesting to add RSA as a key type to libotr. If so, what key size is reasonable? I'd wager that 1024 for RSA is dead now for some attackers - what seems reasonable if it was to be used for the next ten years? 2048 bits? I'd welcome a converstaion on these topics as I'd like to add an RSA key type at the very least. I want to reach a consensus on how to improve libgcrypt's dsa sign() function or to make a different sign() function that is slightly improved in this specific case. I think that would improve the chances of Werner accepting the patch and others using it. I haven't started on the RSA work in libotr yet. I have already written some basic libgcrypt patches such as checking for cases of 0 where it can't be but I haven't really decided on how to modify k yet. All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] DSA, RSA, ECDSA, etc
Hans-Christoph Steiner: On 09/24/2012 02:59 PM, Gregory Maxwell wrote: On Mon, Sep 24, 2012 at 2:49 PM, Jacob Appelbaum ja...@appelbaum.net wrote: [snip] But what is the right way to ensure that k has some safety without being weaker by being predictable? I imagine a lot of OTR conversations start with pretty well known plaintext such as hi or hello or some variant. So a hash or a MAC over that message as part of k isn't really well, unpredictable ed25519 (a ECDSA like algorithm for signing over a particular curve) solves this elegantly by using r=SHA512(data_being_signed || secret_stored_with_dsa_privkey). If the same privkey signs the same message twice you just get the same signature, and obviously don't leak anything by having two copies of the same thing. if SHA512 is a good pseudo-random oracle then the random number is good. (And putting the secret at the end probably reduces some concerns with extension attacks against Merkle-Damgard hash functions like sha512). Outside of the crypto reasons, I think that ECDSA is very nice for things like SMS and mobile messaging since its a lot smaller. So ECDSA support in libotr would be a lot more interesting to me than RSA. Plus, it sounds like TextSecure is already pretty close to OTR with ECDSA, so there is a working prototype to hammer on and find out what breaks in the real world. I agree - ECDSA would be a good addition. I'll leave the RNG and k tricks to the pros :) Heh - my thoughts exactly. :( All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] DSA, RSA, ECDSA, etc
Gregory Maxwell: On Mon, Sep 24, 2012 at 2:49 PM, Jacob Appelbaum ja...@appelbaum.net wrote: [snip] But what is the right way to ensure that k has some safety without being weaker by being predictable? I imagine a lot of OTR conversations start with pretty well known plaintext such as hi or hello or some variant. So a hash or a MAC over that message as part of k isn't really well, unpredictable ed25519 (a ECDSA like algorithm for signing over a particular curve) solves this elegantly by using r=SHA512(data_being_signed || secret_stored_with_dsa_privkey). r? Not k? What happens if k repeats? If the same privkey signs the same message twice you just get the same signature, and obviously don't leak anything by having two copies of the same thing. if SHA512 is a good pseudo-random oracle then the random number is good. (And putting the secret at the end probably reduces some concerns with extension attacks against Merkle-Damgard hash functions like sha512). If you have two copies of the same thing where the signature uses a repeating k then all hope is lost. All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] DSA, RSA, ECDSA, etc
Nate Lawson: On Sep 24, 2012, at 1:31 PM, Adam Langley wrote: On Mon, Sep 24, 2012 at 4:06 PM, Jacob Appelbaum ja...@appelbaum.net wrote: r? Not k? What happens if k repeats? Ed25519 is a Schnorr signature based system and so the variable names are slightly different. It has the same RNG problem as (EC)DSA however and Ed25519 solves it with deterministic signatures. Since (EC)DSA generally has non-deterministic signatures, I'd recommend maintaining that property in any generic implementation: i.e. hash in the private key, message and entropy to generate k. That's what we do in Google systems. But what is the right way to ensure that k has some safety without being weaker by being predictable? I imagine a lot of OTR conversations start with pretty well known plaintext such as hi or hello or some variant. In OTR the data that is signed includes the two, ephemeral, DH public keys, not any user message. Therefore a deterministic signature shouldn't be problem because the signed data is random. Jake, I appreciate your care in reviewing OTR for these kinds of robustness issues. I have to admit, I never would have considered it had I not read your blog, so hey, thanks. :) I think providing defense in depth for PRNG implementations and their input entropy is often overlooked. Agreed - the lesson of the Debian bug is that we have bugs we cannot see and later, we will feel their impact _if we're lucky_ enough to know. I generally favor keeping PRNG components independent and combining their final output. For example, you might take /dev/urandom output, the hash of the message, a timestamp, the last nonce, and the DH publicly exchanged values (e.g., g^x and g^y, NOT the key 'x' itself or the g^xy session key aka 's'). All of these would be hashed to create the nonce. That seems reasonable. What would you suggest for the actual hashing? OTR already uses SHA256 - I think we can ensure that we will always have SHA256 around in libgcrypt. Shall I use that and call it a day? The general idea is that complete failure of any one (or possibly more) inputs should not destroy your application's security. If /dev/urandom becomes 0 and the timestamp repeats, you still have a unique and unpredictable nonce for a given pair of users for each unique message at a given index in this conversation. That is exactly the property that I would like for this extended dsa sign() function. :) I think something like this should be done in addition Adam's point that the DH public values are part of the message. It doesn't hurt to duplicate the use of them in this way, feeding directly into the nonce creation instead of implicitly by being part of the message itself. If someone changes the message format, these kinds of implicit contracts have a chance of being forgotten. Absolutely. Anyway, you should carefully review how this nonce is created and not throw in the kitchen sink. I'm happy to see a specific proposal. I'll start working on a patch; it seems like any other proposal wouldn't be very specific. :) All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] mingw build instructions/improvements
Paul Wouters: On Wed, 22 Aug 2012, Jacob Appelbaum wrote: Pidgin should really harden their builds. My attempts in that area have been stalled for quite some time and I've basically given up on them: http://developer.pidgin.im/ticket/13879 I think we want to add hardening options to all of the libraries we use during the build process. We could easily hack up some patches for our own build process and if they'd like it, we can send them upstream. Any thoughts on that Ian? Just make sure you do not override, but only add to the common build flags like CFLAGS and LDFLAGS et all. Because otherwise you will be undoing the distro's defaults. For example relro and -fPIE are part of the redhat build system flags. Sure - for the mingw stuff, we don't use their flags - we set them all manually. It's pretty manual overall. All the best, Jake ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] Testing with wine rather than native windows (questions in-line)
Hi, For various reasons, I'm testing OTR 4.0.0-rc1 with wine - I wanted to document this process as a very basic way for Free Software inclined folks to do a very basic win32 functionality check. Things seem to work but I've found a few issues that seem worth addressing. If you're on Debian or Ubuntu install wine: sudo apt-get install wine Fetch pidgin: cd /tmp; wget -c http://downloads.sourceforge.net/project/pidgin/Pidgin/2.10.6/pidgin-2.10.6.exe Fetch pidgin-otr: cd /tmp; wget -c http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-4.0.0-0-rc1.exe Run pidgin's installer with wine: wine pidgin-2.10.6.exe Note that if you haven't already prepared your Wine environment with the required GTK libraries, pidgin will download and install it. Consider yourself warned if your local network tampers with the bits that flow across it. :( It fetches the gtk files over http from this url: http://pidgin.im/win32/download_redir.php?version=2.10.6gtk_version=2.16.6.0dl_pkg=gtk It also fetches debug symbols over http from this url: http://pidgin.im/win32/download_redir.php?version=2.10.6dl_pkg=dbgsym I've filed those two observations as a security issue on the pidgin bug tracker: http://developer.pidgin.im/ticket/15277 I also found a proxy bypass issue that is related to their Tor/Privacy Proxy support: http://developer.pidgin.im/ticket/15276 Now assuming that pidgin installed correctly, we'll install pidgin-otr: wine pidgin-otr-4.0.0-0-rc1.exe I found that this ran without any errors or complicated steps. Run Pidgin: wine C:\Program Files\Pidgin\pidgin.exe Now you'll want to enable the pidgin-otr plugin. This is done by checking a box in the plugins window for it. Is there a way to flip this bit when we install the pidgin-otr plugin? If so, it would be *really* nice. I created a test account and tested it against an older OTR enabled client. It seemed to work well. Keys automatically generated after I started to chat with my other client. It took a few full round trips before the OTR chat picked things up - is that a result of solving the OTR-wars? Seems better than an OTR-war if so... I noticed a few pidgin debug log errors. These four lines appear when double clicking on the OTR plugin in the plugins window: (18:18:12) Gtk: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed (18:18:12) Gtk: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed (18:18:12) Gtk: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed (18:18:12) Gtk: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed I noticed a seemingly unintended consequence of the anti-logging, pro-privacy feature. This was in my log files after I started a chat: (06:15:24 PM) pidgin-otr-test...@jabber.ccc.de/pidgin-wine-otr: hello (06:15:36 PM) x...@jabber.ccc.de: hello (06:16:21 PM) x...@jabber.ccc.de: how are you? (06:16:31 PM) x...@jabber.ccc.de has not been authenticated yet. You should authenticate this buddy. Certainly an improvement but perhaps not the right balance? I tried to SMP auth with a QA - when my old pidgin client canceled, the new one was told An error occurred during authentication. I think that isn't strictly correct but perhaps that's desired? When I start the SMP QA auth process on my OTR 4.0.0-rc client, I have the following debug log errors: (18:27:58) Gtk: gtk_box_pack: assertion `child-parent == NULL' failed (18:27:58) Gtk: gtk_box_pack: assertion `child-parent == NULL' failed (18:27:58) Gtk: gtk_box_pack: assertion `child-parent == NULL' failed When I start it from my older client, my new OTR client has these debug log errors: (18:29:30) Gtk: gtk_box_pack: assertion `child-parent == NULL' failed (18:29:30) Gtk: gtk_box_pack: assertion `child-parent == NULL' failed When I start a new conversation from my old client with OTR, I get this debug log errors: (18:33:03) g_log: purple_conversation_get_type: assertion `conv != NULL' failed The UI opens a window on the new pidgin and says: (06:33:09 PM) Private conversation with x...@jabber.ccc.de started. Your client is not logging this conversation. I checked the log file and sure enough, we don't see any new log entries at all. Yay! (I'm off to grind on pidgin for a bit for some more obvious privacy/security issues while I have it open...) All the best, Jacob ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
