Re: [OTR-dev] Open source OTR AIM client for iOS

Chris Ballinger chrisballin...@gmail.com writes: Because it's not done yet! :) I still have some crashing problems related to xmppframework buddy lists that are gonna require some work. It's very alpha quality at the moment. The goal is to get it eventually approved on the App Store.

Re: [OTR-dev] Will libotr4 be thread safe?

Paul Wouters p...@cypherpunks.ca writes: On Tue, 1 May 2012, Chris Ballinger wrote: p.s. have you guys considered moving the project to github? If one does that, PLEASE ensure you publish tar balls. github as a really awful upstream provider for linux distribution packages. Seconded (from

Re: [OTR-dev] [OTR-announce] libotr-3.2.1 and pidgin-otr 3.2.1-2 for Windows available

Is there a CVE for the new issue? It seems that 3.2.1 also fixes CVE-2012-3461, but has an additional patch. I've updated pkgsrc for the new libotr. Once it's had a few days, I'll request that this be pulled up to the pkgsrc-2012Q2 branch. NITS: When diffing the two tarballs, there are

Re: [OTR-dev] Packagers: please check out 4.0.0-rc1

http://otr.cypherpunks.ca/libotr-4.0.0-rc1.tar.gz http://otr.cypherpunks.ca/pidgin-otr-4.0.0-rc1.tar.gz So libotr-4 is not compatible with the current release pidgin-otr, and these two have to be updated atomically? pgpS9UqRy25ru.pgp Description: PGP signature

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

Thibaut VARENE vare...@debian.org writes: On Tue, Aug 28, 2012 at 2:16 AM, Greg Troxel g...@ir.bbn.com wrote: In pkgsrc, libotr is simply libotr. Two questions: will just libotr.pc be installed, but with the new versions? If so, I don't see any reason to call this libotr5

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

Thibaut VARENE vare...@debian.org writes: On Tue, Aug 28, 2012 at 2:16 AM, Greg Troxel g...@ir.bbn.com wrote: In pkgsrc, libotr is simply libotr. Two questions: will just libotr.pc be installed, but with the new versions? If so, I don't see any reason to call this libotr5

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

Ian Goldberg i...@cypherpunks.ca writes: Oh, they're good questions. I guess my lack of experience with pkgsrc (and *bsd in general) is showing. :-p Perhaps, but I don't think my questions are bsd-specific - it's more about any system that has to manage lots of software maintained by third

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

One of my paranoid friends showed up, and the new library did not work. I did 'start private' and got a malformed message. I then changed settings to 'default' (vs 'always') and then to 'never', but still was not able to interoperate, even with OTR disabled (the other person probably is setup

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

I looked at the -S output. Basically, I built each way, and then did: rm auth.lo auth.o gmake -n | sed -e 's/ -c / -S /' | sh which put the source in auth.o (and then the link failed). Compilation with -O1/-O2 and with/without the gcc hardening are at:

Re: [OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

Ian Goldberg i...@cypherpunks.ca writes: On Mon, Sep 03, 2012 at 06:40:08PM -0400, Greg Troxel wrote: Ian Goldberg i...@cypherpunks.ca writes: OK, then I guess the thing to do is just to turn off hardening for that build environment? [I believe the hardening is only actually enabled

[OTR-dev] [Greg Troxel] Digested Articles

I'm not sure how many people here care, but pkgsrc has been udpated, so 4.0.0 will be in the quarterly branch that's cut 10/1ish, and thus binary pacakges will be available for a number of platforms. Thanks to Ian for helping me through debugging the gcc/SSP issue. ---BeginMessage--- Topics:

Re: [OTR-dev] Handling of CTCPs and /me in IRC clients

Not entirely related to your query, but I have long found it broken that presence is exposed to servers in the clear. Of course, to fix this one would probably have to have dummy presence sent at a constant rate. - When sending a CTCP TYPING, pass it unencrypted since it's probably

Re: [OTR-dev] Handling of CTCPs and /me in IRC clients

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.

Re: [OTR-dev] What about an OTR org.?

David Goulet dgou...@ev0ke.net writes: I had this yet _crazy_ idea when reading for the last 6 months every threads and discussions about OTR and different IMs using it, new ideas and also not forgetting the Cryptocat threadS :). So here goes. I'm wondering if it would be a good idea to try

Re: [OTR-dev] Codec2 and OTR

tl;dr - There's a thing called 'codec2' http://www.rowetel.com/blog/?page_id=452 which achieves reasonable digital radio performance at 1200bps (although 2400bps is better) The thought bubble was: I wonder if/how/could (etc) OTR could be used to provide encrypted open source digital

Re: [OTR-dev] Clever logging for weechat_otr plugin (+ log management discussion)

\Daniel \.koolfy\ Faucon\ koo...@koolfy.be writes: It's not up to the OTR protocol to define logging policies, so we must make sure OTR implementations behave responsibly. I'm not sure I agree with this. I think it's entirely reasonable for the protocol to say that clients MUST NOT log, and

Re: [OTR-dev] Clever logging for weechat_otr plugin (+ log management discussion)

Paul Wouters p...@cypherpunks.ca writes: For instance, I use full disk encryption, so my logs are perfectly safe. So which full disk encryption program are you using that provides PFS and resistance to subpoena/rubber-hose? Just kidding, really (and I know PFS for a disk encryption program

Re: [OTR-dev] Multiple accounts

Howard Chu h...@symas.com writes: Jonas Wielicki wrote: Adding complications such as key sync, key management, revocation etc. is not what I consider useful for the general case. Indeed, it completely misses the point. OTR provides repudiable communication. Unifying all your keys would

Re: [OTR-dev] mpOTR protocol phases and research questions

Trevor Perrin tr...@trevp.net writes: Deniability is achieved because any party could forge records of communication with other parties that a 3rd-party judge could not, post-facto, cryptographically distinguish from actual records. Because such forgery is possible, malleablility of

Re: [OTR-dev] Allow OTR to use one of my OpenPGP sub/keys?

cypherpunks.b...@xoxy.net writes: Any thoughts on allowing OTR to grab a key from an OpenPGP cert? It might restrict the keys it grabs to those with a uid matching the account. That would allow us to manage our own keys, instead of generating scads of new ones; and it would allow OTR to

Re: [OTR-dev] Persisting userstate object across app restarts.

Madhav V mad...@avaamo.com writes: 3. Alice goes into the app. Bob and Alice apps establish a secure session. The app persist the session on Alice' device. The session is persisted on Bob's device as well. 4. Now Bob can send Alice messages even when her phone is switched off or off the

Re: [OTR-dev] Persisting userstate object across app restarts.

Madhav V mad...@avaamo.com writes: #2.Unlike desktop operating systems both the iOS and Android(latest versions) OSs provide a mature application data sandboxing/protection comparable to RAM on desktops*. When you said RAM only/persistent state, did you mean to include the latest mobile OSs

Re: [OTR-dev] Persisting userstate object across app restarts.

Tom Ritter t...@ritter.vg writes: That said... TextSecure and whatever app you're writing probably _also_ stores the plaintext messages as a history that can be scrolled through. TS is still protected by a password, but in general, my order of importance of OTR secrets is: long term key

Re: [OTR-dev] pidgin-otr release for Debian Jessie?

Ian Goldberg i...@cypherpunks.ca writes: After I build the tarballs (so they can go in distros), I'll have a go at building the Windows binary... Does that sound reasonable? I'll also accept bugfixes to the above plan, if need be. ;-) That sounds fine, except that packaging systems will

Re: [OTR-dev] Attention OTR packagers: provide RC1 feedback by the end of Monday

Ian Goldberg i...@cypherpunks.ca writes: On Sun, Oct 19, 2014 at 09:52:09AM -0400, Greg Troxel wrote: https://otr.cypherpunks.ca/libotr-4.1.0-rc1.tar.gz https://otr.cypherpunks.ca/pidgin-otr-4.0.1-rc1.tar.gz Builds fine under NetBSD 6 i386 (once I accomodated for the tarball

Re: [OTR-dev] Attention OTR packagers: provide RC1 feedback by the end of Monday

Also, my pkgsrc build was against libgcrypt-1.6.2nb2. The nb2 just means two little changes to the packaging -- it's 1.6.2. pgpnvYDRBJhC6.pgp Description: PGP signature ___ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca

Re: [OTR-dev] pidgin-otr release for Debian Jessie?

I have now actually had an OTR conversation with someone, with me using the rc1 tarballs of libotr and pidgin-otr, pidgin 2.10.9, with the other person using Adium. All seems ok. pgpJE24DEkRW_.pgp Description: PGP signature ___ OTR-dev mailing list

Re: [OTR-dev] OMEMO, PFS

Ximin Luo writes: > Hi Greg, allow me to refer you to a previous post I wrote: > > https://moderncrypto.org/mail-archive/messaging/2015/001877.html > > The TL;DR is that to achieve "forward-secrecy for in-transit messages" > you need to have some sort of timeout mechanism,

Re: [OTR-dev] OMEMO, PFS

Ruben Pollan <mes...@sindominio.net> writes: > Quoting Greg Troxel (2015-11-13 17:43:06) >> Nathan of Guardian <nat...@guardianproject.info> writes: >> > Are you sure it was persisting key material? I think the idea with OMEMO >> > is to support the Axo

Re: [OTR-dev] OMEMO, PFS

Thijs Alkemade writes: > Suppose Bob's ephemeral keys are compromised by an attacker at a specific > time, then the attacker can decrypt all messages from Alice since the last > time Bob sent Alice a message before the compromise, up to (and including? I'm > not clear on

Re: [OTR-dev] Peer validity TLV

Ola Bini writes: > Hi, > > Lately I've been thinking about how to communicate the decisions OTR is mak= > ing in such a way that users can make informed choices based on > that. I realized that one thing I've missed when using OTR-enabled clients = > is the possibility of

Re: [OTR-dev] Suggestion: keep track of OTR keys in Pidgin

Ximin Luo writes: > It is true that even this sort of tracking is quite basic though. A > more complex idea would be to automatically verify keys via > pre-existing verified keys, but this should really be part of a > central contacts manager outside of OTR, and could take

Re: [OTR-dev] OTR version 4 Draft #2

Ian Goldberg writes: > On Tue, May 08, 2018 at 02:48:12PM -0400, Jurre van Bergen wrote: >> I think once OTRv4 is out of the door, just like OTRv1, OTRv2 should be >> dropped. @ian? @nik? > > I'm in principle fine with dropping v2 support. I wouldn't mind a quick >

Re: [OTR-dev] OTR version 4 Draft #2

Here is some information on Adium. * stable The current release is 1.5.10.4 dated 4/27/17. This has: Adium.app/Contents/Frameworks/libotr.framework/Versions/3.2.1/ and does OTRv2 only. With pidgin and libotr 4.1.1, and the pidgin instance *having previously done an OTR exchange with the

Re: [OTR-dev] OTR version 4 Draft #2

Ola Bini writes: >> > I'm in principle fine with dropping v2 support. I wouldn't mind a quick >> > look-around at what OTR implementations still don't support v3, though. >> > pidgin-otr does, of course. What about Adium? Others? >> >> By dropping support, is this about