Re: [OTR-dev] OTR version 4 Draft
On Tue, 13 Dec 2016, Rosalie Tolentino wrote: I am Rosalie from the STRIKE team at Thoughtworks, and I'd like to present a draft of OTR version four: https://github.com/twstrike/otrv4 The STRIKE team has incorporated many updates such as a new Deniable Authenticated Key Exchange, the Double Ratchet Algorithm, and the replacement of SHA-1 and SHA-2 with SHA-3. Further details about these and other decisions are included in the "architecture-decisions" folder. So I am very confused about this specification. This is your version of what you would like to be otrv4, but you are not the OTR team, so this is not anything "official" ? Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] upcoming protocol revision
On Mon, 9 May 2016, Ian Goldberg wrote: For now, I guess there's this thread: https://lists.cypherpunks.ca/pipermail/otr-dev/2016-March/002447.html which derailed into a discussion about reproducable builds. I never saw any answers to my questions in that thread :/ https://lists.cypherpunks.ca/pipermail/otr-dev/2016-March/002448.html Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] ChatSecure iOS v3.0 Released
On Mon, 5 Jan 2015, Chris Ballinger wrote: I'd like to announce the release of ChatSecure iOS v3.0: https://chatsecure.org/blog/chatsecure-ios-v3-released/ The most significant user-facing changes are: I have tried it out but the iOS app completely locks up when trying to authenticate a buddy. My phone is jailbroken so I can probive you with files from the phone it that would help with debugging. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Persisting userstate object across app restarts.
On Mon, 11 Aug 2014, Ian Goldberg wrote: I can see why you want to do this, but it more or less breaks the Perfect Forward Secrecy property to write the encryption keys to other than RAM. So I would be concerned about this being labeled as OTR. I agree with Greg. You're planning to store *session keys* in persistent state? Please don't do that. Is there another way we can tackle the sending a message to a user that is offline problem? That is a very legitimate issue for users using otr on their phones. Could a user that goes offline perhaps generate a new session key that would be terminated as soon both users are online again? I guess in a way the real fix is to send the message via openpgp in that case. Although anything pgp is pretty much unusable :/ Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] pidgin-otr problems receiving packets
On Mon, 21 Oct 2013, Moritz Warning wrote: The problem seems to be that one message has a size of 2578 Bytes and the protocol send it as two packets (1490+1088bytes payload). The first packets contents starts with ?OTR:AA... the seconds packet starts in the middle of the whole message. That looks like a bug. OTR fragments start with ?OTR|, not ?OTR: So your first packet appears to be unfragmented according to the protocol. The second message should also start with a ?OTR| prefix. It looks like the message got fragmentated at another layer? Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] empathy bounty
On Wed, 18 Sep 2013, Ian Goldberg wrote: On Wed, Sep 18, 2013 at 06:26:31PM +0200, Max wrote: Hi all. Out of curiosity - are you guys aware of http://freedomsponsors.org/core/issue/333/telepathy-should-support-otr-encryption ? Just wonder if someone would like to have 400+ bucks :) But see also http://lists.cypherpunks.ca/pipermail/otr-users/2009-September/001710.html See also https://wiki.gnome.org/Empathy/FAQ#Will_Empathy_have_OTR_.28.22Off_The_Record.22.29_support.3F Which seems naively outdated in todays world where spy agencies compete for our plaintext traffic. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] /me bug
On Fri, 13 Sep 2013, Ian Goldberg wrote: You want IRC to show a literal /me to the other person, and not use the CTCP ACTION? What if, when the user types /me action, the prpl-irc plugin passes /me action to the pidgin-otr plugin, and sends the result as a PRIVMSG. Then the receiving prpl-irc plugin, when it decrypts and *receives* PRIVMSG ... /me action from the sender, treats it as if it had received ACTION action? The trick would be that the sending (but not the receiving) prpl-irc would need to know whether OTR was enabled, but it could easily check that after the emit of sending-im-msg returns? If I type /nonexisting, you also want to send that over IRC, rather than just generate an error that that command doesn't exit? I can't speak for Paul, but I wouldn't say so. I mostly want an accidental typing of /me or /whatever to not leak plaintext during an OTR conversation: otr session active Hi Mr.Snowden /me is scared about the NSA --- leaks plaintext about that secret file. The password is: /secretliesandstatistics- leaks plaintext Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] /me bug
On Tue, 10 Sep 2013, Peter Saint-Andre wrote: EionRobb would it be more preferable to not have /me as a command and instead detect the /me in the send_im() func? EionRobb so that /help doesn't show ... me, me, ... /commands on non-irc chats should not be processed by the irc module. Does this apply to /me in other protocols, or only IRC? Ian seemed to imply that it was only IRC, but XMPP has support for /me too. I was not aware XMPP also suported /me. I'm also not sure what that means for XMPP. All I want is that it does not leak plaintext :) Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] RSA signatures again
On Sat, 24 Aug 2013, Peter Saint-Andre wrote: Ian, what's your take on this? Should we support it? If so, I'd like to add the keytype number for RSA in the upcoming OTR draft. It's my understanding the RFC draft is simply describing the current protocol, not proposing future extensions. Is this not the case? That is correct -- the Internet-Draft will document the current protocol only. Yes, which is why I specifically asked Ian. If this was going to get added soon[tm], then I wanted to make sure we would cover it. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Simplifying deniability
On Tue, 30 Jul 2013, Trevor Perrin wrote: [Note that I'm not a cryptographer, just a protocol implementer...] No. It simply means Alice got an automated reply from Bob's machine. With what Moxie specified, a full transcript doesn't even mean that much. I don't understand this. Either Alice gets some kind of answer from Bob or his machine, or not. I don't see how the protocol implementation matters for this. Bob could be 6000km away without internet connectivity. This is very different from giving a digital signature that requires Bob to use a passphrase or pin to create it (eg PGP) But it's also different from an implicitly authenticated, all-DH key agreement. Such a key agreement does not create 3rd-party verifiable digital signatures *at all*. Thus full transcripts can be forged more easily, without interacting with Bob. Again, I am not a cryptographer, but I wouldn't say make easier is a very compelling reason to change the crypto (neither is DSA is hard, one should be using standard and verified crypto libraries) I'm not sure what publishing MAC keys adds. Repudiation. While I'm not sure there is legal value in that, it does provide it. If the NSA says this proves Alice said X, you can say The NSA could have create that message themselves, it is not proof without reasonable doubt. When the NSA says this, what is the this? If they are pointing to a full transcript from one party to a conversation that shows all plaintext / ciphertext / secrets, then they will have the MAC keys regardless of whether they were published. Could you elaborate on your scenario, and explain how publication of MAC keys helps? As I said, I think there is low value in revealing the MAC. It will mostly depend on the judge. The difference is subtle. It's the difference between the police had access to the house and could have planted drugs in the suspect's house and we don't know how the drugs ended up in the house, but the police could have planted it if they used a locksmith to plant drugs there. Neither argument will be very convincing on its own, police tends to not do these things and it is still more likely the suspect actually placed the drugs in their own house. But if the police behaviour is under investigation, then this difference might lead to a more reasonable doubt of the ease of which the police could have done things. When someone sniffs all traffic, they basically have the keys to easilly create forgeries with the libotr command line tools available to everyone. If the mac keys were not leaked, it needs more then just a network sniffer - one needs access to one of the two end point machines. While Peter and I are specifying the OTR protocol as an IETF draft, it is pretty important that _cryptographers_ (not protocol designers) look at this new tripple DiffieHellman variant, and whether it does indeed have a significant advantage. Aside from the previously mentioned reasons (DSA is hard and something with MAC forgability that is still not clear to me) the other argument was message size. With fragmentation supported in OTR, and only the SMS network being stuck to such small 140 character limit, I find this argument not very appealing either. (especially with SMS usage sharply decreasing in both usage and price) Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Simplifying deniability
On Tue, 30 Jul 2013, Trevor Perrin wrote: As a SIGMA-based key exchange that uses signatures, OTR is a bit less deniable per [1]. Performing OTR key agreement with Bob gives Alice a signature from him, which she could not produce herself. No. It simply means Alice got an automated reply from Bob's machine. Bob could be 6000km away without internet connectivity. This is very different from giving a digital signature that requires Bob to use a passphrase or pin to create it (eg PGP) I'm not sure what publishing MAC keys adds. Repudiation. While I'm not sure there is legal value in that, it does provide it. If the NSA says this proves Alice said X, you can say The NSA could have create that message themselves, it is not proof without reasonable doubt. The transcripts I was talking about represent complete protocol runs. AFAICT, Gregory's just describing making up an AES key and some plaintext, encrypting it, then splicing it into a bunch of ciphertext and claiming it came from Bob. If the attacker can make up new keys, splice in new ciphertext, and get some 3rd party to believe this all came from Bob, why can't the attacker make up a new MAC key, too? Because it is the _old_ MAC, and it is not longer used or trusted by Alice or Bob. You can only forge messages _in the past_. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Patch to pidgin-otr spec
On Sat, 27 Jul 2013, Ian Goldberg wrote: On Sat, Jul 27, 2013 at 11:19:28AM -0400, Sam Kottler wrote: I submitted a patch [1] to the pidgin-otr queue last week and Jacob asked me to follow up on the list to make sure someone takes a look at it. It's a really trivial fix, just adds intltool as a buildrequires. Let me know if you've got any questions. -Sam 1. https://sourceforge.net/p/otr/patches/5/ Yup, it's in Paul's queue. (Paul maintains the Fedora build stuff.) mock build had already spotted it. I fired off libotr 4 into rawhide yesterday and pidgin-otr 4 just now. I'll build and update these as a bundle for f18/19 in the next couple of days. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] draft-wouters-dane-otrfp-00 and draft-wouters-dane-openpgp-00
As mentioned, I was working on drafts to improve publishing OTR and PGP public keys. You can find the drafts here: https://tools.ietf.org/html/draft-wouters-dane-otrfp-00 Abstract The Off-the-Record (OTR) protocol exchanges public keys in-band. This document describes how to use DANE to securely associate an Instant Message user identified by their email address with an OTR public key. This association helps to authenticate users and protect against MITM attacks. https://tools.ietf.org/html/draft-wouters-dane-openpgp-00 Abstract OpenPGP is a message format for email (and file) encryption, that lacks a standarized secure lookup mechanism to obtain OpenPGP public keys. This document specifies a standarized method for securely publishing and locating OpenPGP public keys in DNS using a new OPENPGPKEY DNS Resource Record. Please discuss the drafts on the appropriate IETF mailing lists, even if you simple agree with the draft. That way, the IETF knows there is an interest in these. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] draft-wouters-dane-otrfp-00 and draft-wouters-dane-openpgp-00
On Mon, 15 Jul 2013, Peter Saint-Andre wrote: Those look good. Thanks for writing them! Thanks! now on to the main spec! Please discuss the drafts on the appropriate IETF mailing lists, even if you simple agree with the draft. That way, the IETF knows there is an interest in these. That would be the d...@ietf.org list or also others? Yes. I am not sure where else discuss either one of those. There is no OTR working group, and the openpgp working group also closed down. I opted to not send these to i...@ietf.org, but somehow I think the non-dane people should see a notification of these as well. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] RFC standardisation
On Thu, 11 Jul 2013, Earl wrote: Hopefully secure end-to-end file transfer will be considered and included in the RFC. The RFC will just codify the current OTR specification, which does have a property for generating a (temporary) symmetric key to use for encryption of bulk data, such as audio/video and files. The implementation of that is client and IM protocol specific though. I don't think we can specify much (perhaps only something for XMPP?) Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] RFC standardisation
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. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Clever logging for weechat_otr plugin (+ log management discussion)
On Thu, 14 Mar 2013, Daniel .koolfy Faucon wrote: For instance, I use full disk encryption, so my logs are perfectly safe. And I prefer having my logs because I often need to look up things from my logs. From Quinn Norton's article about the Aaron Swartz prosecution: http://www.theatlantic.com/technology/archive/13/03/life-inside-the-aaron-swartz-investigation/273654/ Encryption doesn't take away the responsibility of logging. In some contexts, you might be forced to cooperate legally or violently. Strange game, the only winning move is not to log :) Listen, There is nothing I can do to help you when your government can coerce you with torture or financial ruin. You will talk regardless what's encrypted on your hard disk. In fact, I'm sure they will be very helpful and _write_ the log entries they want admitted from you. OTR is to protect my communications. It is not there to prevent me from having coversations with anyone. I need conversastion logs. In fact, I've used what at the time seemed volatile unimportant log messages for a court case. If you write opensource software that does not have a logging capability, you'll find people rewriting your software. If you don't talk to people who might log conversations, good luck expanding that policy to have any communication. Like only mailing people using encrypted email. Currently, the tools are just not feasable for such policies. And if you insist, you'll end up isolated and unable to talk to most people. What more could a hostile government want from a dissident? Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Clever logging for weechat_otr plugin (+ log management discussion)
On Wed, 13 Mar 2013, Daniel .koolfy Faucon wrote: - Logging should be deactivated for the entire duration of the OTR session by *DEFAULT*, and the only way to re-activate it should be on a per-conversation basis, manually. I voluntarily refused to add an easy command to re-enabling the systematic logging of OTR conversations. Doing so is toxic I disagree. While I (reluctantly) agree with a default no logging policy, it should be possible for users to enable this. The choice here is really a user preference and has nothing to do with the protocol. Therefor, free software should not try to dictate local user policy. For instance, I use full disk encryption, so my logs are perfectly safe. And I prefer having my logs because I often need to look up things from my logs. Especially if OTR becomes the default enmasse, not allowing people to log their conversation is a sure way to get them to not use OTR. Putting any kind of notification in the protocol is silly, because you cannot trust the client is actually doing what it says. It adds as much security as those snapchat phone applications offering self-destruct photo sending options. It's a total false sense of security. OTR is about protecting the transport of your conversation. Whether or not you can trust your conversation partner's security setup is something everyone has to consider before talking to them. The best OTR can do is to not leave cryptographic evidence that can be used against you. But it ends there. twitter, facebook, sms, iMessage, email. It is all blending. Would you design email software where you can only read a message once and then it would self destruct? No. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Forward secrecy/deniability for long messages with low overhead
On Tue, 26 Feb 2013, Sergio Lerner wrote: Read the spec. there is a separate method for negotiating a symmetric key using OTR. You then use that key for the bulk transport encryption. I don't know from the top of my head if Alice and Bob have a way of acknowledging the key for destruction, but I would expect so. Yes but you don't get forward secrecy for the file during transmission of a 1 Gb file. If you can't keep a session key secret for the duration of the transfer, you are toast. cycling a AES key because you don't trust it for more then 5 minutes instead of one hour buys you a factor 12, which is basically nothing in order of magnitudes crypto normally works at. If they can break 1 AES key per hour, they can also break 12 keys per hour, and you're much better of doubling the bit size of the 1 key. PFS helps you using a long term key (years) that generates session keys (hours, minutes). PFS has nothing to do with the breaking capability of symmetric ciphers. You're fighting the wrong battle, Paul ___ 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
On Mon, 25 Feb 2013, Peter Saint-Andre wrote: 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. Peter and I have currently scheduled to work on this at IETF in Orlando on March 13, 1pm+ Feel free to join us if you are there, Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Extra symmetric key
On Mon, 14 Jan 2013, Dev Random wrote: Is the extra key meant to be used for out of band data? Yes, the key is not meant to be used in OTR-encrypted messages. Thank you, that makes sense now. It is meant to be used for file encryption, voice chat stream encryption, etc. etc. It should probably not be stored for re-use. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] What about an OTR org.?
On Sat, 12 Jan 2013, Peter Lawler wrote: IIRC, pidgin(1) [formerly gaim(1)] similarly didn't need a foundation etc until AOL tried suing the pants off them http://en.wikipedia.org/wiki/Pidgin_(software)#Naming_dispute http://en.wikipedia.org/wiki/Pidgin_%28software%29#Naming_dispute Whilst I can't speak for those involved, I deeply suspect having a foundation before the suit turned up would've saved a number of contributors a lot of pain, heartache and stress (and subsequently may not have delayed releases/patches as much as it may have done). Pete. P.S. AFAIK I can chat about the AOL thing, however I believe that others involved may have been required to sign agreements banning them from discussing it ever again... P.P.S. Given the previous PS, this email will self destruct in 3... 2... 1... You are right that ensuring the name/trademark using a formal non-profit is useful, although being right and surviving a lawsuit with the name intact are two different things, and forming a non-profit does paint a target on your back as well. In most cases, a rename of the software is much much cheaper, and the energy is better spent on the software, than on the battle for the name, especially if that battle means you can't really release new versions. I still don't think OTR requires an organisation at this moment, and one way of securing the naming rights would be to write up the spec as RFC, something Peter and I keep reminding each other of, but we never manage to do before the next IETF. Paul ps. See https://nohats.ca/wordpress/openswan/ ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] What about an OTR org.?
On Thu, 10 Jan 2013, Greg Troxel wrote: David Goulet dgou...@ev0ke.net writes: So here goes. I'm wondering if it would be a good idea to try to create an OTR foundation or non profit organization or whatever we can think of (OTR project à la Tor) that would basically regroup libotr This conflates two separate things: nonprofit structure and registration a group of people to actually do things Setting up a nonprofit in the US is hard and takes years; one needs to have a board, file annual reports, etc. I suspect it's just as hard in Canada. This has very little to do with actually hacking on code. Indeed, and would only take away more time from the coding part for those people involved. The real issue is getting good people with free time. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] irssi-otr 1.0.0-alpha1 message length interop issue with pidgin-otr
We see messages being dropped between irssi-otr and pidgin. It seems the irssi user sees everything, but pidgin is missing some messages. We think it might be length related. (03:05:26 PM) bleve: did you get long msg? (03:05:30 PM) LetoTo: no (03:05:40 PM) LetoTo: do a counter and let's binary search? (03:05:49 PM) bleve: disapears. (03:05:57 PM) LetoTo: 1234567890123456789012345678901234567890 (03:06:01 PM) LetoTo: thats 40 (03:06:06 PM) LetoTo: can you do that? :) (03:06:31 PM) bleve: I tried :-) (03:06:35 PM) LetoTo: nope (03:06:37 PM) LetoTo: half it :) (03:06:44 PM) bleve: that was 80 chars now. (03:06:56 PM) bleve: 12345678901234567890 (03:07:01 PM) LetoTo: (03:06:56 PM) bleve: 12345678901234567890 (03:07:03 PM) LetoTo: got that (03:07:30 PM) bleve: 30 ? (03:07:34 PM) LetoTo: nope (03:08:17 PM) bleve: 12345678901234567890123456789 (03:08:19 PM) bleve: 29 (03:08:21 PM) LetoTo: yes (03:08:36 PM) bleve: 30 ? (03:08:57 PM) bleve: no 30 ? (03:09:15 PM) LetoTo: no 30 Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Handling of CTCPs and /me in IRC clients
On Mon, 17 Dec 2012, Greg Troxel wrote: CTCP TYPING is (to my knowledge) only used in bitlbee, which is (as said) an IRC to IM gateway. So when Alice (using bitlbee) sends a CTCP TYPING Thanks. I didn't understand that, and guessed that IRC had a native i-am-typing mechanism like jabber. I withdraw my semi-objection. It _is_ a bug and I've reported it before. I have it too with pidgin, even when I use jabber to someone, where the /me has no meaning, the irc plugin seems to grab this and it gets bypassed as well. I understand this was related to pidgin not being able to select/prioritise plugins. But also, if I _do_ want to send a /command to irc, then pidgin-otr should _not_ try to encrypt it (and prob not att the spaces/tab morse code) It's a problem, but I'm not sure if we know how to properly address this yet. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] irssi-otr 1.0.0-alpha1 authentication interop issue with pidgin-otr ?
On Mon, 10 Dec 2012, Paul Wouters wrote: On Sun, 2 Dec 2012, David Goulet wrote: https://github.com/cryptodotis/irssi-otr I packaged it up and tested it. It seems to work for me. Testing with multiple logins, no otr wars etc :) So we did find one interop issue. It seems an irssi user and a piding user cannot authenticate each other. We tried using shared secret, and I tried on the pidgin side using questionanswer (but I'm not sure if the person on the irssi side had that option or confused it for secret) If any irssi-otr user wants to test this, I'm letoams on freenode (in #fedora-devel) Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] fedora packages for irssi-otr 1.0.0-alpha1
On Sun, 2 Dec 2012, David Goulet wrote: https://github.com/cryptodotis/irssi-otr I packaged it up and tested it. It seems to work for me. Testing with multiple logins, no otr wars etc :) http://people.redhat.com/pwouters/otr/ Are there plans to fix the xchat-otr plugin? Paul ps. Conrad: I can co-maintain this package if you want ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] fedora packages for irssi-otr 1.0.0-alpha1
On Mon, 10 Dec 2012, David Goulet wrote: https://github.com/cryptodotis/irssi-otr I packaged it up and tested it. It seems to work for me. Testing with multiple logins, no otr wars etc :) http://people.redhat.com/pwouters/otr/ Are there plans to fix the xchat-otr plugin? Not on my side for now. Although, Crypto.is would be quite happy to have someone contributing to create an up to date version and maintain it. Okay, then I think the original irc-otr package might need to be split in two. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] [RELEASE] irssi-otr 1.0.0-alpha1
On Sun, 2 Dec 2012, David Goulet wrote: We are happy to announce the rebirth of irssi-otr now only supporting libotr4 with some enhancement to the last version of 2009. :) It's an alpha one version meaning that we want to get it out there, reviewed, tested, broken down, etc... before any stable tag is set. Any comments/contributions on build system, compilation, usability, fixes, security, OTR usage, bugs!, etc... any feedbacks is more than welcome. Don't hesitate to email or fill up a bug on github. https://github.com/cryptodotis/irssi-otr Download: https://github.com/cryptodotis/irssi-otr/archive/v1.0.0-alpha1.zip We hope to be able to quickly push packages for distros and get it out there once stable! How does this relate to http://irssi-otr.tuxfamily.org/ Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] [RELEASE] irssi-otr 1.0.0-alpha1
On Mon, 3 Dec 2012, David Goulet wrote:
https://github.com/cryptodotis/irssi-otr
How does this relate to http://irssi-otr.tuxfamily.org/
It's a forked and now a huge refactoring.
We had a *lot* of trouble getting in touched with Uli. He reappeared
three or four months ago saying he still wants to maintain the project
but disappeared again and we did not heard from him either on IRC or
by mail.
It's nothing against his project but the forked here came after having
trouble with the code, build system and maintainer ship so we decided
to fork it, enhanced it and move it on the cryptodot.is github to
build an open source community around it stimulated by cryptodotis. :)
It does. My confusion was that the tuxfamily one claims it is not only
for irssi but also xchat, bitlbee, etc. So if that is still the case,
then irssi-otr is not the best name for the software. On top of that,
the fedora irssi-otr package comes from the source package irc-otr,
so that confused me further. But now I see that it links to:
ftp://download.tuxfamily.org/irssiotr/irc-otr-%{version}.tar.gz
Perhaps coming up with a totally new name would be better for everyone?
paul@bofh:/vol/home/paul$ grep otr /usr/share/dict/words | wc -l
927
plenty of choice for puns and jokes :)
Paul
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] Adding dnssec/dane to OTR enabled clients
On Mon, 19 Nov 2012, Jurre van Bergen wrote: I just came across the following link: https://www.internetsociety.org/deploy360/blog/2012/11/got-a-dnssec-project-that-needs-funding-apply-to-nlnet-foundation-before-dec-1/ Apparantly NLnet has some money left over, might be nice to apply if you are knowledgeable of dnssec/dane and would like to add it to Adium, Pidgin and perhaps others? Would be a nice addition imo! It's really two projects, 1) DNSSEC / DANE support for the TLS certificates of the IM servers 2) OTRFP support 1) would be nice, although in theory, if the underlying crypto library supports DNSSEC/DANE, then pidgin/adium does not need specific support for it (and a project to get DANE in openssl is underway, and the gnutls people are working on it too, just for nss I'm not sure what the plans are) 2) is a short RFC, and not too much code, but it requires we first write up OTR as an RFC, which is a much bigger task but Peter and I wanted to get that started for some time now. Paul ___ 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!
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 other OTR software get ported to 4.x already? Or will it just break? Interested, because I hadn't yet uploaded libotr3, and if most software has been ported in debian, then I would just skip that and push libotr-4 and pidgin-otr-4 into fedora rawhide. Paul ___ 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!
On Wed, 29 Aug 2012, Ian Goldberg wrote: Indeed, that's what Thibaut noticed, and I sent a patch to correct already. Oh, did not realise it was the same issue... I'm looking at providing libotr3 and libotr packages, as I don't think all the apps will port their code to the new library in reasonable time. Why libotr3? It's version 4 of the library, and the soname is 5. On Debian-like systems, the old package was libotr2, and the new one will be libotr5. The version of the old libotr is 3.x.x, so the compat package would then become libotr3-3.x. (as to not conflict with libotr-4.x.x) Paul ___ 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!
On Thu, 30 Aug 2012, Ian Goldberg wrote: Depending on how it's packaged, the runtime packages may be disjoint (the shared lib has a different name in each version), but the -dev package (with the header files) has the same filenames, so you'd be limited to installing one -dev package at a time. But it may be that only pidgin-otr in pkgsrc uses libotr; if so it's easier to just upgrade both at once and leave the old libotr behind. That would indeed be the easiest thing, if true. In Fedora/EPEL libort is used by: [paul@thinkpad ~]$ repoquery -qa --whatrequires libotr bitlbee-otr-0:3.0.4-3.fc17.x86_64 bitlbee-otr-0:3.0.5-1.fc17.x86_64 climm-0:0.7.1-4.fc17.x86_64 irssi-otr-0:0.3-5.fc17.x86_64 kdenetwork-kopete-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-7:4.8.5-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.3-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.3-1.fc17.x86_64 kdenetwork-kopete-libs-7:4.8.5-1.fc17.i686 kdenetwork-kopete-libs-7:4.8.5-1.fc17.x86_64 libotr-devel-0:3.2.1-1.fc17.i686 libotr-devel-0:3.2.1-1.fc17.x86_64 mcabber-0:0.10.1-3.fc17.x86_64 pidgin-otr-0:3.2.1-1.fc17.x86_64 xchat-otr-0:0.3-5.fc17.x86_64 So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Do the old libotr and the new interoperate? Specifically, if one person is running the current pidgin-otr/libotr, and another both new ones, can they still talk? Yes. The new one will just fall back to the old protocol when speaking to old clients. Just to clarify (and confirm I'm right), the above listed software cannot just use libotr-4. They need to be fixed for libotr-4. However, code fixed to use libotr-4, can talk to clients based on libotr-3 and libotr-4. Paul ___ 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!
On Thu, 30 Aug 2012, Ian Goldberg wrote: So 7 clients use it, so I am not going to assume all of these can fix their code within a few days. Indeed not. They can continue to depend on the old version of libotr. (Your libotr3 package, if I understand it? But does that mean you have to change all of the above packages to explicitly name libotr3? If I understand the Debian/Ubuntu method correctly, the package name has been libotr2 all along, and all those other programs name libotr2 as their dependency. The new package will be libotr5, and programs that update their use of libotr can then switch their dependency to libotr5.) Yes, I will send patches to the maintainers of these to change their Require: libotr to Require: libotr 4. The libotr3 package will supply libotr 4, while the libotr package will supply libotr = 4. As I am the pidgin-otr maintainer, I am going to ensure it is released as an update at the same time as libotr gets bumped to 4. Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
Re: [OTR-dev] mpOTR-dev Mailing List!
On Mon, 20 Aug 2012, Nadim Kobeissi wrote: Hey guys,Time to create the mpOTR-dev mailing list! Let's not lose the momentum we built at Usenix Security! I still have the notes, so create the mailing list so we can discuss them (looking at you, Ian!! ;) ) Why not use otr-dev? The list isn't that busy? Paul ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
[OTR-dev] pidgin-otr 4.0.0 beta crasher
Program received signal SIGSEGV, Segmentation fault.
otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1)
at otr-plugin.c:901
901 if (!g_hash_table_lookup_extended(conv-data,
otr-ui_selected_ctx, NULL,
(gdb) bt
#0 otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1)
at otr-plugin.c:901
#1 0x7fffe4defa8d in otrg_plugin_conv_to_selected_context
(conv=0x0,
force_create=0) at otr-plugin.c:916
#2 0x7fffe4df9b0b in check_incoming_instance_change (
account=optimized out, sender=optimized out, message=optimized
out,
conv=0x0, flags=optimized out) at gtk-dialog.c:3256
#3 0x74eee2aa in purple_signal_emit_vargs (instance=optimized
out,
signal=0x74f48e18 received-im-msg, args=0x7fffb6e0)
at signals.c:482
#4 0x74eee3fe in purple_signal_emit (instance=optimized out,
signal=optimized out) at signals.c:434
#5 0x74eec691 in serv_got_im (gc=0xd57b50, who=optimized out,
msg=optimized out, flags=PURPLE_MESSAGE_RECV, mtime=1336072740)
at server.c:608
#6 0x7fffe2529c9a in irc_msg_handle_privmsg (irc=0xd52290,
name=optimized out, from=optimized out, to=0xc76520 LetoTo,
rawmsg=optimized out, notice=1) at msgs.c:1274
#7 0x7fffe252f940 in irc_parse_msg (irc=0xd52290, input=
0xc8be20 :NickServ!NickServ@services. NOTICE LetoTo :You are now
identified for \002letoto\002.) at parse.c:747
#8 0x7fffe2527f5d in read_input (irc=0xd52290, len=optimized out)
at irc.c:665
Looking at the code:
/* Given a PurpleConversation, return the selected instag */
otrl_instag_t otrg_plugin_conv_to_selected_instag(PurpleConversation *conv,
otrl_instag_t default_val)
{
otrl_instag_t selected_instance;
if (!g_hash_table_lookup_extended(conv-data, otr-ui_selected_ctx, NULL,
(void**)selected_instance)) {
selected_instance = default_val;
}
return selected_instance;
}
Looks like it is not expecting that conv can be NULL, and
that conv-data always points to something.
This is happening when i startup pidgin and click on
the accounts to go online in the account manager window
Paul
___
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
