From evan@adiumx.com Thu Feb 9 07:59:21 2006 From: evan@adiumx.com (Evan Schoenberg) Date: Thu, 9 Feb 2006 02:59:21 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think Message-ID: --Apple-Mail-18-103488079 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've seen this backtrace in the Adium crash reporter a couple times... 0 Libgaim 0x04a62ba8 _gcry_mpi_free 32 1 Libgaim 0x04a5da58 otrl_auth_handle_v1_key_exchange 1320 2 Libgaim 0x04a57f0c otrl_message_receiving 1164 3 Libgaim 0x04a54054 process_receiving_im 192 4 Libgaim 0x04a0654c gaim_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER 64 5 Libgaim 0x04a05fe8 gaim_signal_emit_vargs_return_1 304 6 Libgaim 0x04a05ea4 gaim_signal_emit_return_1 108 7 Libgaim 0x04a03d64 serv_got_im 156 8 Libgaim 0x049de5f8 incomingim_chan4 564 9 Libgaim 0x049e086c gaim_offlinemsg 156 10 Libgaim 0x049cef6c icqresponse 420 The usual user explanation is typified by this user's: "sent an otr-ed message to an offline contact. everytime i log on, it crashes again." Any thoughts? -Evan --Apple-Mail-18-103488079 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I've seen this backtrace in the = Adium crash reporter a couple times...

0 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a62ba8 = _gcry_mpi_free =A0 32
1 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a5da58 = otrl_auth_handle_v1_key_exchange =A0 = 1320
2 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a57f0c = otrl_message_receiving =A0 1164
3 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a54054 = process_receiving_im =A0 192
4 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a0654c = gaim_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER = =A0 = 64
5 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a05fe8 = gaim_signal_emit_vargs_return_1 =A0 = 304
6 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a05ea4 = gaim_signal_emit_return_1 =A0 108
7 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x04a03d64 = serv_got_im =A0= 156
8 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x049de5f8 = incomingim_chan4 =A0 564
9 = =A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x049e086c = gaim_offlinemsg =A0 156
10=A0 = Libgaim=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = = 0x049cef6c = icqresponse =A0= 420


The usual user explanation is typified by = this user's:
"sent an otr-ed message to an offline contact. everytime i log = on, it crashes again."

Any = thoughts?

-Evan
= --Apple-Mail-18-103488079-- From ian@cypherpunks.ca Thu Feb 9 15:18:58 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 9 Feb 2006 10:18:58 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think In-Reply-To: References: Message-ID: <20060209151858.GZ31179@smtp.paip.net> On Thu, Feb 09, 2006 at 02:59:21AM -0500, Evan Schoenberg wrote: > I've seen this backtrace in the Adium crash reporter a couple times... > > 0 Libgaim 0x04a62ba8 _gcry_mpi_free 32 > 1 Libgaim 0x04a5da58 > otrl_auth_handle_v1_key_exchange 1320 Good catch. Try this patch: Index: auth.c =================================================================== RCS file: /cvsroot/otr/libotr/src/auth.c,v retrieving revision 1.3 diff -u -r1.3 auth.c --- auth.c 30 Oct 2005 21:01:15 -0000 1.3 +++ auth.c 9 Feb 2006 15:14:36 -0000 @@ -1188,7 +1188,7 @@ unsigned char *buf = NULL, *bufp = NULL; unsigned char *fingerprintstart, *fingerprintend; unsigned char fingerprintbuf[20], hashbuf[20]; - gcry_mpi_t p, q, g, y, received_pub; + gcry_mpi_t p, q, g, y, received_pub = NULL; gcry_sexp_t pubs = NULL; size_t buflen, lenp; unsigned char received_reply; In the event of certain error conditions, received_pub was being gcry_mpi_release()d before it was initialized. Oops. *covers face in shame* ;-) I'm not saying this is exactly the problem you're seeing, but it seems pretty likely. Thanks for the report! Fixed in CVS. - Ian From evan.s@dreskin.net Thu Feb 9 15:34:11 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Thu, 9 Feb 2006 10:34:11 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think In-Reply-To: <20060209151858.GZ31179@smtp.paip.net> References: <20060209151858.GZ31179@smtp.paip.net> Message-ID: <1E01301F-162A-4C1B-8959-08364B22C035@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-19-130778326 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 9, 2006, at 10:18 AM, Ian Goldberg wrote: > In the event of certain error conditions, received_pub was being > gcry_mpi_release()d before it was initialized. Makes perfect sense. Thanks for the quick fix; I can definitely believe that was the source of the problem. I'll let you know if the crash is reported again with it applied. :) -Evan --Apple-Mail-19-130778326 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD62D0I5gp6xQhrvcRAkaFAJ41mGh9smeLxq7xhOQaU26LPIf3cgCaAwxA Tnc4UtsalcCH5gj6fercVR0= =WV1d -----END PGP SIGNATURE----- --Apple-Mail-19-130778326-- From asm@CS.Stanford.EDU Tue Feb 14 02:04:46 2006 From: asm@CS.Stanford.EDU (Andrew S. Morrison) Date: Mon, 13 Feb 2006 18:04:46 -0800 Subject: [OTR-dev] OTR Formal Analysis Security Properties Message-ID: <20060214020446.GA4865@xenon.Stanford.EDU> --FkmkrVfFsRoUs1wW Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As mentioned awhile back, myself and a partner are working on a formal security analysis of OTR. Before we try to break it, I just wanted to send you what we're working on in terms of what security properties OTR claims to see if we're in agreement. Attached is a PDF of our working definitions for the properties that should hold on OTR. Do you guys agree or disagree on any of the definitions? Is anything missing? Are any of the claims too strong or weak? Thanks. --=20 Andrew S. Morrison asm@cs.stanford.edu (650) 575 9261 --PEIAKu/WMn1b1Hv9 Content-Type: application/pdf Content-Disposition: attachment; filename="otr_properties.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nK1azZLbNhK+z1PomFRZXDT+cbSrNrVJlStZZ2r3kguH4niYSOKE lOydl0r2FfJm2yCABiFxJDnZ8mHKFAj079dfN/jrilWwYv5f/Nvs7n69+9sHufo43v26gumn 9KfZrd7d44/4XzAVB6VW94934T1Ycekqq81Kg6qEE6v73d1X399/+Pr+5zvJKqOZX3i/ufvq h6F/9k+FrBjjLj5th0PXjv45HiBWAJVTCvwBa8UrBgCrNbeVddPq73q/EngFBlTawT9yFYCS Nj561+/3bX30P6yFqMCq1RoE7jz9+na/GdrPk4CisgqSgO/7YejGfj+9JlXFhPOHi0rK8OI3 /hddaW2ESIc/DMd6eImbcaaSVCDeTKKi6MIkZTljOqqqVyArITWfVAUnK2nMai155YCHHfxK LitwLm367SQbvqhAJKkPw2QTDpVAweLDzbE5dEETPMutXOU013I6S7OKGXTUGl+xKMdsY47e 5WmPfti0w7S1qiyH9PgQXIB+EjzZe/IrrmKWk2GGx37YTf6GCrUMT2v/wFZsZkG/rN7GhUyy tHRsm+PQHSYBbKUURcxL2MPbLj2q9/X2ZeymMBIGLWaSdfrHKC0wnRR4miIGdOWYSqd9/9v6 /qldf2gbVNv/bFAYBjL+vGvHsf7Y7T9OscGdqzR6ae2toCGYYOiDZTBeFIdkmabfRpc5MGm3 zyGOHGpr50GMkmsr0qPxqd5OL3NeaeeSpL8P42QUQJ8alrbctL/v22grMO5cV6VF2uE5JiJn 6G7JzxKRa/SD0V8k7OdufIqyggJ+GivK0cufplxB2XMIt0P3+BKzRUmXIqMKxzBmdFLz393h KYYkyPT6eGyml9HwLkXEUwgSbiRfVjvH6TrCBFRGmeBTdGCQP1oEYc8YivbJ1pspvQWigWDq qqm4AGEW/GoUeWXXJyUE+XrThuhRmPCQJI7giiZAtElHH8cYnPhYcRI1+1+DSbu+Pw4BGNA0 M2DwxtcUUH8sYYetDFhzm8CcJYGb4HGQklz21DYxLVjO1V+WIqO6f4p5LSrBeIrK8MxV0gqX RH7IKES1oamPYxscjEJpK5ODrzhM2+ywfdtuYmaDJtyqN5vOY2zALom7cAK//7b/6R66bUAv gXVRUe5H9FJCZSelosYcVbDLxnWGkmQZeoe2OURI5SIdjUj7OdUkIKvVAe8wxLUWKX0QfHGL l1SuuUh2r/ebCD7cGkr+bEYyfP1L3BXLGZAC+y5mm689ogDQmgyGeYGlDEqDCS1nUV0fUs3D lTeZzIL5f8TjGAFNokvjs20XVGWVdFRk2phhap4+BrPCUli9/de3P/7wdinN0OTSc5bC5Keb oQuAq+SwHz58++P7pb04LnOWPEA2cmS3fX+IrsKKSnXzN0y9WAw4T7Fy/zT0x49P/fEwoZ9C 7zLSJ0cBzI2AyGoxN04SrwsQiEowl9w6tI+RcGCqZ3in9JBanOKa8dwsLXweun3TPW+Dk5DA IUlMgfB22zVtxEep6JWfvlpCQmSFmpB10UOTrYjZ/vT1mxgBQlCovOsfYoyChS84790y8CLW UxWcncfJTO+xqvSBiSIFQs4pbz9zMXJwe6OIDS6eSVbF3e0KfW+EnZoDTGGGkLQSvu44My1m S4foSmIQ29V6vvKSxKJ0S3ksusVIqa8fyz1gov/KY+cq8tKNpydh5CmjblBwLbALcr6L8UXx un5lFJSHeuJs5XQow8S7pJ5xLKpHK6N6bmqwRAkumIcik6fvjuOhmzoCgb2Cotp4g9zfveJk I2aRNAHLWmP1Nk4VReCbUM20MYT//RAh1xhpTtJfV4ZTLjd96o60TOIskc19sAK2IJrghOo4 R6bnCJFuYMqcEdmOvYZ3t14opIjEThLqBgCtUCd9uZTHSo5HOUv93bVSLoB/iQTJNvURLbuP S5V2BMGpbAvfDPMCypvaWy+wYWxUgBq4WWhJSNKERmryHpYFTuw3hBsGOHOkzqH9mBpA4Qlw 8krothE4ODn1Tag9WEvImnPEB0lYvShVwmpWWUXlvx4yd6a6+NTv2zFRK0UBiSrt47YaCKcP iS1AFt43SpGqIzF0mnp7KnMgraXTtpvIl7DnN1AYvs7DAJl8mnoDjEtDXOzWxBjGOg0N0DfC knNebbAwSISkYCVaxiuuSKTY7Hg5OT9JFawSxC1ySceD6eQ+HANGZUBY0JuMZxUl76wdoHQK QSZnLCw0c5HoOm1vTn2fZJRL3lHVjNmaAtXK0qx8FzLvYhAxFMZ9sleQEXt48syuxlju+mPg NRIJGTU4rwSef2T81EA6irvYOfsmhl5/PEbvFDx9KWAOQ58YmxDKln5ElfnpyAGPF2S3fXs4 J+cL3Vc/UNtA/t72ERqAURb3v6R217uBWDCFAbYPFAZD7EWwA3QeGJeSCJ3MIWmQWjTLqGa9 Gg1RfQdETNLbZgbBZBKg/CHXM0biN/Vz/bBtEzYIQ6O4xxBcwLxTdaHBpZIJlp2XTBCQ26N9 l/suJCqa0ZkvIYaUY/yWnJgQ2A/qDMHG4pHdfhr4JZQxQC3vIYQDOE2PLvJLgboFfgOvMyHE fu5L0nq+cmifh3YMiYOGNpbi+UBeyc/qNBu1Gb8upB1qYA1NhJ76XYw941cWsJA7BG5zqR2Q fI3RmLPpVa5bRqmc1NRGcWo9m3oIWMO9KJQH2LRFxgAMoNQNIUWojGWzEudSOPy5IgKMwsQD UJUolqKO9B9U9pQ8n4/Stp9CHRBOmsyN3kSJnKBB7aWIAYFcMRB293rEaIQokTsSN8tW5D+m 8kPhAkEOh3b3fIh4pDj2uu5kVo47mXlhiWLnUfuSIYPCXKuzptdWOl9aLGJ1DM4CbWNoIzZK yLiSQlsSWM1O0cTl/oz3fUxyuGCJ0GZUMVSkokHVrP8AD6QUgyFcscbicqNO5+/nZu02bcww I2iEFREoyakkUh0rSjm5R8LrKASeT4spprBYXIwpwyIK0colfoKSBYk9W5IneI5CCZtveIZE I1EKR11Qog9I1cWfc96UVRIw0HWGQAIfB670hg8UIrHYabTdp6iBY7q4o8P08eMeV6YP0UN2 1kmh84GdxiUWfE7oce5LZNpibgpU2uXxZVTbsFyc625LRRdwsTgLBSH1TaHgEOuuhoKfPJgE L2llbF8Qxuim7IHgWhJbK/pyLtgsL+IQT/jty1qSwsnBTUooYW6JZ1EqQBGKnIV6oteo1TQR lNwUcXDuSe7Ik68l9ybWEzDkzphVXGXyFhkZVgl6dMUE4nqZOJkghZVVOIkrq/PINNQO5N2I KJzy5AoDAY+HC9NOR85FWrtdf451HjMiHdgPoWecmlkq6mPT7uuh6yPYKpepdMq1Wbs/rUIC rNUCV0/R2JMvFS+xuOl3z75jCaxSVNaRKs3Q7bp9vR3jT5ITRswbdif4ScOO6gCXs4b9DQU2 AXUfrkD9UJlQikocsBkpS1XB0jXnpm0woMboEESpkxrOffyQQ45DmJL4ai/FmZscEAnu8ekQ vWQsNafzeUfZxKJFUSlVkvzZwIvRPd7PHg6CyRAPbO4Xx5cROUkorPiGoGnffdgGbYl9t1ne RslymzfRJDJfoFyI3pCSpZyvpyQgPSnZQJojydwkF+gG1p6jm/AXYrlOhCkEsgQk/1CizKW8 t4pf7yeMvxovuwnq5LDO0HRk4tBkOkODu5ATuNgakSnccZuQTCo4QbKF+YXWfIYNNHSR+d7/ Ir4hAfyLigIl4hn7FVKesV9mKEAeh3qXvlOwhu7QMJ9TbyAdLX599q6tuE0H4QNjQYuSykfc KmZB3JKS48tu1x6GrkGyMkWuxp/hHCFA30YUfCP4FwrM+ddDPsakX4p4JKeFPKLj7OOhH/MH NdLN79Jfopscowynb7XU9K0OMcTZt1rlLQdM8WfCR0VczdHGT10seTpNKP34jm4Nrn48I4Ga g7rbjTHgee4u6UsTlsPnYktQ0JKJKRr/5ARDE7+ej2ISq8mz0E33sTvE+wPnqx1BV7/bxYqG xDKddtx3DREdiaw+Y7GH1V20j7b00cDDNn16NI0XmSgptP/Fd1u56jT1eIwfVSHUAMtEKrBz BGjriBzUh8wv/lLL54mFK0f6mBYKLA0snromxsRsbhJnyUY5flpLsUJKuzB899Ems1Llva8x culeAc61INK0/RSFNSyj7SYagDOi2rs6sQFLI62XIL5Ex6cjlj5FIbrkdDkersfxOLTxkh+3 mN+taawIVEjHNpVNSfnUDIlzSijKBDZUylkaCr0spS0KjShfXKKcSoBZofOlSrggOgQnCv86 gUP92geHSHwEFfPM5rilS7Jd6nrRYlIveC7fCGGC+GKzfVmSVbrQv8SwCFZQxrgcrI8hrJQv PnQ/cog+FfkTPX/BVg+xJBlO45ZN8LVijMYY17zypU6Zbtn893LlnHoxPsp72zzOXdxYyvlA sQo4hrwMqaYS2FUH1J4+O/37/eqfd/7f/wAQk1kxZW5kc3RyZWFtCmVuZG9iago3IDAgb2Jq CjMzNjQKZW5kb2JqCjM4IDAgb2JqCjw8L0xlbmd0aCAzOSAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nNVcS5PcxpG+81fMzVKsBq73I7h7INf2hsOrCK/NCNsRuoDdGA6W 090jdLco/h/f9y9uJqoqCwUUuntGOuyGDlSA6KqsrHx8+WWCP96xht8x/C/+udm9+fHNj3d8 fJb+2Ozu3n9489u/SHPHeeO15ncfHt6EH/A7LmVjjb0z2jZCqrsPuzffiIZ/++G/30jWGCEM vPZh++abv3abodt8xb/47V+4v/ONN8IoXOs+vXnPXSOdHd9/h29y1jjP4wrHvIJUjWAyLd3v 8ZlrGPNexWc/4SPVWMaFj4/aoW/HNwVvnHbx6Qmf2EZyodM+j+3T0/ieBGmkiI8/4iPdOOaE jI+68FunhbTx0bb7n323jTJKL9I2x/NmPJBstE8CPQaxvc4rnh7bUxTRGJ8O+HAYxh/rRiqV Xm3DrxXzMj3aHMbzcdUYpUtFeMtlUmQ3HNtTH96VtrHe8eUZ0++7U1Zueu0LPjKNZ4qW7MLO oAxOD5+Hfn+Pj++lECg6XDBakAjC9s9P3THYgxBTexAgE7dJo+/iK+4OdrTSaXzFNsp7MDfZ GOa8G1/8Z3hRFWuBQTEwgrv76Zsi2pY0PMn6UBMkqC2Z1Lu348/AeKw114SDqy+EYzXhBGp6 Ltynmos43JRMsd1va+Jy+H9hknW9r4kG9+iM9bfoTcBf17WmxQu09j6aj9YmPXobTFJxbeQ1 YR1Y7Q16tOBU17VYSvZdsGLHGImxP0T/kZ6u+HB67Eb3EwbWZxRNPkWT943hdLQYTazlylXC idM83eHzMpwcjsfuOHqEgKhglaeg0EXnslyn35/O4D41ZYCzcdRtcDbDpxd1SR3vfv/XuJye XgKcz3oI8Pd8tGqdAx+86e5gDcfBMOFNSAQOX2NaMjm+9nmMMPGx1FlDS0kk43BzoCFvfEgA P3wT3gQDmLwJbxidYtPuWL1mUJQhN/jh25qNFstU7LGrqQLCqpFSl6r4XFMFpCfp0bFZ471n Qk6PvpCEY0oQsKaIR68ItKkLJLmSrhToVDMKSDvcwS7TF1cCDdwEBZqceIQkUUIShUAgBE9O 8jV4uXZMpLh96nddNboLUKPVU4eZC4FJ0ugUZJpoBwX+uOeGNQz2v4dsgRhhjFCNWAKPPwfR HJM6PeqGh25ziulPqyTxHxIU0AQtDsOXmI61JMjQDtvoz97JZGeX8A1gEHT0At/8OUQf5bXh C7HA/7lgNt/CKAX82nFCOFEKeKikTVKUGMnmKDaNQt6Za6AGFlWGzlaAGvg17bYGanwDp1qC GrgfK5agxgPKmoIaD2BDkg2+BtQgLOKVM1YwTRInYxpG0CdEeAioIBGXCb1wAjfrEEbphkuK 1SsoQUOSGFECB7dZT8WI0GTMb/SmCIoC+6OM9OtDGF0ItwZhuJkLtxJZtJY3QBgj2K0Q5qre nI7o6hfq7dcBMdc0aSFC36LJKoxREPEWMIZ5XoMxwumbYIwymmBMKLJG0yFfX8Uw0Q8VR99O Hnp4iCtMUFSENqOLWajUpgXCKsIREArsHIO+Dto4wUxIn4qpW6CNiPjyArQpN4H8zgz8CPI7 Sz9+u6ltgoGQr4GGeYK0YUkP1c3/B7SUtLuKlhCc3IiWDPjG9OivQktJoKtoKb1Y1R3EcMBF lLxO0cAh+RC9sIaCwM45v4iCTANon4qAnMAFSMeuJXA8tydWov0YPEkAaFOOENqhIm/l2VPX DoE4USAS4Y8JDEwrfg1xAxAtSdPvIdHvKDXfCw8pw5miOmk/xqWspXx8OJ8ivGHK8jJcgMkq R/n92AYVC0CpFGwoeMBTWJWCBYEO7ay8dkcSEcLsjsroDo4oVOAhuI3ondXWgsuUqUilN/81 6pq5S3ZQQcNQnU/C/Ydw4VJrWugQ3jJKknXuDgmrITeRgN1oUhx+7FSGa/0xpgSr6Won+MhN DQ3ux2tCil/6YKTwW56Zqu02rQdVXmk+YFEZErYbQnBgVozcI97avZQcc2ORJb4HtzgMXyOY N+DiSZTHfrPMbBGeKtg1PfrUj3CSQwJm2YmO8RkUPkkFMYFiHU68XnRKpAysI9tNmc55Qubv nvoNGSQnzB/tEfZWtM/7w8ffJBqACzL+zXkYQrKGkgcwP58aDcgkKUSPVUAqJJzS6VCfK7D5 6zF5lKUznZJMPNc8a94OFy0dqWOCCNIBI3AQGO/FVGS4TqgTQJJpKKC3QcQl/2GQyntVWTC6 jZKgT5L1Q7RzcHOhKKBG22eNFrYigKEzdD+eg+GMBS15QPtEVCikDju7I3BpvzASQyctjVl7 CraP7WZx2s/9/lPcH4yhRoaThRyiUo1ztP2+i/HVkuHVRJoiND3yQNn3HmGRY6ij4TdST4lf qI3ap2DGCqtJUvvmsHs+n+Be0l9pogx2/fZLvBGI76TRcKvGCzmjGwDG0rKnx+Fw/vQYVec8 uXfkyafFx6tsBxlst7AdNGuy9ePj4fy0TfoQ5OT7QzR45PVciXK7fUrOEPO8oaCegw3Pdpju kWty1i34+tfncAmA7LVJB3puj9RK4KSNHaBzwPzHeCSew/6FeBk0LemUyRtGkJQMNMURCGS+ YotUWnTDpns+BToBHNJylySONSEIIDOfcDwdhm5b54CEVyCZnXFAMipzwgG9O4MZ7+OOmmVh +g0hkwVrY1UIQkVXah/hA1h7Rjj9qW+fYrgVhtzpde0Ykek3qrngkb/lmiASixlNJ7HxkvRw TlEcIBHhmuF8jNchAV47Igaezx+fwl7g+hIOfCmLRMPUuW8THASChsgtvNPQ7o+7/hT301hA vZammbWeonPFZAIF5iQQRZJGacj7ahnoFVXDp6H/Ca7yKURgyL7WKboLyKrnoYt/Yyn9Zqsd y/c5Wh/53et0m3BYmiQpuvZEfJszGWwkUGI13VIMb05xQnrH56B5KzMF1W2SiUK2Y0S/btpj N/qWMBDdKbn+IchprCULy0BF0hUfzx9Tf08jDCwZsiNkyIhXkH4tcj9k0oysX+gnx5HxUArR 1bIjOUenAGGoDJreinGEgkd9j48V3CtlsahZAEFZs2MwivEF8BY1c9p+CDFkxlRASGeMGM/w yiWi6fltLRQBXhWGOFLwy7hXyWYYbC9BLARs6MBfCI7NhVLYJoOrnr64wthZZiq9AKMZyZIc rHo03kgjCrKosoXKWCPYN+BChY9LMihEqSYaile+gI05wEvRMO1zE2JTxNaMyMjmtCLsVOWz Ahg2jfUUcqYRH+7GkIGth0ZMdLR393PizR2nivWx3X/q0pJWvZ64B6RTnUbwXl+dRoBwrQX1 /qfEvatWY8qW1dhqbwizlRauUOApLARVgDWcYEh/fIzAFi6MTYRJ9avIzARgyd0oIBillznL 4a2HSA0qsjpXp6fHqEoo9fSNNjxp8lRtGOGKm6VsgNqKkP7Qbbo+QjQMPLMyERCLIRGP/aeq c6OK0SWC0/p1aUrvDi8mcrDC6hG/+31tW48VFwaV0De8Ydvpi4FMHMs8V85+PAyHXbwILSkj D13IXMj5mOyB+2031OQXYz2YlDnUpbImG2JkykFOymr9KRgnQkoiSpag9UxRgOD1+jiQVZNU nrFyZl0w6UZkznLGS85WYQr1lWNCqSgyU/NvtVUQ59AJqzcIGZxzcbnpKhCLIkVdAG61BNx/ TG7AfC76u09D0DfEaKJp6h1Ti8Belh3TCSgp2ZPFWREg6aSOv9cNmymIktOJkVCiATR2kmGv Fgm1QP3GDhnooGTrR0PH+ICtfnzxn/UUN7ZnQSSDUIBuCDlWChE/hNQBOEmajH+/9ttqMBiN U4A0Squp9PAOYq//RJF/U6Eg1SgpXJgxsb9UhRsll17NaeuCcbeU65v3ozilAkG/Ro4RY6HA OUIyWGtBrrHsdrH33c/j3r//cPdfb/hdDyAUdCOxqw4JFgCCAhMAIYfuzcPqzOOsUxJeuRNO N9jdhsWQURlnHrePK2GbgZWkloPIKlkGY81ZjJ9qesqXNzau7JIbGzfr8tJo0DjVN1lurX9m vf8lLTQbDPclLbSxHJssut5CE0WW/MUttJD3sNGZ2alZ4auaXE9nulXKa20jqLRUI1TZPqme D/KQkTNmBeyV+yvsTIrRmJo5Aa2I4ZRSGc8PqcvMicD7qd+GA2Ju1sQ1xlwpdJ4OSgsKQ4++ fxdzrGTEs/17zR7CiI4rUcmuZg8AIK2KM2nXbG45kSbGebSyv3qhMbqaaJhysUE0sccx04A1 yzHTQJnkb8o15czmAoNBLTXmGmV8Evzb76I1QlbLhGS8OmMNEQnrkwDzY2NPji+QY5mDQXxB nUaTZkcdf9HEbXxlPjcjEbxPNbqSN7Tjaf4jvfmCsQ0D/1/bZV5Na8egii52qUYJbIlZuazr 0IFIK7UJbELRQs9GqNtnIo8tnEnOiHwxzhYu/NU4wh3b8yYVW+DviqBHnMOyxhH3UZuof+pT XAFxaaM1MoTj5b6ADPlHzaEc9ptsOZkUHAqKVK7wvhOyuOhPmK8QerjLJkQeldHbDQnzBaFM CKbN/7VQtqJ5xgDXrWh+nFC7SfMJNc80vxrLsubTdMp8WmMi+YrnTQ35YaVqMI0VVCKtaQBS 4ooGRjR5qwZ0TQPlsaBodgKJtqkGTO147GLhJ+D/ieRZzVE45rI8VshR+le/WYFM8/RcTUJM nIZ0/5iaxKbBz2umca/os0kCL+sluQZoZSj3nQijQEmRK3X68kZ6KrdT/Q7aMi7Tfy8ETg6C g6OoeaiGPqysjbtyT9w5F6rWVDG9ompNke9i1YpDPMn/NH4gVOYsiXT/9S+jpnrftdvAehhs V6eDdj8/P/Wb/hRaLgqMNTdZr3WrIHFm0q9N5oIpSpX4+MIkujUXZ7DwVJyy5b+ErOghCqZt ebjf6dD89pw66+BMy9atMRfJobpxpV7eZHYHae3cdcy5P7TtiPXWmHX1YjJFUjG/mqsKymh9 dKQSR0nGXc2MHdggNqSLnHd9MPDWci4h6RUGy4L3IIxCBsvFmeBGj/ZUfjbw1J6PfURXGlk9 Ake/6/Z9+7F/Cv4Of2cwel6is7gymDoCnRVbLn+LFRAnE+6SLc0+J6yVpdiSzcI+T4VVDJ0o r5CErYqmcEiMTvZT30ZjcJb6TYGyA5hryOMr7bY4ceYmiRZJ+E+Hoe+Ob2tHUB7WpJ7Ily7a XP42pP0crd4q/4LjzH0JnS4PPF8bC6PI1Of8YxUv8s+ujeuipU4vHkxhUtCuz2ZaN/HXWh1d 8bZ0Filczk4xZ4HWGHWEK9seTo9rkCcHgnd16JQT19rM/mjTs5n9GUHCcBgqCfjYxqueNIlq J4668pM51jhtB4WNocJ1321wqCWMTeGIVx5EujSqwLJR7cBQh9jQk3AamZvVaRwWkNi1Qipk N0CCk4ngtXYYmBXO9onCrOqDiDTG4WiJOMSTxJ0M6W1rjsaRuJkM1AzxTMzk75xCEQhXCdgn jxZd8zVwl8Wsis3zShdnVaafPQdfAz0xRXe36mQOSVdi1i58li3VK50MlG3zd2zVT7LLyZJ7 yP/gKCXsmH5xwcTka852X0UjEqxEz6iPhRvlsLz+BY3U8y9oZstgX56GONohQVyTaYgpswCY US1HBHPcuEYsgKtZIUql11gElDybaRpUi2kcFDNNqKCpBsd27uFP52VK4/EfHsBLJWD/t2ha LvtPFzILhs08yVtmdYVsDaHOlayOsxBOFE2q352HfG4taFBi257aaEXa0LrrgwDfJUQiJ5/R pYtiitwuS4xjoIY6YzEdQWrPHHSKZQwAPcHpwEuPu6H+86xRWAAy5y0MEGhAaD67u3FROxkE H3BmdkhfzM14dgCgFI4+r3WYcDLUcl72wd/V/AC7XTjdMn2xDkPKbteFnbk3qtz5fX1np+cd +OrO99LgtxBF0CjbVlqqOy5BkNtbVrPQfxf/mQ6NI/4GFxtnNqYtq0WjGNw9WUGFLj29jQUK z2zJn+o4X49VUYHzu5ongcacoq+T/RWwAWGKYmm9FFh8LwFS4fes04hQIu8INZGOIz/clgFh xFjzD12MJ1coPtBRVwd1bIP/7kBlUAd5WEJTceKPozEvOQmVvwOCIPwcY5rIM47dkD5J8lzP kKpTQkxyUgKSTooKkEwBawVIhk9kXYmS1z4stTVSffGtKGiroNQv/JsXGbOvfoHJwVRv2ZXp ctfL/0oDnFk4P7sWbLzRtTycI2IFIQTVJccujZOAX9GHEimzZmKlRLYQeTlNaIbavmipnXcx l0xIgpr1DSGnQiYSnqYk/iNiT91ApUxukeCQ8+WXDLdWg17mmZN2OPUh9IOJS0EMWRrKuuca T2jhAiDUmkBoC4qF+N//AlRJeq1lbmRzdHJlYW0KZW5kb2JqCjM5IDAgb2JqCjQ3NTgKZW5k b2JqCjU3IDAgb2JqCjw8L0xlbmd0aCA1OCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nL1WTY/jNgy9+1f41lmg0UiiPo9dtLf20GmAnj2ON3Hh2Blb2UX+VPsXS+vL8cYz vRU5BKAoiuR7fPRbSQkr6fyL//W5eCveSuZt6a8+l5/3xfMLs6UlVnElyv2XIlxgJQMgWulS SU044NG5eHKn5tP+r4JpIqjl6LY/FE99UzfTVI23+UgIAtKydDSbJOGSch1N17OPAERCjvAa 3Aw1HKKpGacfvaMhas4iWFvnbZRwptIbddX3g7cDJ8ZS9kHQ2WQIpRJSxMs4+JCCsJziV18I sZpBCtb0KWvJVbS5U+Wf5YwYYMnatNik0dsNEVYn+9A3sR7JZLR9my2KWCqoiaZq8l6cCKOX hza63jXH1rXnyvmzHVBsijTljjFiJQ+xru40jGQ+f36R4h5kLvFVzsr9r8UTJ4jQpx8KmEvW KZE/3Dj0R99WTZiw0fxz07fVa9sFJISdj1I5t/DSmk47hv3hWMsOSwejveefs6clgoG6h0aj g4CUwaH5J/Ts+QVxuE8eA1mZbk7OdxvrpgqWbh9jt4W5C5hy38xUaKI542sgEFv5AIQi2pjs mLvBOQGVeXkLZONgeErADSkmVclWd1XrR4IrwnLQO25xRtP7kedIBID8ztB3t+gqTHath2t3 CFVyvmqefybB+dNWI3C+BOTy+s0w2FlraQrzeRN5AImJihUnT1WaYJ5HZmve4qRaVIlU0dgg 2X0yGJdTkca1Cr4KBKRBP7Zf4xhpukx/mmHF893zrFzHxkuNwAaKnNTr1aV5Nfml/jH522Py y6grKr/HA/tvtExF/T/tiBE1XTSu6lp/l1miLLPrdpAoKRK1V6/g25/aKVJdg0ocQRG9eOss zCJZm9FFulsmYT0V0iwb4VxFrKxh37vZharv6TlOrYSs5+fhcb0cmq5JvadUrOPd76acnF1G NmsvEybB8R8jr5jK94cvsQcA1q5pBLg2bBasq5vag38LdRjEAtQx8tbOcVPybmsmcU8zyJ3+ bXO0BaGLHn07DVE5KF8W9CVnrGVmdGCE37AqMAKrfg+WNqgv0kFpluJ+NJOIvcjSVQVUraRZ hO4IbB8JTKlOVjdW/VSP7SWsJySwymcRCorClW0bb9WhWOyUEnL9/mokx6lybfDFDQkia/cH fEbhyQUsXx7K5PV6uNZN5BWqBLyf5aH9uxlD9xAUajORXPimMBLEitYh+8SfJo0mbub09uTa rgs4cyyIroW7Hm8XNxzH6nJq66oLO0fj/odMp49RAmEfUfJKo3Al4XfHTigcCfw4ml1gPvhl X/5ezL9/Aezkh2xlbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjk3OAplbmRvYmoKNSAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMzIg MCBSCi9Gb250IDMzIDAgUgo+PgovQ29udGVudHMgNiAwIFIKPj4KZW5kb2JqCjM3IDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQg MyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNTUgMCBSCj4+ Ci9Db250ZW50cyAzOCAwIFIKPj4KZW5kb2JqCjU2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRp YUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNTkgMCBSCj4+Ci9Db250ZW50cyA1NyAwIFIK Pj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNSAwIFIKMzcgMCBS CjU2IDAgUgpdIC9Db3VudCAzCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cg L1BhZ2VzIDMgMCBSCj4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlL05hbWUv UjQvVFIvSWRlbnRpdHkvT1BNIDEvU00gMC4wMj4+CmVuZG9iagozMiAwIG9iago8PC9SNAo0 IDAgUj4+CmVuZG9iagozMyAwIG9iago8PC9SMzEKMzEgMCBSL1IyOAoyOCAwIFIvUjI1CjI1 IDAgUi9SMjIKMjIgMCBSL1IxOQoxOSAwIFIvUjE2CjE2IDAgUi9SMTMKMTMgMCBSL1IxMAox MCAwIFI+PgplbmRvYmoKNTUgMCBvYmoKPDwvUjMxCjMxIDAgUi9SMjgKMjggMCBSL1IyMgoy MiAwIFIvUjE5CjE5IDAgUi9SNTQKNTQgMCBSL1I1MQo1MSAwIFIvUjQ4CjQ4IDAgUi9SNDUK NDUgMCBSL1I0Mgo0MiAwIFIvUjM2CjM2IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9SMzEK MzEgMCBSL1IyMgoyMiAwIFIvUjE5CjE5IDAgUi9SNTQKNTQgMCBSPj4KZW5kb2JqCjEyIDAg b2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvWU5OTkZXK0NNUjEyL0ZvbnRC Qm94WzE4IC0yMDQgODUyIDcxNF0vRmxhZ3MgNAovQXNjZW50IDcxNAovQ2FwSGVpZ2h0IDcx NAovRGVzY2VudCAtMjA0Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMjcKL01pc3NpbmdXaWR0 aCAzMjYKL0NoYXJTZXQoL2NvbW1hL3plcm8vb25lL3R3by90aHJlZS9zaXgvQS9CL0YvSi9N L2EvYi9kL2UvaS9uL28vci9zL3Uvdy95KQovRm9udEZpbGUzIDExIDAgUj4+CmVuZG9iagox MSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYw IDAgUj4+c3RyZWFtCnicdVZ5VFNnFn8hkPfcW/VVaJ33cMaORa1WtKJtp1awLgjUorSKyqZh E5KwB5RCQLLdBMK+JgHCEsCCgAvWXQdXqlardNxq1Vq1Wm2P0+/RjzmdL0idc+bMnJN/vpx7 f9/v3vv7fveJKGcnSiQSjVkXEBCw9NMZPv6Bczwdf7gLr4mEyU7Cn8RmHDZwfyDEpX3yqMfj UdrLaPk4NPslSiwSLV0Z7CNXpCfGREUnu7/h4+E+Z+FCL/fF8dLEmE3hMnf/8ORoaXx4MjnE ua+Wb4qRJqfPcl8cF+ce6MhIcg+UJkkTU6Wbhy71kccrUpKlie7+8s3SRBlFUZMWp8v8vR2n pUkxKb5p4RHzZ741x3MuRf2ZCqY+omZRf6FWUR9SS6nV1DRqDeVLfULNoNZS3pQPNYkaQ71M jacmUBMpV1IhRVMg4kS1TgudOsWTxCXiZ87rnU+4KFx6JR4SFf0OfZTxYg6McB6RN+KrkT4j r/wuWhqhGPu7003nW2BHYXZhiVUkTBrwYzXlusJMyASdVr0VSwcfumZGyBNW6hkZfcpohB3Q DPuhUcfY6XBDYi05FYLRVLEPubkik+QYnmPKAh1o3eLXQiIno+uNV0lIM1yCekeKL6RD5i4G W4Q6FjH4Oxe8TUI4OJ8Iw2FWc7+QbRcZrogFD3SbbTr3hcECJEemy4QtkExQVxsJiZ26kmSC kqNTa1SvY5MrFqOGvErCwuDW2A5Wzk4n6IJBDlKSEOhI6IVidUUc8hh0cg2dAjpNbka8QhoC TJzSDDy0F7TblBXpGakqmXRn5JHjuw6caeQJJX5gFdiFyVZRfx/a1CcWPkYaFu5Dc3KbrGtD YQxMB+mC3DRG/4sET852kdHni7cH89hGh2SDL6m70XiUVG2Ho89btTILengUQD+7cPz06cq1 ARzO+j+R6yAR9C3M2N/FqvkfgH3AxS56aBNqLotRxsBMdrtFTzrB4Nkyq+RSviqSHzTQCtgw cwjnyFCnjzzHmQlfNPHCHgON8v41siA7P7cU3ErIpAqrkGZgrKth8IokUqvy4dJkknrjNXK/ Ha4NzSiN9tGW7uSFZnpnfuklzmrHsyUpoNfnKrFs8EtX0prdUneimAtWtJtw60ff3RPvGVjE yqz0c0bN9DCwMFqC2O9v/3jd+xoeVcE/NF84C1eY7+bdxJM4vBRfZJGR3mEs2suh8ZInHW8H rfh0ARbzb+C7bKiuaAeP7Ogj+seDXu+/E7DYg4xE9KBYoaoTPK0i6Ect/WIhFMWyiPX4BTN4 9MwpeDye+GQGkqCRjx6j8RyOxSFsJIRUyw4oevQnYDd0wqnWnuY9e6vboQt2pzdtbt0IfhAJ 0eCfsEG+fqNSCszzwauswmwriul2XGQ+I0ZHHOUNTziBTrWHtQeQGTDTPPBEPOGhB3Lq33vQ UskvpdGUUhc7vSy36AAv/JP2HbzMEqVqM1OSoiNk64BJwFQp+uRSeXfdDt7a2t16EE5De0jp 1vIMotV0crmo+80jqjqksCCfoSpzT4uFCWgbW2cEy9OgB3gMlsydil/Crj9PR2I0qgdRtYXq grxcnVqt4xO8lieHAxP+12a0mLfQBgtbjObcMTfDr1CIpxhiHPjbTt4aVvWZX6+K0bsok33U fe+bYiPoC7hczdY8UDCy+uxqq7WiqUXRHDZfNluZx+mRWIJf/R8qbzYegxZogovDyvHWlXXw YwcmEHkcJL9W0cPraE2dWDg/8Dd2sOmFZhv/UIjEZrxLANrhDtgJQDw9T1fewSPjHfpBaawX X4eqUyReqtg3ubmoVPJcKi9L0FSwf1KJpzB1xDpEOQtMZFzzzSLoQek9YnRdeJc1g0mVq0zJ 2c7FNcQVbiGzGhO1Yk02RHdG823yz7fvyzmWXaFtSDNvq0gBOROWuH7uivWdT1I4jRkMeoOu QANaYLJBnc7jyXQ6qEtNBkNtDWcqAmNVdeeGo1ADzLPDvVePxrbllPBRrYrCFeXxhd6VcJJp rd33PRIVzoozcobcIsgHpgxMZod8xw2Gkd4z3WjCI9J+MfIWBtnG1Hp5QkqqIt6mtLWaG+s4 zOEAorWzJXmkzw3/6fN+8j7LoBc+H3JRjamLF5zpF2p9rXvYptDfBe8XUl1Gzw9Z8sFC9RdH OPQtjac4BtgPWk8eT6fBH6JaYm0Ju7IOkWLa4HO7vb66E4CZQyP+hYiRQI8VINV66hchyy6C n9CMq2LhJeFXtqvAdI44baLOB2QQC/NAQZy2lb6bnxXFD4bSnhtWBaWuKu6N51rULWboYGxb G2KSEzIjl/T53/72/knkxBHux6fXqmqF1wjwgKdY+BndZevO7DXWGBgHcDrEEWgdBDksvEdX rgAl6GG7RjUbV7lOQx3qcjBCvlvzTqglROS6CBK95Y8d0QkVurLPTHnlsUVp87HWdQZqUFeQ +AK3pi6wDBFfBwqyJHTg54g/BKWasi1oPP7NlVjl9jIoAVO+qfoJ6nR9gjtNW03aEnArg/yi gjJm2IisKMPScOMkeaYXUURfPxH5K8jKEhfvDu2KbgupDAVmoV+Qr8ySWW+rqbHtioJtfP3u /eZuYPadkM7hN9F4o3aRF7zPvPdD4qkve7r3W7iCDa1Re4Cp7a28xh9PWU0HJuVmSuFIFed7 gPXwjg0LjujYj1zR++UdRu6/nKr/DDL3kwc94Mti/sVLHXxYRxcUNx8sKKqP3CM9Cwyinz5C LJrw5mMsXrMhMTyGNwaxYAZjWbWtY6/9ADAtz7LwmuWq8KQoPi1uU9w6CILo9oymz2qhAGqG i09tEqZaf7ixyyaCG0hzQ4zGoacsKkTjuo92dGTHW7gsKUSkVCkbG2qq7Ielh+YRb3bFLFbg ZjTa/xYS3X+IXkFus+5O84x9X67i0Th8nvWD+OM5tTmNqgPwFXO146fvj9kjY6q46khYB2Gw FkKU0sT1URmbHCbteEs4qBZ98Eh0xypGn2rY06ldm2XKlASFJaWlqqzIVMjl5xvAAIwRMtUr Ez4K3chrtHodaBi1SW0q6b+MaG64GOvAq0NmW0xWyhr0NQs31dej+iNu+tQFw8ewRBa5QO6n 8gdMwfQi744lXYsuJB2G23DwsL2344rxMfQyOAxfZreAr1mJRNknoR++ghtwufpEzblDrXvI 3ulNtrxdEQjvwTJYDouyA5TYyU8ZDcPdJKbQbd9rFaGJF8Ro1wDL1oMhjUtSrIucCkSb9XAQ jjUyg2Y6Sps1l4uTSZqMj8hn2A74EZqIG8TRc7XENIexLqLfHiDyzQAPUOxNseCH3mNTJNqM 3DWqrdtzAiGeeKG/pKn+1NlGG5qJ3I8fhp+IKN76huxQZtkbb6/dC/m1jVVtzUqLPEcHei1n OX90Xx8wtw4vmT0/eHHgSh6H4FSXJEFE/6GFu4/R6zY05t45m6jpHlp7X4z8EGYz9Bo95DAq E5i5fZJbnR/OwJOWRQevX1j/pYxvU9sdrmBPtcqTEjKlnne9Hevszr2nPyy+NKOGu91w/Gv4 B3N1Ye/0aYsDvDe15lbV2qpa2pIqU/KGSHWefwAmYHb0bfNQalfLwvj40BitQs+MTa0dWFSL G6uQvFSCw8to+8i+UdxIZy/r6BHWktGj+6pHj6GofwMxt9K7CmVuZHN0cmVhbQplbmRvYmoK NjAgMCBvYmoKMjcyMwplbmRvYmoKOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0hUV05RVCtDTVIxNy9Gb250QkJveFsxMSAtMTk1IDY4MiA2OTldL0ZsYWdzIDQK L0FzY2VudCA2OTkKL0NhcEhlaWdodCA2OTkKL0Rlc2NlbnQgLTE5NQovSXRhbGljQW5nbGUg MAovU3RlbVYgMTAyCi9NaXNzaW5nV2lkdGggMzAxCi9DaGFyU2V0KC9PL1AvUi9UL2UvaS9v L3Avci9zL3QpCi9Gb250RmlsZTMgOCAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9TdWJ0eXBl L1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDYxIDAgUj4+c3RyZWFtCnicbZN7 TBRXFMZnWJgZBRXRqW2Ks2NK1NbKI8UKan2EFq3EIoIhQUUQNoACuyyLZbXCIq77OIs85bUu sOLqCkUQtaAIbqvFBzH0D5E2ttpIa32lahp7dnNJ7UCatmma+9e9yTnfOb/vuzTl7UXRND1t XULiJ3EJi6I2bApbOvEgut+k3YFe7rmyWpLoWemJ9TkV6HMhAONn4ooZGOJPyWg6OiYpSqnS qrMyMjXiwqi3xbDIyKXimhyFOistNVfckKrJVOSkaqRLthivTMtSaLTB4prsbHHTREW+uEmR r1DvVqRPikYpc1QFGoVa3KBMV6hzKYryVaoUsRvV+Zs0WQkUtZGKo6KpUCqMiqcSqPeozdR6 agnlJ01PsVQO9RudSJ/2esNrn0yU3fae6632vveKXjzmP/0VfcOmK7W5w600DKFzSOaOwp08 zg5+RmhCBy8gs0nAw0VII/3wCQYIJJmk8Fsh7YSmW91rvAw9cK7skqO3+fPu9gHohdPq1sy2 rfAxZEO6KVa1RbktpVABnKTyx/ciSXTgEqs71EYPu7BhSIYq8gEfYyjvlmMs60w9p3IB9+z5 GAZiQPiToNiknWlK+S2W+Op88tjBGv0W+XgOqzAcjBHy2NayHnBIpxdaTdxadyUPDdDS3VVR 3nGyH7hbV0MJQ5iY4BUZ6Ucu5MiL7FAJ1okparerSm1Y0IgfTq57wCVzz8RivrwcyuAw92Lz T4SZt3Q+mUFee7zoJXr3vGyp0oPpgNlUbBAK1iZkJUIKpLSqerIHYBAucJZGvgqDvm0/A8Nw PsZCvCUNr+ER116bZ7mNhlG3clTmWYIPeUwlCzCYLCMrSRAJJdvJdpxPFuNyXIVvYShuFchN 8oCXhvZHBktQh4G/PH+Jr79L9hE9mUW8iJdc6qwJ14ED+1pw2EHfGcLrozJMwhEewxnkH917 /DhkjMyRk8E85ptaSJaPn2aTdRAt0XKWuaBNOi5wmjgHG62DXrkJW3l0sh1lFWeE51J915qI 0O3ryHRJh94hdoHDLVrp4QFkh2X4Dur4J2d/vl1VZTZWCVBwIC+/qaSxzl51on1Xc9aqnWsy S+RmpBnC/W0VafvHqvOSUU4YgOMT4lHFkrikkZHUUmp1RzTQ0Im6Thledy/jbWaL3mA2f1Ys GA37S4yGXR3Jlj3AEVlaXFzYi91OvfxGkd3Qoq0vthdABpeavzkkPPvmmFYwNoClFLhSs/lT OQlitRZzZYXFUl0hVNY0tlYebladyrsM3K+uL78bUB0vqpPntGVWpVYn1H3UANc4R8NXz3+v XLCrTLAcrDAfAq4GDh2ZwO3MV+21SsCvWfGqI0AC3jf61DZnVpE7EB/xj5vuDMEd7tG8H4ko EPv/ML80yfzSv5ijlZ11AacwV6Bd01B0Jh1UsBbWQdbJrNM7Bgx24EZq7x6phKr9pWa9QX5w fW5BNiSA/ob+mrHF1Giy6/tLbxHfTi6yRooKtjCT5t1i7j7NJf6En6de/Zd50ncWHBjZTN93 oWCT4SL3Qh5FBxFxg5YxBWWGvW/i9t4nHWwhEG/kBju+HhGuaOPZaNW21Ny05gfC9FeU55i/ lAHfLpz7gxQDGYa4x3m7tklTUKjVFNgKj9qbbEcFMoXE8Xns5er/OP4FHINWOAtHJ1bfaKrs lLsZViJqrVsNDg/npNFxU+bx8qzgx0eYPSTPx8bU47IGJwaDTYpKtbnJCMWg4ca72QyjLkJQ 5jF9ln7LRbgI/eY+M+dQshHGWqlrNwt2qLOVV1ucUiUuhsbcerKMszHT91o9q6zEXofKaoak 1LCOqS5fYaq3Vuk3xXrYz89V7zeNov4El6DJCwplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2Jq CjEzODMKZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv V1BIR1hMK0NNTUkxMC9Gb250QkJveFstMzIgLTIwNSAxMDQ0IDcxNl0vRmxhZ3MgNAovQXNj ZW50IDcxNgovQ2FwSGVpZ2h0IDcxNgovRGVzY2VudCAtMjA1Ci9JdGFsaWNBbmdsZSAwCi9T dGVtViAxNTYKL01pc3NpbmdXaWR0aCAzMzMKL0NoYXJTZXQoL2NvbW1hL2xlc3MvQS9CL0ov Sy9NL1gvWS9jL2UvbS9wL3IvdC9waGkpCi9Gb250RmlsZTMgMjAgMCBSPj4KZW5kb2JqCjIw IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjIg MCBSPj5zdHJlYW0KeJyNlmlwFGUax3syMDQRI+7WbGUkdGfNioB4AFKUGkswnGokgIRTk5BM 7mTCJJDJJJn76Omnu+e+QiYzkzuTAwgBLRYEFI0iiJFlD63VtbBWcNfd9Xw7drbYnkQsP2jV fugP/dbbz/s8/+f3/N+WYLNSMIlEkrYzb9PGXc89kJObu3n5I8mVTH6BhM9I4RdKq4Si7/sn C2cPZNyx41eo+m707F1o1XxslkSy4bm9L+Wo6prUFWXlDZmLc5ZkLn/ssdWZa2uU6oriotrM 3KKGcmVNUYP4Up25XVVcoWxoeihzbXV15rbkF/WZ25T1SvUhZcnMsTmqmrqDDUp1Zq6qRKmu rSuvwDDD/LXFu3Kf3l2nVDc882zNE9mE5LyExrB7sXXYY9hDWBb2OLYV24Btx3ZgD2DLsOex O7GF4oa7xbKwOViX5K4UsQhpZFb17EWzPTJC5p5zJ54xd+Fc5dyXU3fekuTuyEubNEECvZjg 10claCOaIy/eVNJaQOlpE4AGt7ps3t4EB33EEIxQg4C7Q9ARMDEWsoGt90I3BN0Bb9gTZOAK wnHklLGHwkIGGPGanVRjqxEaDUFgx05yMEZ0w0WqWwwQhGjACLpc8PRT5POTsx1RcGpB0Qx2 i9WIC5qpzXK0G300KHw0O+2W5Oj5NYY4Gr5+PC6Ba6j2hpTP5OfLm6EVWlubWxxasOD1EUNH f2/X8dP7jq4TFggKIUv47fI3sr9GWR9/G3RbPVabw2G2EtmLBQnoAX+u7vT4WPSfw2+TiQuv nXwNhuGYLlyHp92SZmv+BolJSULCN/EPy1ejvZTX4QRGAe72jhNOP+NnoB0P6oHaX0hBEaGG XE4NuFUvVumH0LjbeNBHolRhUCgTGq02mrbaFHvy9zXvonQzYtJgDA0McZAgjsIodWRGC7+R cZAmppqFPjjcdjgY+hJh6QNDo2Oxrv8I5nSngaHBAWaNtsRuoE00aHF9AJx9E8medMNbSUk9 QegIGsFMbmIcnPZ4yY1N6JGG8SsT36A7Bvv6u451jXMhxgfQgTPg19VUUlBNlIKSKxOT10Gj xUV5aNJHJxygglaDzmxKinExa82MGN+v4L+S+46w/j8C3umbbp6WFNJlB4AGvWZKMvVu+pP8 RarTAQdAISyUaQyg0Yv7QhGaDpKHHW4KDGCnKUov/HrKnW4s1lY9TuE2Hd1kclPewREOhshh OEINAe4KieENYCG3MYYodIKHcXEBlMGfSGdkn/wXY/WMiJMiAO6Ay8MvnrxTXBaypiaMJQ5z Nii0yYODwPVdEbUhx+AkNTbNazRgAk2pCiJOYF0RMu1WyncGTGT+chyNir2+eEOKHv2LfCYI rk0y64MIiSZlaAVKRalfXN36xtIA+XXHN9fgc/za5neEeYTwqUwzs7GD7QBHOxlx+GjQzZSJ twus/G3E+EZY7iQokFx2PZZXsHLVMiGNFLYL1+WtYkOtjJGhGPACl0zqPTSYjrbK/tGxtnDx iqVCajLJddwjP9B4k78sD4cHBoaGr7gUgWQnI7jX5jQfqKWgjqiEcq5qupMag592efodh7QN B+w2UmgRokIKOmMNAytS3HUa/GG/qIYIsGo9BaofAdb9ALDTpBYBvkv4K0NxBqAUQBULq2xN uhdo6gka15hnpnkaPbIPrlJ90+hNy+vQAKslD7FWFoLg8Y24Yu2Xuba2cVcHw3l9Ik8SlIkJ +Qm0LM4/GJfw+VelrwhpcnOFw1IAuF7snNll9/b2J0MPwXDSaaZhMELrbjFe8ARa7ekmQ7V9 5a8CjnB0N1qE7r+57fJTu/eWlVSSxvOFsVJ4ETQlpqamCt0WoHCjH1g/w8TdRPv70d+Lw9Ye NisbKINdS75jkHt6e/sibSOJfk874Me7yvPyKoU5TUqyYv3eylLAN+s+crPAckGxEZKJGCZa UF0cPSF60FXUPiRFW1CzvB+usWdiEwOuNyGMv6wc2yBIhQeWCjn3vZn9xS9Yz5OmjweDTKLt LdIdl4+iZV+19QB+qre2Ikt4FPYnz3p9caEhht76NBSXoHdvSK+/KadarA1gw5vCprZgxBv1 EKxzGGU4I96hyIS71xnqO9UV93r6e05CD7TpGaixHayHA3hzQCOW2HlkpGpg1zMFe1QawvxK 2eC+/0OjQ5RBtzOZS0VGnSHOKxIoJyoZuyhF+/nfyW/Kov7ptjSRK2VH0L2uKLjxdr1fS6no chNRIqyc/aCs0SgOohei5HVZjnDUroUmfMcx5fkvL6BFXr8Z7CaaMtiIwqz8+grADxlDQ12s x9meZH6pef7B+OsohdcmJCxKkfLH+O/k3iHW9xrghwPQ4bNyZvXzFKjJSnicqwTclDRfL/R0 +sHRTXZRHkq8GawOi8MszJkqSK9fujF/p+hL+f7msxztEecAH+0ZHhis82ub9ug35p7b98Fn X1/+V7d4tnRr7m33d/OL5TRnT84mEwkHvCgHLUi/+d6oc4DzJi+BCO6kPOaDagrqiTIoSfqo RX/bR+MOn03MoammwWqbukc4l/4hupZ0zz+Aolt0RZ+ZtapyxOkja2EdVyt+qftFu7xnajj9 ti3d9rb3kxMSgzgtPhB3xMQR/InDedxxro0Mnw2dC51FSxCe3rPlkrCke0uwLmk5eE0hbTIY Zsb4+AkOjhNxOE/FfzReE7mf0flaRvC071MMM4P61XjbOz+LIcMGT7m7PQPeAc+AO+6Ouzqd 7d5+xtmWOPf3zwF/xVdaqbaozDWkfpet0fCSsZS2mirtjaaKH6Ik3N2DXiL8+lG0yDfKhc6h eUgC+MlARdm2IkHWmE+a6u1iqvi+kfJTN48myTEBZQSqxUa05Fete0HUxOLv7PZ1+eJkx9kT SAoX8EvFJ9as2VWQX0rQIWpY1aWOVbnUsBz2PKttsF0oGnjpNv7luryfw/9w20/wl4/PF3bE 0JpvJZ/HpaiAkV9Wj5ZUNqpVddEDQ8GQ0+cnOJZhGMAZhm5dW76lspIUxXWIgS0uuyvw4Z/R XELkau74/JIYPxyVAI+kk6t5mzzo9rgggAdMPgPlAIuOmHpVCBtsZhvoFaD32gI2XlxID1lY kUA84PMFAhaX3k1OxREj/hOlbL+WJxTF0NNR/uEYahEDX+KJS1J+8+QKuehZAWDEe96nN9KU 1k5sFZqFlTbhfkEBQoYClk1kozSLudpSZa7W7zMqkyp4aJeLZTiOYFl3FxcOnQ6eCZ1Bq1zo PrQA0D3wQf5nAunHhQVT6+VbuJwR+DegeZ+gTLQkhPf85k/2Cy/CShBSV4n/XUv1eNrB+ORT caE3EAjJhKLAnETq1TuI1Fmro/PmdrvnzcOw/wEMuZ3mCmVuZHN0cmVhbQplbmRvYmoKNjIg MCBvYmoKMjUwNQplbmRvYmoKMTggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 TmFtZS9DT1JJUk8rQ01SMTAvRm9udEJCb3hbLTQwIC0yNTAgMTAwOSA3NTBdL0ZsYWdzIDQK L0FzY2VudCA3NTAKL0NhcEhlaWdodCA3NTAKL0Rlc2NlbnQgLTI1MAovSXRhbGljQW5nbGUg MAovU3RlbVYgMTUxCi9NaXNzaW5nV2lkdGggMzMzCi9DaGFyU2V0KC9xdW90ZXJpZ2h0L3Bh cmVubGVmdC9wYXJlbnJpZ2h0L3BsdXMvY29tbWEvaHlwaGVuL3BlcmlvZC9vbmUvdHdvL3Ro cmVlL3NlbWljb2xvbi9lcXVhbC9BL0IvQy9EL0UvRi9HL0gvSS9KL00vTy9QL1IvUy9UL1cv YS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveS9mZi9m aS9mbCkKL0ZvbnRGaWxlMyAxNyAwIFI+PgplbmRvYmoKMTcgMCBvYmoKPDwvU3VidHlwZS9U eXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2MyAwIFI+PnN0cmVhbQp4nK1YCVRT 19a+MZJ7tY7EW8C2Cba2TtVKnWqrVZzHoiJOpaIgg8xTBEQgAiHDTgKCzEMSIIABARWc6thq bbW2aiex1VZL1feqHWztvvTw/v7nAlr7v76+t9b/yFqsleTcnHO+vff3fXtLmN69GIlE0n+2 14qFK7zGzF66wmO8+IG78IREeLKX8JQ0gJh/1XSkOzU++dRMZ7w1GOMH4guDGKlEMm/xutlR 0Umxm4ND4t1Hzh7l7jF16hR3z4jA2M0BGyPdl26MDwmM2BhP34S7e0cFbA6MTxrn7hke7r5C fCLOfUVgXGDslsBNXZvOjoqIVsUHxrovjdoUGBvJMOqpnkmRAUtnRW2aHR3oNScmaNnc2OB5 cSEr5sdv9l6gCl25cEvYooTwjYkR/qtHjen3fP+x417xmP7iiAkjH5M2Svo2MRHNDP2Zp5l1 jBczhxnHPMMsY+Yyw5nlzDxmPPMss4KZz3gwzzHezAJmBLOSWchMYEYyPswiZiIzilnFLGYm MaOZ1cwSZgyzhlnKzGLWMq8xs5mXmL5MPyaC6U9/fgAzkHmScWYUjJzhmCFMH0lf5mWKKMMy IBkm2d2rf68a6Uipsbdrb6PTEKcEp/OyKbIDrDtrYn/jIvp49znVN77vr48d6remn61fZ/+W AcsGNA3kBxoGfjFoxaB7g72d+zkvdL4urxoSMuRHvuHxPo+vdpG4eLpcc/nF1cU1zvWIm8Qt 2u3QUJ+h+55Q/SZZ6rNsQEc6OHCtQ1hokUCHp1R4umMJn1Wkz02GZNBpslJIQOffXZPWBGzz MXDhbKVxv6kJHHBcX2/gHOza2Gq72ZhvNCkPoYsTguwEGWvUmjSgdYvwhmhFONtkvgh7YD8c MrTqOUcS6wUpueoGjtiEfB6dSJsTUckG/NZr4JlBZKOt/EtB5ZDAl1JhArbz9rPHjKVAd4nX RxriIQl8TSojPYPDULoVYmG7QZ+V9hwxuBIp2rT5+mzIdrM3Q4XCwcYYFuq3QjQEGCNM9IE3 oQKKQ3B0p8Q1KzUlVJOqWhk1bzFkQTwkljuy82xQytkTS+MTVKkR61uDj55tOXWqSkFPNcY8 HhyCU6vK5tx2dskFDLzgIm/AXniHJ1Z2vRoW0As2Go+ZasBOEdktIrJADQeVuIT96dLb584W +KxQkJR/sXI1vYNhF4feLFwHR3hTSlmoZTnMAt8NUUs5+cc/s2SY2imcvZiXuU454DfJkZgT 6mpsuNVcLYFruPqWFInwOO+v00RAKhdTnlBrt5Tt+nDG3lfJ4BcIQwaRId+NRA6H1mO//Pzt oEvXazV6ReS4RWlBwK2asB8n4ZSrrSd2njUEN9Lfl+50WMHRIXFI7tUKVV9IUdMxik+36ShG HJkeXiW7bFIHKzt1bDT4Du+6zBFTAzTAEX2jeJnhcLhGKTQZWdT8o1dOak56PrgVgDkvuwAN Hf1djZ2XZMF69auKuHBZs/lD2EtfH0CzjnPEsa/qC5qUQhXbZCq4rKhykOmyGABDZhKJ6jzj SoNwymcZzdDzNtzrcL53DU/fmfW9i1zAWKEXjwa2wZR7WIGDZHcaJ69avG4KkSpvpvN3Ki6c g0+4Gy9cJY8rOns9PH0VK/+55xjCkzJ0+6b9bzemfkqkhcql5ApPBst89bkNSrTjMva71nEL 5qyeOlw5QNCpq4XxNhH1XdekQhiG8jhkxH3SnwweTSRkMOF/GoN9sP8Pd1GuIDHEl98Aftbo Q7EH4F1oohc9WXWg5tBh6z44APtV9g32DbAcAiEYfFR+qvV+kWuB6041tU3VKrjZMKjVme5V cd5Fvk0Y9Ba/kMURBU4Odm5G7hGl8BNLhj9MCxLOyo80RW6w+zxB+j49ivBEfnckys4d3F1f rURrb7KRpWWjV2+NeH29agOsh2B73J6YFt0paIFm05m6g1bHnoaT0Ait2xzrC7aCHpLEs1x6 6SuVo2MsrcR7QvQuacfYjul8GeSqtVpIy1Cs9QxqWnN0DLgRLzKJTCAbSABOJh74Gk65i0rk 8iE3VQ2a7QZlBnnGfSqRAPcaWbMbj+FxXL37XZS0jyfPWZSmFNAVA1cKZquy+/5klQOftwlu rbHVzm0XsPSai/wLnI3f8HXHjtQdA+7jdycQJ9J/7hTPgEBLS7QyxQpGsHAre+ckt/p8Bhw+ 9tNd5FE++jvSe/pGP1WCUn7nfA9cl3I1fsrOkAeluNt43GSHGjjWnb3dRTuNfVhmEVac1RXx 9PNSYSgm8zYzWL/zuUOjzb0wnP4f+vNoZHHAQZRW5GeYstL1mgy9MmS4B2yHtRCwK7454k04 D02c0crvwFFfVu8G7l4+eWKTWGl9zgxS2Tteqhbh9bsn7QjEWzxuIGMoiovIfDKWTCT+ZCOO I+NxHi7CMTgB1yvIV+RrfgwZ+jUWYyE+9+G1G/jMHLKTlJOnprwgAki+VvfU73VB/r20sWMG H17FPsj7B1nfS4bTUIEjcRmuIE+gB5mhJEP+4c53Jb6wp7ucvpe9BxdUx+bsX7ZzEkwHIk30 Cl6XEL1i+XNdqSpydXeoRlcnWMRcLaW8+IUw6F2ezP8rhIVTKjZwvJP8Tm2q/9lXniDc06PJ 42TwneeQu9iyv86mNGM4T4axEJYUpYpLTQmL9gVu1mvtFOnHLl775PPWiatEJvToZmUHTvwy zya5cv7WDSnOE4bzKHOQPsjJvn7zzQPmEsgsUaRpk1IhlosvTaipK7FUNQc1rJo7edUwBWGn hV8hlx+cda/xsKkW9sFh2EcZaQvrKTISvWiduBHuseNZEVU8ek+KCXiBx+ky7IfMF9/fHfk1 eUpJ7j/CLw9IrtH8CZW9PfApNP5Ocjos47GyG+N2GU6AYet8gXL1hN83O+PAht2Se+24rlra 4Y4FfKwsloyLn0VmUhp26+EnyzfsnYKwycpqLI+VTVKHj1Z4YKasmwl5GY6FmpWlRMlVy6JQ 5dR55uHxrA/T4BOquRKtyPg96nb+/nUX+UGc2cbjOMp97Z/lmsBgUugMCWkQw0VZt9nKqwvr 68PrNswKXrAhRSG/jL1Yovydiax/DaagI/6VuOL0l5UIlc5wPOFTnPVp43EX+S8YizP5ifB9 ZY2xvqRamVdYWbsPuBswIj7aELYtVpmRFh8VANzIPH5vVIuuArjbFy5cbk5ujq1UNu1uyikH E+SA2aDWZqkhjdtalFaaX5FbWZZWvynBT+O/UbGxYaNZBdy4efNe9bMFVm9Rpm5LCoUQTt4B 4UWBjgSvrWEbIICb/d1KHIB9fzrW1phybE2tYlXtcniNKvQGyDSGZW9xQD1kQ2WZhUM5+Y1/ bt6xE4f2NB8wK9+RXcfeMMlnztpRYhSNZwbRKB524KGuKK6sxmeqpcKVjml856F/jgNNkzYq EC1wE5ooWKHs81DUqETDdfbb/AfxnbI9dIxiEu7oiW8/GY6Gau9SoqDxpUE0UL6yCZMrnKEy /k1Mpv9c5O24CVfxNu3VZJjNrQkJmD4l+NRXiQpdkSF7O3CpkJmkJK7sVsgsyDEaKyoUJhOY yisObDxosFIWZQ998NGJiF1phcrQ+k15G/M4+WXvggVFp4c22luuY68cj3CTwpi+k+LOFUFO hfIHVtSGLD2kpSp02u3pWl1grT9so/k6IHCBd0hpVI1KWR9Tq/kohXtoqbpUTtImOiqp8Abm 8I9aoCng55UczBnwB9kjWtdZ9t9yXPQUXz0ZrbLRQJ2w4XHqKq6jAZ1m3PvW7iLfivF4n8dC Fiqh0GbON9WBBbhvsLeWPDsv7mUyUvl9Kn+nqu1daOO+JbIvyQgF+eBPCKDJfKnL5VzqimwP AeAOVn4UWVkptELj5j3BEA4LYBEEtAS2BL+l2QVcW9nV2h1QQPUzPdOg1MwJSYqFdZBxLOV2 6ueuSefWNaysoMeXDjpIBTrdgrEO4VmHM5WRye1h9aJd+OYsX6TaF1AA3E7IK1HiLHZvds77 1BEHGVbqIyAAJkOwmQuvZ78xq4OUi1n5YdKbyNOjFpF1jV0CvbbhzC83PcgIi+JRfcbt7KP6 H1bvc3Ik1f/XyGTyItlItWoimYArPv7c/s5ukaAzv1ZTDR1hwSgHvmSRfHUBh1ZL0VOk6Gcc 5BlcEiszTI1wH6XlVF+ROpYMvJ3WdKn20jnFqdiVLG0HgxbAzTLqvyW8WE2UobD/fefW+3Op I7qNc4XXeOIupsX7OzWUeGwPgl1vPGmqol6msTvYC7U5e5XyH7KFPXx9rDUqXBUdE22LcdRW W+t7rD31OONrncEecw4/PLeKxv5j/FFw5ckQx9KSTSfhtNvFk++24Ss28tL6HQqjBjQFPRmP b3TBkWkwpGUqQlZE1Pm3vEjhkE6ZMOylE7PaopUF2mNpF7dy8ts1mbsya4OsMfmhEMrNWTt7 SuSMnCOrFMtP6s4Zmgz5GaB7UI++XfWYazQV5CrAaDY3nHBsPhfcTuuxz+d3sdf3C69OsSi7 m7X3HLjbIbLL8Xap0CH8yPc4Z1mIzpMay0CYCSE0yD3iT1LJcUxl/3LNvxMuLMHjpOSv1zzi YZ1andu6m6VE4YkrvAeLwx8aWCoyyJIRvwvHPHbi6/NnTdEePq7Ar3q+aQPdi0oymp0O4/H5 tw/Uvlen6NZ92iOWfi3EdSUE3Dr+8yKaEr9ikJgSz4sPXt4pMoU7uz590uKseCiKUZRkW4qh hrMnWaKikhJiVr8dderT987dVMg7O8b1rourioyMi4uMrIqrq6uqEncRzS/NualW9GyWQDXm tWMeleJxHVP5TpQlEpVTtawYJ5U04Bgop9SSr7dqQQ3xHMVwM6Q8rQgIl7WYf4RD9HUPWig+ AezTULxb7HAokxSXZxdQSqoA+nhJaDGZ1M3im5+M7jZvyLRLUSXG1FxwRWEX4zWNRmsTTOuK l529Yu6Jl049TREjxuIKjcReuNIVixh2mq47FtSkqa3CUOrhhRSpMBGv8zsry/afNz5sp+Pg DdNWsZ1uNhTQPhhof6hVP0vyXElvrNcUUXo3udn3QjkljwiDtz7+93b6LGRrisJxOEHXHSmm rCIoguyd2fk91pCCx9ZhDGX381Lch6W8wZS1A8yQfelMft7ZY60mq3iGSF0qRNEeaKkpRTxD hSFfDamQkJKWkUmGkQGuQjz7p9zfQN1FHeyCfYZ9+gfcf48999blYa3ekOSWuFWbSFfVGt8x WaEO6gx14qogUEHgCfF8kq/VKttp7C1socBgbxx1XYpv4Uj+hbXeqzTz4XSw4njhLntTlCVK tTnFz/OSV/uPH1/8tEBpzKN47OaEZWxLMZylkPjpAw2+sBEmQCANSxN7F1JDlN3Z0wO7OEv5 Ddv58qOOokbxyioKuwoiYb0pUbxyk8GWRN9pQJ+VOp7sdB2J9dpCAzUzbjV7wUK3iDSs0cdB BER2o94Mpfr81BxNQURu4iSS5fo8WrIK6amyH6zvjpIWVhmDxfVHoVBXGIbO5BfXnBRzhhgl 046c4h+wyfVH0pytFj9yKwJzd+S6qbZD0h22uR2L+H8B/wlTNVTTrr/5ofSKDbJtqwPDrDXf vGlzhsuv38IpFz6udpEnq/H6Z3x2QM3Gw8BZ3y3+Qvl2rDe7PFajDtUezFGgL0t1cG9w86a9 a0tfB27qPN+FEZat9tpyi70wq+ENo7Km8UhBPXBHTm16URlEpVO9RjdXtyRi5ubY1eDHvXwn 9uz5Q/sOVygy8SV+BPv87M3r1/k3Hn2r9RpO3aF4mI5OYhEYxWRM43ft2XOkyu5oaik5LMYk Rh9hiKEYrzKlijGx6vNSIRmSt6dmaZZOd53+Q3o+RXiHG5SU7LR0rTcs1CfDFvA1RosYXwSj 4bDXd4R39fUCve+K15cv028B+oXd5DDaaQK26qtEnFTmzCIoAVtdw7sf1W3KU+9dm6cuSqax T0/fFi2O1XYZ3zbZaLe017BLTFgfSDLF14lK7ykOP/4wgeri1cb/1hDq/zuuEr3a1sCUG54F 6x+Orj79P6Orbl1QW4ThXbONtvNYQVv7IzhT6M/jxT/U+e1q1mjMK645zMm3xZe0rv3kiQdN /ajviGz6Bt+kZKWZlPLoz1IONRaU7n37rbwqOAhNMVWBdn/zCvCHIL1X5Pot4YGhPuLAoyqu OcVK6aecotlbSjtva8cwmg+/xkl/HSZc5ctP7c/fK84YI/ThBlprsNgUI2bCBwZLKCVFjS5D ryGjO/1dyUQh1ZCt30Hrc9dpsNN6C9bN71LSDSZ/8YlTYIXCYNtcV6Ls9CSTBLXBbMgF879Y /SlkZxUGoW9nh6s53by9CIrBlJtdhFOFHFd8uXNH94du3Z9y3Z6KmK2/elskOOu0FFvRzEOb GvuvRCcvHDjpfWrsNVqtRgf6iiTl3ZGnyAQggUBmBJE5ZBBxTk0DPeg4TbZ2R/43H6L8HcUx 7FWIUviS655IvGTFg/vwEP358/ukwljcymO9rLgCLJZESFGSemyQFUNFQgIkpihIA2lgUxIh IaECipVI38lSINFigYriR6amjgwLsu1NNucr53HJLVGpj+I16gEP5ab6K0nlX1GKIGWJc3qy gf6Bm96ghxTg5NdIX3SSfXd933u7mrbHWxT+ek0UJHOh9tSKysrSXe+sbPUcRx5bQyQKIvtD e/9nO+Bltpv0iI8VZ96X/N0mxfmlvNFoSFkc9Zqfr1KjoXtrucwcbU7hlSvInotrCQhJio6J KYtuKi3ckZf/6E1Ra1F33TOY3vKOIKe3/Ovthf9hgzVO8i+0YDBqTWHF/tRCcE8Tifczyv/s 8Bjs4EkoxeP2Z4c+2VkD6bWKdG3ydoiBpLxtZRoxY5b6LEOv01TmyqVYh178aVK+vOfScF8C 96W48gT/Jw7od1QwqmedMOCfFyZ2Snkq4dMXe2ZmdOWWCFXBR58jV6f/xOcBVDkmMBoVucYC U14uR5WCwtXsOECzzOUTKR7uGMJXgSlesXTxBAgTedMC78BxO9dJvaYuzUMRJvqbG7CPvm50 +Zsw1kNX0NwzREO3fThuH1XasdKO2fg5X/IgWzu/lfVkZ4lS+DtZxffk8TZl599k2x7krXia y/jzzz9QOvgZ/W5KBR+cxcfKsiIy/bZvy8xYSF0DRxbI7t/D8ag4cxK+d0OZx+dkAHHyfOFF 76NgLmssbLEn2UMy9GDQKSrfP9l8Grib+1+e+sraaSuXKslKEqpWU2zi3ARW1g2soOxKt7s0 3fyF6/yZuIMbHkBlKc7fQfsMk9FoBM4EKdqwzNlLlirT0n5H99pn2FdBz62qvYQcDq/Evj+8 V+1MjczkH/GVWzPuucgJg/vxZ/5qzemLcIW7OuHtMc/N8JoRakusc1hsdUd9YZvCceR8URNw LW+pPNL0y2P8lBGvb9bFGjIMcfpMyDBkGmA7J+9Uq3OhTHFAdrV5/ijy5LxIvw0zy94JUTZm OWywh2uKtkTGhaX4jb+9ECU44ObNH68uaXvGqvgDUQHlqS9JJk/Z17S1jAxG5zBcDjgWcNYe nIUDcXCRaGDMXK7WrNnuMZ/IlynWkF5pREplZXoB6f8WcTpDBl5flA/cjmxzrigl87v10IE5 4uQPg87fviEVVoqdJeug/MDJ2t88fPBPh39NIbu9l/kFarMUkc3eOdHAPU+41YT5z+oNg/7N tJAS5H0endg7V1vfP1KbCIpkXYLocDXG2Jp06nXTIY0jLDtAZeuYYSM1ZRhZICP+hayj74XH FH17T7H062Pb2a/fBUu//gzzv7eIS4QKZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago1ODA4 CmVuZG9iagoxNSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL01BUklE SitDTUJYMTIvRm9udEJCb3hbMjEgLTIwMSA4MTAgNzAwXS9GbGFncyA0Ci9Bc2NlbnQgNzAw Ci9DYXBIZWlnaHQgNzAwCi9EZXNjZW50IC0yMDEKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEy MQovTWlzc2luZ1dpZHRoIDM3NQovQ2hhclNldCgvb25lL3R3by9JL1AvUy9jL2QvZS9pL24v by9wL3Ivcy90L3UveSkKL0ZvbnRGaWxlMyAxNCAwIFI+PgplbmRvYmoKMTQgMCBvYmoKPDwv U3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NCAwIFI+PnN0cmVh bQp4nGWVe1QU9xXHZ5hlZyBIFDMSos4sKkrVBomeqG18ILoGFUWJSIKPXWSLG4HF5aEgLxVw 2burXTSAorAQKkhWV16DwZYQbcjpwURbY3pOq2maE2ObcLTHFO9wfvTY32o0Pem5f82c39z7 u5/7/d5hGY0fw7JscHzMpriVa+bExq9Ijn7F90anTmbVKX7qVM5Nto32jyb4d03h/xKC6RNw 5fMYPZ7hWFa/LiXWkl1gNafvytVFxv5MF7148UJdTKbJat5pzNLFG3N3mTKNufQhQ5do2Wk2 5Ra8rIvJyNBt8n2Ro9tkyjFZ801pT6rGWjKz83JNVl28Jc1kzWIYZkJB1k5LWrYpwZqTa07M i6M3Y95iNjArmQRmFbOR0TPRTCLzBrOZWcMsYJKY2UwIM5EJoR0xGsbG3GMT2Qt+4X7Vfv/h krgOzWZNveYbf4f/37XTtGbt39Tngh/5bRxgyFaPelVhAVlOPaQ+L7pOHD02BILCm6sOQypk QxVscgoG3tEHJTZbhd0mkwDya/ICnvW/rGhzqlaDBbIgAfbQQ0M8xo9FVJYWZ1WWhuVv361f BYehFMpcTsfZWugQPDnuzIycfPPWXuPHtz+82dsoBY/6g6IGetjryOJ23x1acVD8NvW3xC82 ftdys2RHPy1ZcsjfwP+hGtJk8ke9gW923oBWGp9Bc5Wg6NHMI/PXgaEL7pxlEjnz/wf4YNVW 4VVDvbTLIFyNgZy6CwPE2jI4sN9uL62Uyvdlvx4FAgkHnHtx0IGhGFo9WFVpt9ur7LLNVlIE VsF4rrDF3VHXd5vwrs1Ev4oIhCdTvo3CWRjdjkK1RHG+UsbQOi95HtepxSBOPYMWESdH3SPR ZOGC6WQSCb37c4zGhV/dwxCJOMlGkUwCDLjdB79r8MpNXRdPK/B78GafsjSmwxZIERYBLST6 OFV4aGbc3P84uYuiwvujK8SnXLbzeQ072vS0iWkz5xMdmX7vVQy73Nfg6ZS38Kh3+St8fDl0 yqrKE3bsjmhcn1ySTk+PB5z4Ca3e1CG3Xxl0NUM39BZ4dgi0IElSMMLjw+Ybjou2g+fJHFGP b2hb8nqtH4OAUx9+gTNRevlrMjkhee/unfIHPIl5NqyxYz+dhV7tFi9cGqjvBOHqYAJ5kUTE Jq81GJr6MmSKj10/UOHFxDZc+oTgwbucmox7xGYXtJwt/3xbn2zsSazbSG8979UIEkJ0D+bh HJxzceTUySKo2G+3lVTIe9bE5afQExF2nHxFbtM4ux2dbm/De+ebFHgIx0mQ400h+BHHlF8H BU924IDCjuBE7MNwDtvwIxGXavGX//jyATJzvySL5bG5hpGx4XCDts35ELw0HkIblVQ4jy+p wyJGweLVcbCQRMlExgFt8CN2qDj7B0F//wAFDtMwT/RU43wMkIrLyguhQEj1FLa0eE51929p TXnNrDcWU41zWrLopxr/nEJrg1vwLq23gKepLw0wVAO6syxcw/3XOHWcukxsgOqiiio4WCQd tpWVV9os9b9y0bFmktlAJk3D8XntlfKZSk/FUeg62GUFo7B0HuQnr6sftkgVjXZHIQj5YMuV Cc/vg/KT1U6ob5R+03Bx14dwGsIu44RaDLu0x7P3tJx6zuza/M7amg01cEm4+jW4kXOtsjol R8kxqAXBDUea6QjZnscO4BVc1sjeoqoZ18Nhuhoh4gyFzMBEo9YemRIZaRPevkXa+fDbuTdu 9l65KQ0Yt/BxmVkZG+DTZuojdlEZQ6ej9v8LZ1COHOaMcmL32+1pqRlmk6nd3N3pae+WyEoS R+U/+D/IrsMZCm3oMbJ4dQ5PRVyqjPJdLNzBz+5wWK2uEyObbDfghNDvGRwe/morCXVLR/LB 3vBDC5jA+5CW2+wHDkqGt6zuNztnQxiZviyasK97t54olj/Y0lrxfe79vNqqpvy6kjYLJAuG /NeIZj6Rz+LMQ5L9NBzZ+xRrwhOsDsfxd6SamuN1LS0fbbtd4nPOvE9GRv4Zf4ewLfITbwv9 z3Ygjqjrnxk7mV+2ff2S5YdbLkv4HU/0P8rkAD/r06yH796EW4rk+IUWY340ucanl2ZqbkUd VljU4Iscto6GiqhRtOlVs8BIYxak05WNmrFhojHwXud96KFxH7wUHvEl8K0zmuCI0tvI0i3n z+G9UV5sq4LdUsxawkEeCPsMDdrzMODqqhPGmohs4Huc/4Y+GiPQ40sz9WkaDMQhDOv3/WfC MAFf4FQn7haNWlt+eULRgUPlS6CImjZK2/HeN38+WYPcF9f64TsBA3V/okvCf/bauUlKUXO7 1/1+T4Y746jU9f7AUTcId3uXxy5Jik01yCST7D1wkP6rCsIK1UV8cGnt6IpaUn0cdzRqybZq XglE9jkpULOwMSjg3PGgIGSbg8Y5goIZ5r9rd8lICmVuZHN0cmVhbQplbmRvYmoKNjQgMCBv YmoKMTgxMAplbmRvYmoKMzAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9NWExPQksrQ01USTEwL0ZvbnRCQm94Wy0yNSAtMjA1IDg0MiA3MDVdL0ZsYWdzIDQKL0Fz Y2VudCA3MDUKL0NhcEhlaWdodCA3MDUKL0Rlc2NlbnQgLTIwNQovSXRhbGljQW5nbGUgMAov U3RlbVYgMTI2Ci9NaXNzaW5nV2lkdGggMzU3Ci9DaGFyU2V0KC9hL2IvYy9kL2UvZi9nL2gv aS9rL2wvbS9uL28vcC9yL3MvdC91L3cveC95KQovRm9udEZpbGUzIDI5IDAgUj4+CmVuZG9i agoyOSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDY1IDAgUj4+c3RyZWFtCnicrVZpVFNnGr4xiteljNVGJ6NzL7Uei7Z6aqejdWxnqgy1Loi4 gy0Q9rAkIYQQiIGEhJDkTTAkJCQBsgAJJKDsm6wuuLSOaDvqVGu1zrSndc4sp+30i3M9x7mA nXam/dHt3F/JOd/7vd/zPs/zPgxs5gyMwWCERh3aGb1lxzMRUfu2rXtu8p+w4FJGcNmM4C+Z Qopz//37+2cFloXWLUTix9G2n6F1CzAmg/HqzsMRfEGhkJueIQoLj1gVtm7jxg1hm3NShdxk Di8siiPKSM3hiOgf2WF7+cncVFHh2rDN2dlheyZP5IXtSc1LFYpTU6ZvjeDnCPJFqcKwKH5K qpCHYdjiQl4yP0WQmiZMz8sQcfOzCrI5kpwkDIvDorHfY7uxSCwGexXbiu3FXsP2Yduw/dh2 7AC2EzuERWFbsFhsFxaBLaEfiM3G+hnZjEszVs64xTQz/z3TPGvhrLaQVSF3Z8fO/gKvn1M4 95W5PfO2zp89/8Fj2oeM1LPPhT5kfGjAKI5j7OaAJ7jCJfcsrLnDO+84vWTRv9B9LyuV2rg5 IRbww7IOo16vN+nJgLHaBzW4W2otLEkp23uwm3vqs48+/Xsj8bcgoa80GKGCbVU6CnJUPKWW 2EKdmLXorzxVcvTupfGlfa3nWz9snCDNbqMdnPhwZiBxbQYVXqawgNGmN9iPEuaA79444Far JjdPIZClkLmRuZvhIP7COO/kQKDBZiNCH854fsNluSe4xsNAY6frzjNREYpgGT2VbqPHNgL6 2mZ7Q/+164D3GeLFUQnUPFkyWczVlIIYT2hKH/z4GFpltChBVQzaI+WEUiBYFQO4WOewN1q8 5gbSNdaNZsI4fmufJ27j4WhJMaEa4voTIR0KRNIcSXLxbtDi0w3rPUai7opzKAC4F3hyqUZS LiVfoca0ZTo1aNhy8xFXda3JaSJCg4lyD+q40e9hwBXEucMMbg0+xootgyS6ltQqrfc1eDqG Ett3UAsoFrWcWhl+dtuf0RPv/8NhVFqV5TqdQklsXvN8eRHg+4X942O+z72DZNvF4eP9YIV+ rSMJp8f4cJlgGhX6iuorzGAlCrDu7b78wpc1V7wZ9T5agFhoOXqaoCopFyslLfDOsBcxW06S 7ecH/Z2ADzUl7E7MX5EVTfL2HYqPg6/XRWk9DJhgBk/eX8fSVxjMYMCryiqUGoVOpyHClSU6 uQ4kbLkF7IMGlUKjKQYdEUMVHwkIfBxgU0xqLvUstXL9QOS1tj73UBdpjWsXH4d2cDc6AnUd 1eN0vcmxlOh0+WWEbK9kJxfwXPDZTeCobCB3N7CU2bs27QP8deVZ/3AAzanrIRvPDwx3gxnq dXV8i9TCAwlodOXaskdtUwcC6NkpSIKbLzE/pJ6gSyg1KTq8tAQkKqPa5GuugCayBY5p6BFW 2sBZrQDZIai0VJq8R2vINrTSVNSYNApsxEDzUDha9UX0UHRcYjqXR5aMx1cLvwMpykCq4pNn RSzzsQs3TgHeb9mTxRFQ83g7yBJhYuQhwGMUd8wVk4CS0zQReNAmeoiXkbqDiZRIyvLDpYpB 540WuAgmfCCtc8dy6qmVVOS6wfX3vp0j2+Vvd3ZY+k0+stLD6kUvflphAbyrXsB9ktoImSQN zvMBN8XxOG8GJQG05l03fd1tdOE2E/mDK1i3QmotUGdTQhH5coj9akWd44q53TrWRuPs1tqk OWpZHhTg+XWKmsZG1/HepPqkVUJqMVdFiKkZs7aFSOVQQJPAQV4I2fJgTkmUIqlMzFZyiw+m gwIkFXKH32hvABfuKbRIhcKCjPhecftn3SitjZbJQ4bXL5C70eUbDlrc1+iGrKibJls/Yn0A RmgClyxDrskCNV5cJfHWBeydo9utma+mx+ZLCflYijPzB6rUb2o2GyZVSoNS/adPPMFQj9az EG4LJpYs+hx9NMYSbyiJLRPzuezk15PhCBRDNgisLnO1G2pxW6kztzBblpLcXnj78+t/uO4k ECO4/agDDHCU7S4yKkpESl45sehes0zQlLiUmknNpsKpJ9ef2HptpLe7upq8iOyseGq7MmvX y/uAvV973TroR3PcJ8jGk339tCjPVW1QTg7NdpcW4pmbaO3EsIfx7mm08AwzuDg4m5VVrhSA ApdXFjXUeqt7B5I6t1Fzkp45+NuLsqYyok/Rr4D9eJZg04r8GOOIlBgxQg+tNWexTSziF8Xv Gk9/G63uQKEDd1+uS6oi+JXpZujFG9wTN33tihQr8X8WgCxTnnv6e7gAFf7grk6rKwUtW151 xOm21VoriKOOFrTY1DTt21VtekNdi6ul980rP4Vvv5aRkZM92fjODWN04+wAinAxms4xkY3m 952QWiut9FKQkptC2lH4UTs9KePUpIQKMV06hfrVrPUhRXKQlFRBDXkzJILq0pWXS0HGjm1N Hv3nyKNGSkBXqCQKDye/sgdwATTWmKDG1PRIXtN4sd9b2H/6xCnOrSWLgug2eor1tQfwBM/Q D1DK9D6vrdXWTnrOuOnP0kxj6sRPpTamreFSq9RfrcaqVu/HU6tRLcqT81QSUp4t5ylFxZkl 9CdLLad1h6c0JI1+0opWHyUWfa4OiliNBWaZWFDAF7qUdleTs3lye/78UXOMd+gtzwxagktZ hko9vbbxr6/tfnUhaEuL2RI+LycB8B+7u8eO+f0NRN3+3jLnd7L8KSCn7HDiPds07/hvnb3z o3jnNzVVGYgRlNCufksMMWxQQblGRhumilZPxAlhe5+n1WklPB328zQYXzVWfEiylYZAoK13 1Zua9EbS6AY92GAi0rezqt7udvsCo2c7B4bBCSa5XsdRqTNAOeVQnqa6Dm/hsfgDiZxkLrFn m1SaUUTvphk2QeL0CK6et52+cx5F/IUZXIBeYqn4OjHIcHn2iwci4artpPdq4BZhchod3xHw WGoZ5IIAuGauN6+F36+phRY4bvOPONK6BGfhHPR0+9/2T3SitTCGHy8J8ERCkajYpKpUEQ25 FVkghuSs5UVJ+Qezkt4APFba3VOlb7D2kT3opUqPpYv2s0mK8FQCmiKhD7GHhufknvssOhac +56DefwBvafVBXCEfaAtbbDD5Wu0EbXH7W89wl1dBmoNoRIWRUo4fGB/lQL+J+bQWaQgOI81 rV98Ur9ZKq5aR0h6s2qyAP8xiWOSfrvdLGVW1G++LXHgfY0HOVqdWls22dHEpC/XvItyb9qn FunwbWaQF1zNSlZAGuj+u6pGYqp5+zLjJAoi/1ycWQj40/upJaKpaYK+xkj6Phjt7AK82SlK ziuJK00j5Um6cvkb0u3iTdGggTwosvvNVY3gwL3iymKhUJyZ0iMaGGzt8NcSrj1Dci/gn46g X7gePUmqJgW/jk3hAF4gqB5tsPaaj5HWHscFc6t91HfqBFRAI9TIaDYy140/itPBb8TpITBU u5uHe8cvAz4Ah44IVDxtKbmdsn0j4nahF6bPsL9x6Id7+e0Y1+uRsQkJOYTy8kFnPERDXCb3 jZ8oj38Zac8gwaXvR9/wB6ROo0iCVPaGnq1/RDPRHLQaPT2ZDVO54iwuoXkQyhJmuq/1VR1v RiGkqQEMDldzV8exjm/Lf6H5nvu/81A+K8ozhFAc6+zA3Il5xNyZG1zz53iq5s/HsP8A8gJF 9QplbmRzdHJlYW0KZW5kb2JqCjY1IDAgb2JqCjI3MzkKZW5kb2JqCjI3IDAgb2JqCjw8L1R5 cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvWFBOTllJK0NNU1k3L0ZvbnRCQm94WzAgMCA0 OTYgNTU5XS9GbGFncyA0Ci9Bc2NlbnQgNTU5Ci9DYXBIZWlnaHQgNTU5Ci9EZXNjZW50IDAK L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDc0Ci9DaGFyU2V0KC9wcmltZS9hc3Rlcmlza21hdGgp Ci9Gb250RmlsZTMgMjYgMCBSPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFD L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjYgMCBSPj5zdHJlYW0KeJwBqgFV/gEABAIA AQEBDVhQTk5ZSStDTVNZNwABAQEe+BsB+BwC+B0Di4v4hPjDBZ34KhL3TRH3SA/3QBAABQEB RktaZmtDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHku IEFsbCBSaWdodHMgUmVzZXJ2ZWRDTVNZN0NvbXB1dGVyIE1vZGVybmFzdGVyaXNrbWF0aHBy aW1lAACAAgMwAaQBigABigGLAAMBAQKc1w7/AklRsK2g+BqfAfdByQP4a/fNFZmRlpCLnQiZ f514g4iJhIEe+x4wmvcqjZgFl4Cbd3eAfH4enPs3+x3mfpOGjIeLGXh/eX15loaZhR/3KEz7 KEt9hYCGi3kZfZd5npOOjZKVHvcd5nv7NwV+lnyfn5abl5F69y2Ljx6peLVuvmmmeY2LkosI npedmZ59kYWOH1ihWKBYoAgO/wFJXRC0oPhxnwGL948D97f4bRWPlY+Si5kIqnCja2OBan6H HvsZ/EWKiId/i4kZf6qBk5OOkJWPHg50ovk/pAb7E5UHvAroC7yXDAwAAHAEr6gKZW5kc3Ry ZWFtCmVuZG9iago2NiAwIG9iago0MzcKZW5kb2JqCjI0IDAgb2JqCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvQk5NSkZKK0NNVFQxMC9Gb250QkJveFsxNyAtMTEgNTI1IDYy M10vRmxhZ3MgNAovQXNjZW50IDYyMwovQ2FwSGVpZ2h0IDYyMwovRGVzY2VudCAtMTEKL0l0 YWxpY0FuZ2xlIDAKL1N0ZW1WIDc4Ci9NaXNzaW5nV2lkdGggNTI1Ci9DaGFyU2V0KC9BL0kv TS9QL1IvUy9WKQovRm9udEZpbGUzIDIzIDAgUj4+CmVuZG9iagoyMyAwIG9iago8PC9TdWJ0 eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDY3IDAgUj4+c3RyZWFtCnic bVNtTFNXGD6XwukdIiqkEbLZ22mWTM0cRKPTuDnWjA0iCwPETDNDwTu+eim9vZRhuXwUCtKX gBWkfLRQPrUQK8TpItOFxMTcCCw3uj9L1GzZzEi2HzNmOXe7/bFbWYLJlpw/zznv+7zP+z7v oVB8HKIoKvmDT/Jys3P3mvOKijIzYjdG5VVKeS1O2aELtCjjf+kSwn+vpJCPtpF3tpC3tyId RWUfP2221TbwleUVgulN825T5uHDh0xZHMtXlllqTHkWoYLlLIIGrKZCW1klKzTsM2VZraaC WIbDVMA6WN7Jnl2vabZxtXUCy5vybGdZvgYhpM/Kyy8ozClGaCfahzLRfnQA7UGHEK0pRvGo nkqnnHE74u7ptujsyniyMg7Sc4nIjyhQqnREVh4Z3AtitxVqwAVuVt0cDaWJIICnq8XjaYUm mpuGgPEZDk5CeLYeypmJ5wnkIJ7YlVBeD1ZuEoLMMxyYhvBgx6XmC4ynpw4agVbNisOwqn6X oKbhFyXJLpmEJWrpLpm6qyM3lQRDc7m7xlNDe3Hr4n7i7/K1TvIgAl2IG3ngrCGYY6Kivtqp 1ZiCYeYxHp7SBDihmlHs3fqBz5fVot6mPmGQvdDua/O3+2EQhvr6hnp8PxKff4nujtrx/yaL +rkQzIZ5aGQKcSl0im47va7wuETOS9QDmXTJOnKEdBnINkzo75+urWU9VfWMKuBGu6ZsWiMM R0UOu3iNPoaIAQ9rA5i1a5wcVsT4P/FvN7OLi0uy9zKvx9pvkT6TSFXspKzIJEe2yGPy9lQX yVAWDQ/xr1/nnz515tMMxoxJUbVhdX5Ugq/on449VhON6ofY5fi3i6moyG8gsmm9KQe4GJ5U 4dQ7P+BRCMOcbdwJdWCBXOBGqwPcZddVoO9Pri7MOaClVQDOy7R1fXHOBreW7kOfe8LYfEUI iQP0C5lKn5QCK2RkhV3ZnrpGbpMZw2XPk3o4QJ8syT9qO9U7U2a0zHTe8Aa9AW+wGugKcNYz apreBXx43Dc012+8zkmuZaAJ/fDnX5bLbzQPMqXXay++G6RT/zgStPjZCCymf3v7mwckcfgt q8/YUzfgGQM6AqExhqTpR2CKc3Sc49qMpZET/jPaIuneP3rw41s5TxxMr/d3Yej8ulmKKFFk t+bTHW2EBG3MX13YcImgqKiil/DCS3EoZkxbSLkqaR+hUaec0IiuxTYj9vrGelIIIsx76r2m 4i+PtZeke3FHpDPgnt+jpKdF/hN5TZMfDVxiR+AKpM/AKPTP08ktAwoZUAv7sdpwUS8lypuM ifENtqRXpKQkOWkzQv8Aq3IA1QplbmRzdHJlYW0KZW5kb2JqCjY3IDAgb2JqCjk5MwplbmRv YmoKNDQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9NTUpPT1krQ01N STcvRm9udEJCb3hbLTEgLTE5NCA5NjUgNzEzXS9GbGFncyA0Ci9Bc2NlbnQgNzEzCi9DYXBI ZWlnaHQgNzEzCi9EZXNjZW50IC0xOTQKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDE0NAovTWlz c2luZ1dpZHRoIDMzMwovQ2hhclNldCgvY29tbWEvQS9CL2MvZS9rL20vcC90KQovRm9udEZp bGUzIDQzIDAgUj4+CmVuZG9iago0MyAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDY4IDAgUj4+c3RyZWFtCnicfZN7bFNVHMfvXVk5g22KWnWC 9xYNBnQRiQ8UGGRsGQrUjb2cKGEPugfbaNe169at3fru7a+vrdvau61rO7Z1LyziBroyUWGi JEaCcYqggcQEX0H9w5ziRfEOH/Efzfnj5Jzkd37f7+/7OSSxJIEgSTJFItmZm/vyY1kSyQsb Fy/E8ZVkfFVC/EGBnSv+9eUb+xLHVwl33oUlK/CmO/D6OwkBSebs2pslk7coaqqqleK1WevE G557bqM4s16qqKkoOySWlCmrpfVlSv5QJy6QVdRIlS2PizPr6sT5ixWN4nxpo1TRJD1wu2mW rF6uUkoVYonsgFRxiCCIpMyK7XKpsrZ+M0E8RGQTDxN7iByiiNhNvEikEMt43cRSYpxcQUYT qhMWBEVL1iVuSWy5RUqK8lJvCV5ZXQpRXBiNZwZJXI6TRdVFtQ15Vr1dB6BGHd1Wz8iUG0ap SZi2jgPy9EHYr3NYaaOjygmj4OsZ8HR7vLMXIm8ifEx4mNtk1Ztb8yCtXQsqq0vvH7vghjE6 AEP2AATsISYAyN/l9fe1Q+sexnvYRj8Z/80WYrqaIa0ZzAaDFnHtN7eKcCW+NMtdSky9Rf5u 69BH8PC1iQgJX2Hz94L4zvjdoipzmwxUSB7SB8Kv9cc+zhgs4h7laI7i6KfPPolX4IwvrrOd hl6jmWGMRipjPZcELYCyak9+OMZi8tR5+vWTpyJzwEKMGZYhfhL70zv4ScxH8ESUjMd/EuD8 iyJDDWPcCkijg6Y2HwTo+H1CvAWL8NLrF3Z+sLqXxinhnz6Dq+izrR9x91I3CWGzDlRaHwQd g8AE6BDjZEAPDFisbWiUM4k+wDbvhMM1A2k4Xfjz0PPSTU+s5x6guWruqqjO7uh2gMfdR5/H o4m4WvhtVLJn7SNPcyl06q2E3d8QXHEUr43E6QgZV1wWLHCpIpOMMVYA0mmh6Z+k6CPwunUK UHeva5DVQrtKDj5P1wj/rO8d9t3eGZ964sBZQDgVr+TXOpy0aS5HUlwmk9OaMwX+ejgAjQ2t cnVNay6YkY4FF+twjXZRffODc8cAjXSp5B2Mzm6mF3Si+c/n+iYBHTtyaEe5ak39Hlqxd+8r JYCyWz7vcTu7HO5F4dSSPD6+ygjewOf3JT5yXICVuFkUgS+c7w5+OsLGYBy9VziVwyVzz6zn tj1y7imc9B/h5Va8cZmFoO892hsRTeM1WOCLADpxVCV9lMuAUr4bGXXwsMRTonh7kDy1IMD2 OC36WTjohzCrAw2dLjyK1zo8Tg+40wJaVq1o0zSYKJPCH9vPbUdr/o4vQH8nbN6izlBvMSsM VaBDeXNVZ7DgHBb7/TqwtdsZjZGS7S4pKATUpPVHe9whZ8+i2f25Id7szDU2gstjJO65ePYH Af7oRrrI4XT5wYE81u529bNGRkEZ7Vo7NCEtC74YmIwmxswYKG71zXOWFp4XJq3NpwmP+oPh TsrpPo6z3ewF0xklvAQWsDB6axu/d6Ds+drYD+M43bEoSmu3NFuo9lJ59l5AcuPw6AA4O0do h8s9AL3wNZfMlrnGAkenBvrejs3NngYf+G1efanJUANtSDXQNjQ6Hp6ZajxanP9S+aslVFnF wbpyzeK/+CV2p/42dTc2f+L8VBDPuSyyqPkqC1IF9P2Bfn+3h/J0eyc9Ic9g71udw53hzrBn qPc4OIMTkyfnzlwEdNq1rzG3lBO0ltEdMqsBNKj4xMG3fzyBqb4/pZs7rJRyc2k5D3OTlQ0N efyBN2nfxPQvcBr6YaZyTOM/xL4KG6Awr7bMeCW7vwSehYKS+grT+bxwOZSCsk6nRKpKbT4v 61/Qvj948i9omw2VJjltkuvLLapa7p77rTqzAmz/b2Ha6R2bjrwxe2oB0LyjpFlh02kLFikr eEHMFYdwJl5KXo8IcFW/CAr1u3bsslptNl6AyWvqZK9cwss/bJzdd7Cxoa52qOG1w/394KBS 1cEb24LccE+PT8iV9iydXHZ5ObVsycZgctKkOzmZIP4AGeAPLQplbmRzdHJlYW0KZW5kb2Jq CjY4IDAgb2JqCjE1MTUKZW5kb2JqCjQxIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvU1pRTU1XK0NNU1kxMC9Gb250QkJveFswIC0yNTAgNjM4IDc1MF0vRmxhZ3Mg NAovQXNjZW50IDc1MAovQ2FwSGVpZ2h0IDc1MAovRGVzY2VudCAtMjUwCi9JdGFsaWNBbmds ZSAwCi9TdGVtViA5NQovQ2hhclNldCgvZWxlbWVudC9uZWdhdGlvbnNsYXNoL2JyYWNlbGVm dC9icmFjZXJpZ2h0KQovRm9udEZpbGUzIDQwIDAgUj4+CmVuZG9iago0MCAwIG9iago8PC9T dWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDY5IDAgUj4+c3RyZWFt CnicTY9dSFNxGMb/Z9PtNGWasIvKtkOI9kGRJg5FCllJobtQKc1CXHr2QdvO3KY0Y25T59ze fThzmzNsM79KMCVDogu7iAj6gvKubrzoRrrw8n/WX6qJFcF7874P7/P8HgrlCBBFUdKW9ia1 uvWUSt1yvfzs3kXBH6H4YgF/VAgknCnKDObOZUqL8NWDuLEA1xeiXIqqb7xxi1NxFofVoNPb meOqE0x5dbWSqTOxVkOXxsyoNXY9a9LYs4uRaeG6DKzdcYapMxqZ5r0PG9PM2lhrH9u9H6vi TJZeO2tl1Fw3azWzRtbEmu1mVpd14Mw2o8amRwjlaHUVVQjdRB1UgAKUm+VHAjRBlVJB6pWU HyXhNK+d5Q0pCpd8FOIV/o0MNmFmdm56+uHsp8hYMBKBKB0fAldZRZvKLycNYjgNd3s4p9Ni afTRw8MBjycKsYBifXSrD8po0i6GJjC81K6b3g8tAZ24B/GYFzxBRe2Y9vngymgcQvCExifF 8Bg2/LGBDw3z3XEsWYbPsEj/IdKneUP6L9FXGbyG5dbVzkcNE7eB9njAvZ/4ZWS1Y0IXdoMf 9DTJGpqgLeSZvPKu56mbSAxwETiaXBaDCnptVofDbrvkGwn4fOCl3TGI7Xzb2AzJcbbPNtyf X0wmFxbeRujx8WBsH7czXJWGHVr6SzC1lO5aw/17Q8EzIf8C98uSDyCVugNOxe55UQIXY8k2 LgYaV4r+CUQpIpWkhEhJLanBx0ghVipw1X/6ORFhgIi/u/BhWkqM6R8FKQp4nzCTl6mRRRPB EGRxvJNOj9fr8sp3r/1EXlfAD75Dw9GBZCwaTUTl0t6ZzIUZESkcE69JtvLkkhxlKv/A2lR+ PkK/AUOtLmUKZW5kc3RyZWFtCmVuZG9iago2OSAwIG9iago2NTUKZW5kb2JqCjM1IDAgb2Jq Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvTllUUVFJK0NNQlgxMn4yMy9Gb250 QkJveFsyMSAtMjAxIDgxMCA3MDBdL0ZsYWdzIDQKL0FzY2VudCA3MDAKL0NhcEhlaWdodCA3 MDAKL0Rlc2NlbnQgLTIwMQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTIxCi9NaXNzaW5nV2lk dGggMzc1Ci9DaGFyU2V0KC9wZXJpb2Qvb25lL3R3by90aHJlZS9mb3VyL2ZpdmUvQS9EL0Yv SS9QL1MvYS9iL2MvZC9lL2YvZy9oL2kvbC9uL28vci9zL3QvdS93L3kpCi9Gb250RmlsZTMg MzQgMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggNzAgMCBSPj5zdHJlYW0KeJydVmtYU1fWPodAzuHitT0qUz0HtVZH sYoyg/SrtYqiWLHgpaBcTCIIKBflpgHkogGSLAIGEeQeEDFClCIQvA1Sbe20tmptdebp1Gkf R+tMS7VTP1yHbr6n3w5q+33tv3l28uMk66y917vf912LZZydGJZlx63dtCE0NGhOQPCycJ8F uQsWOn70kl9g5clO8hSFhUQN9Q2FuHRNHnV1PJrH4YYx6DuWUbBs4JqIgJSd2tSEuPh0r1kB v/fy8ff381qaFJuasFWd7BWsTo+PTVKn04dEr/UpWxNi07Uvey1NTPRa53gjzWtdbFpsamZs zJONA1KSdmakx6Z6BafExKYmMwwjLtUmb6UPy7eFpMYFpsWnJ6zPCNqdqNb4/uFlH3pMZhqz mXmTWc6EMCuYQGYGs5LxYdYzq5iZzAYmiNnIrGZ8mbeY2Uw4E8wsYwIYgZnAjGHGM88xzzMS rZ1xZvJYBZvAXnWa41Sn4BTRivPOgvNOl1dcDir9lBbl15wP9xfem09yHeMa4PqO22y3bPcJ 7v7u+e6PPcpk99E/KUINXmDH+XZ5dSMrRw/5C7p6w4E0SAVDkU5LSoYfT9JlgyFFn6ovhgzg tSrlUdP7YIVW+AyaDbydy4BYSKksrQCTqawfJ0xCi/JDMt9lrkrZbhqATmiHf0MLDfTmyB05 W0CedLuQvcrRPzmF9jMk0iZ/ZGcBWYW8Xx4jmKvLDl4BmjXBUAwa2AkGWGfiVVzJWcjV6wuN eom4kgPkeTzuctGuTDOshBRIhhDYRYOucBg8PKMob29yUZ5nZvSOwBVQDHmQbzaVHK+CTt6W ZklKTMtMiOxVv3/7nZu9jeLoIRewy2429jqyGO04wzG8LHyjOU+cAoLjX08QjeikJIv3u6i4 D8ohRiKfBKq4ZtOncIyuJ+UHYgKHzN/6r7xtSVsiktbfBnCjZX1hhzyxg1bpgSvRTSHHo6tQ lQ8F2UZjXpGo27Nz1TzgyVRA79OXS3AiTiy/bCgyGo0Go6TX5+ZAKq8+kdVi6Tx89jbhzBtJ 4ArCE45M/mYezkSfNuTLRQrngnyG7vM728g+VeihkFsxRcAX5j0gPsTPdzqZQCben4s+6Hfn AY4XiYmECmQCoOvts/Cnhg6pqet0vR3ehY6ddSmNcRAGEfwioBsJDpwKbTQzbuwbSW6mUOHD oWXCM1yiuYyGLdZAWsS0lxYSLzL9wR/R8+LZBtspKYzDQLOLnQvWwSlJljnCDt8T1GvDc+No 9FjA5z6muzd1Sm2XLpuboRt6tbYtPK2GXdtf2IHrrfjak4L23VfI4bhLaDZDy3Hdraizkrpn /eFQmmT+H2eQ8cTrh/k4B+ecHqyryYHCbKM+t1DatTooM4JGzDDiC5ckq7Opu+SUpaOh/WST HR5DBfEo2US3UkQvf53SYMDODuJz8mScrOh0lDY4PDBVJftzuAFn4RjcjpnEG8eQEImE/M9E QR7A2dwd+CTh7TCrpmEzEAGIa05YfGR81KrtPkDTsmH9DFXWj3ZMs7E3H91FXoFJ8gwBlXbi /oPy0ce1tkqT0WAWcwr2ZUEmv7Vde7Spo6a3O65n+XyiiCW8OGOp6ib5cYRStyihrPAFHKGU 8uXooRnddZq9phP7R86NZ3GqAq34noCvKfG//vnVD8h4f0X8pWHvJ5UorabH0EHXY7DSHFM5 /J08IOA88F8ZBH5knkQk7KeqZK/s3flUFI9+cJw5BjMEWzkuRFdxb74uC7S8xpbV0mKr6+4L OxbxakKgei/ViUJJFv1aJ78+s4OhJKodF9y/1Y65J1i4jWmD5tsKnICrhXO7LkEN8Che/Osn fckdeYcka+2RsjqTvogaTy6fWb3n6NHqBssRbbtapcnUZoqaIzEV4fRyxQ2vrUg8pOlJkLL2 aOMhDlTN2yzZaYXB6bCOD/loFa7BV75859Y/Qq2pVWLEkTdgITW3LVBUoirP64QGOFhSU3mY R3ez4AvXz5yB63fuQGBUFAT6SpdIhPDZJ7lh8fGhZBKZFHep88qHUCPRSi5551P0rfRzjqI/ CRf2KIbchhYLw3cp2vdH0EYlvA39cBfO0/KJJ1ovct8e3LJM6sHjauWy/VvmiBvofU1X4kJo WVZNRvE9DvTP9TNUal7HWbiG2dcU8ih5idAA5TmFBtiXIxbr83VF+pTabWaqniQyG8iEaTg2 o61Iai2yFZZB176uVFDzr82HzPA1tQMpYmGjsSQL+EzQp0uE4/aArqbcBLWN4tGG0/HvQD14 XsRxVeh5bpdtd72kOZFg3njojco3K+Ec/9FdsKDCvCLVJJbkHoQq4C1Q2iw980yHF/zWNl/a vDzJQYfvlGTpz3QYfu8/ss2f2J4RR+PsuKSR/YLuNapHgXEOCb1oJy/ierXSOCti1iw9v/0L 0sZNvZ3+6c3eSzfFfnUYF5SUnPgmXG2mvsguynfoUO77Hl+knFZg2pBC6N7eFqNJTIiNbUvo PmVr6xbJchJE7ezy/6HvddrjjsGVEfoGy3M4WnmefYjrYuEefnZPgeXyGmFWk/5TqOb7bJcH Bu5EkokWsTQTjA1PscIQznF3Or2xYJ+o2pxq2XRqNniS6Ut8CLuqI7J6r3Qh7Fjho/SHGVWG pszDudYUCOdVma8S54VEOo4v7ReN9VC6+9n9hTy5v5KSikNiZWXF4ZaW96Ju575PRTP/48HB fwXfI2yL9MSr+V8uBwfltT8bdTi3JHrt4teLWy6K+C1HAn+RbAE382ry4yM34Qu7WPKKEpf+ YtrOjrtopmY9YpLojJMUeGxoooDOdmWcYSao6ZoJcbQFo/PwAHFWcR2mh9BD10PocJDfkUDh nc8UWWTBzg7FyKOE8rrS8vccjT7ZkEs1q4HckQRcxXnINYKxuECaRg4TDjtd3nX0+RA6CoTT YWATjbnMle4/kFu2r7TwUBoUgUGvM+qXkNBJhMEGR3Q6nQp2wg6IgKSRaJw7PK5cW6ZrAs9K SuODjYNYP2mQ1FZkOB49m6DUXF7PPyOKPNA3wpKkodXCbzl8g3KiFW78TFGnaV9RvaKmFX0d bUqBGoccVHhBuL/sAzJ1PXEr8lO3a1uPWy2dDbr6rErRVnGEmg5/rTvWX9rKkQVk4RaimI/8 7ut/Pd/T2yhtA9X3Yp/SchCaLPtgr7SmBGqhmSfsJWGun3bHZo3tzNfItH134P915euPsJJ2 fIz51am/7+HqGuoaahv73rqY3+Ww18EvcQZOmXuPTAmJ3LNDIx2IEE6eu1DfQ/8bC+S5oGhY l7ZNSoyILNgBK2Hbub1N/BPnphpSjkyJeMZR4wr0EQbss+WlyhZjWarWADl5IhkYftNFhW8T JWFVnNX0gLabE/AAWilas2nnl1MEcoPA01aQ13UDx+Fc2/foUtXIXjiDKQ5ivSzXCif2t9Je cITOIle72xounKb1H4CqPKMBigrEqOzN+ethHURURtbpTHqTHvg8KMiSSC+VR37jIVPJoYNi VXVH71fA34e5rwbAdDJm25rqdxOk/sNdTR27WrclbddG+n7uh+748sBdHIujF90hU7ZG7N+h kp7SgFoF/Spwz6cjVhGzPVGjsSWeGrGKZ3DIpfZeisZMdFHggyFOsBpgh7j0DaJwzMl7VA3K k9Bv7jrMDzcRScX1mP4bztI1CD0OSUx5CgKgG15Bzz7HDOyJIfi8QjbhDkGt1GfqQnIK9usW Qw5tcvOUne1f/6WmEhV/v9YH3/Lo5nWDtiSX2W94v2XPaW7rsJzpSbQkloldZ/rLLLTw3tcD Fr8VoFFJJInsLthHpaP1zJIX/Qz9KRRx/Mkv8fmeDrYNnTDYMT5U45dU1DA9IhqmEiYzqPRE hGSvqGmD43x3slWjTk5Wz3u4kQ5D/p9//fB86jdkXqv4j9Y/fwCf87cCPiQScfYPeWXTqeyj 1pMNZ5oLTkSWiz3d18AM/F0ITEoqjqJ825WwyxBryDPuNhYbCvWgg2I+ywx0Fs+rGlpWRcor cEujkkSVc3Y3ZN1FN2e/Rg/XExUeHsg2e4wq8RjNMP8Li0i52wplbmRzdHJlYW0KZW5kb2Jq CjcwIDAgb2JqCjMwMzEKZW5kb2JqCjUzIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvT1NHTUFLK0NNQlgxMC9Gb250QkJveFsyMSAtMjAxIDExNjQgNjk3XS9GbGFn cyA0Ci9Bc2NlbnQgNjk3Ci9DYXBIZWlnaHQgNjk3Ci9EZXNjZW50IC0yMDEKL0l0YWxpY0Fu Z2xlIDAKL1N0ZW1WIDE3NAovTWlzc2luZ1dpZHRoIDM4MwovQ2hhclNldCgvcGVyaW9kL29u ZS90d28vZml2ZS9EL1MvVy9hL2IvZS9nL2kvay9sL24vby9yL3QveSkKL0ZvbnRGaWxlMyA1 MiAwIFI+PgplbmRvYmoKNTIgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA3MSAwIFI+PnN0cmVhbQp4nHVWeVAUVxrvcWC6NQQNY4sY0g0JimeC SmJuFQQsAh4giDAgg8wCohzDiCIERxCdmW+GWwyCMBwRBIZREIQWL8qYGDeWySa7sbLZLZXU mmMrVDbma/LYdR8xSSW1tdV/dff33uvvd32tYFymMQqFwn1jdFjk2jeWBEcGxS0PmHriKz+p kL2nyU8p7STR28U6Eena7z29zgOznsCwmbhiFqNUKEIjEoKzcwr0GWnpBp+FwYt8lr/00iqf tbt1+owd2iyfSK0hXbdba6A3u3yis3dk6AwFz/qs3bXLJ2pqRZ5PlC5Pp8/XpT46Njh7d84e g07vE5mdqtNnMQyjLsjK1q3TpxkyojN3aVO2Pv/s8hUME89sZDYxocx8JppZz8Qw4UwgE8FE MkFMMPMiM4eZyXgwamY2bYxhmSPM94oNCmkaPy1fGamsUd53qXd9wTXTVVbls2q2j/2Ee4qr fKg4ELPJ/eG0pPFNROOU35EUgKxSLpfd+Or68uobwElsnnm3RQ96SLLlWzkNaxuCA5YjBy0W kbDEQtTY6npFUu00L7dYIJsWpdCiGyxunPQ1JOxJyAxbB15vgtlaWl5b0VoPvVxPXltGdta+ 1Dgp5d1P37l+9aRAzy++ZwQJx0fTnB63UIXJqPJUDw1JvIbtsL5rOwN9cM3cYeGkUNSxqLgz 8r7Dnr9aIK2h/1twjP0+ps9/SWxUXK6g/hQZlqwpddWw16shVSTXWXf5T2X9stpJG52N1Thb KfdhFo/znhsnq8iLAfOJF5l1zx9fwVfvjuNMgdSQCJ6oAZm7Q3Cx0SE2nR6wj8AADBS2pNsz YAskcIFAGKKeamPm7JyyfozowZcf7V/6lVJOodu3HIWTXWUfb7sg/sEZeyIUOBIY6EeeIPO+ XYzP44rBB40n9sHh/ebDhWVifkJUZjit8LWg10Wxx8XWZx2w97zd33+sE3A62IinNZ1zf6jM HWdAksckBTLoLXuivxL9J9T85BhhNHIwi9twMc7EnZhDFiNP4sXJII0KTZNjvDyGC9gP4G/7 RkJ642rC4FkgigOxmUkJYSsLNwDdWnG7oZKy8RY+s2WU0sE8QHdPiuSVOVIgBrMftqP7t4LF UlAIWVxK997Ozm57/+WYzq0hO7ZFGAT1ELqy5OXfQE456rUO2YbhDNwAp4mjDJBEJy79+iMn Gs56wJchqMR1qIR7IXc81T8YsQaj+JVwc2gIbt67B+uTkmD9SpG4H+SH8y6a24FDv9HbH0r6 nqIG8VSD3VZnNR82l0AZp28sePvtxqa21v29iUUaU/p2oeCY1r6WYum35bWQlOaUboOYnV62 E/KhqCK+P5NTTzDFpqD8iHlxo2tQgyG3r314qvT99Q4humMjLIFcSITD1u3VxjNwAo5WHK+q 4a6TGB6nq7rQFSLTUmPIHOIWPzz87vtQL1LcLq26Rel/KOHqZsXnVMYzJCXuln15XCCRBRit UVn84xcuNHFpn5OTrM/dPR/9Zejqx8JlTRwblpmXvRlutFIRKVbnXv7JC2MY4NGFAWQGMp7q +2iQY3kSNIXrtV9x7bKO2AbgFFw0O6n2I1n1+FH5Jn8uzaFNTk9PTu5NHxxwOs79bDCjJP9n 0AOGE7/BW9+8PuSp/lheIK/gyfyuHbXRDnjPa7Dj+refjWcQ71ahIg/MduDaoLJVxDfYJqgt KLVYDhqFpO2bh8NrE8CLLA1e8nR4T6J9jzgS7ziEijxOff/evkZTS/7xonYKHZeQG/rMarK0 GReVCpYTULkHuDwoM4gknN0HJSdqbbbqGmF4+IP4+2VnwQtfuo6u46h8+a8BTeKjRKIofCfh VqrB7/weYaDDIL6ztaaqud6hdWh7tLUHGvaCiSspgGJBw56y3bVWghMcFoeZk/azyWCqKG4g r2HaXJwzXl9XW30TvCQ2x6Sn1OZAuM0wlWetUG6qKSWbyaK5ciJLQn5V7uQFimeoRnXaKtmc cBrO/wRyKPsLRfLYqIK6Q4mGiXD+d+soM93W87ZBGIRhs+PnRdOecz1d5twt4cZTuMzpQb38 Oj6BgVNJly/P+JTfBYn/Es6rmo9BW2sxFIsbrPAWtHKYyY6t+yNZFEXcj6zc3rvvZFe3feAU xdkmdFR1W48B9+de7Woxg1VL60ykuoTMn7cEZxXc+kw6O9Ai7Mfl/FJ2yXPF+rgdvedoUqyo v1D+sx7ox9jlp5y4+SeTE4YKthJne6r34055Po/Dv8PiG4ltaGo80dDEqQdLa0Zixp7ERd99 gSJ6LfuSzA/alrU3T6wiozxWsCd7z3eOUpe6A3k8RANbclPFrJREYyaEQOqVg8dpwLi031lT ap9Q0Wnj7WJQ/nhFJnxVo9XWVd5ss0PD1NDJsaSbk0AHkZBWTklqh/PQaSRrJqPnkhA5yfVr SaUzLYNkSIVXIZ1W3GHP+hJv8v3/e4uH/q2oKqw42A5e7VBxtKoBg+TYuRg0Gfu7p1PhZBx8 D73Rz/kFzqIszXvxMg3Rp2kwyfWYyCP76n2yMCvWlKkRcC7bcbjO7KC9LvgHurZXm+sOmCxw xChG7YktS4bVENuUW1tSbrGagHsTjIUiGWKpVFveslXUVAt9w1eOngVuDFa+Iqp/DAJ/4pYX UXlVKzhtnW1wlrucfDyvaGvJhhduv4CzMPCfX6D7L/GAAXS8BCjx4G1+ML03+RezD/b2Dgq0 A6rNMulcs4JOgMeU+MOEkm+Bo7lGMxwqEV6P8qP5x+3VNKsaYNR6rYmbrCeihj1X/gBG6PUA zpk4ifhMDUqgAr2Kvmem/gr8MBQFJcVAz2tUpr0lb7x5yFi2BgppuvqrpL5Lg0M9qPr7DQm+ 4pB95hPiSx5fFrl80/mitu7+lguXtA1FFUJn25k6J3B3hsPWhOrCQtaJJJFoiw+AGfZ6Fchr WXdj3URQHamqxSS7iiRWs9IMVD0mzHBZ1ew2vb/azQ1VHW6PW93cGea/Pv+lfgplbmRzdHJl YW0KZW5kb2JqCjcxIDAgb2JqCjIyMzEKZW5kb2JqCjUwIDAgb2JqCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvTFZMTEhPK0NNU1k1L0ZvbnRCQm94WzAgMCA1OTcgNDY1XS9G bGFncyA1Ci9Bc2NlbnQgNDY1Ci9DYXBIZWlnaHQgNDY1Ci9EZXNjZW50IDAKL0l0YWxpY0Fu Z2xlIDAKL1N0ZW1WIDg5Ci9BdmdXaWR0aCA3MzUKL01heFdpZHRoIDczNQovTWlzc2luZ1dp ZHRoIDczNQovQ2hhclNldCgvYXN0ZXJpc2ttYXRoKQovRm9udEZpbGUzIDQ5IDAgUj4+CmVu ZG9iago0OSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxQy9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDcyIDAgUj4+c3RyZWFtCnicY2RgYWJgZGTk9Qnz8fHw13b2DY40BQko/pBm/CHD9EOW ubv7x8sfqaw9PIxzv/8R+u4u+N2F/7utAAMLI6Obd1Sac35BZVFmekaJgoazpoKhpaW5gmNu alFmcmKegm9iSUZqbmIJkJOjEJyfnJlaUqmn4JiToxAE0lGsEJRanFpUlpoCttY5P7egtCS1 SME3PyW1KC+xGMjOLM4G6s9gYGhgZGZcwtjFAERMjIxMG/j+Mz2QE1i74IfUfMbvAdeZf4h+ XyHaO3/2d5HuKRxza2aWl9VW1zTO+i3cVyb32+Bl3eTW7o5uydryuuLS6W2r6+VPl3R33c73 KjLOaWhr7qhu7S7lKJ5fN3NSb/esJXILZ25cdH9vR1nNb+HuRo6amdUL5s+aOXdK9XeRzvly F5LuRU5sn9ze3zG5m2Pm/BmLF9ZPyJ4u772ou8d6+Zklj1dNmzC5b/bE7oUci8tn1Ha0djfX yfEVL/5pv5Dtt/h09sNcH7gPz+DhYWAAAGlxm9sKZW5kc3RyZWFtCmVuZG9iago3MiAwIG9i agozODgKZW5kb2JqCjQ3IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv Q0dWVkRQK0NNTUk1L0ZvbnRCQm94Wzg0IC0xMSA2NjggNjk0XS9GbGFncyA0Ci9Bc2NlbnQg Njk0Ci9DYXBIZWlnaHQgNjk0Ci9EZXNjZW50IC0xMQovSXRhbGljQW5nbGUgMAovU3RlbVYg MTAwCi9NaXNzaW5nV2lkdGggMzMzCi9DaGFyU2V0KC9rL3QpCi9Gb250RmlsZTMgNDYgMCBS Pj4KZW5kb2JqCjQ2IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggNzMgMCBSPj5zdHJlYW0KeJwdjlFIE3Ecx/+3rXnp1AwMRTsP6qGIIokKXwo7 SSyHZmhRGax5OXV6Y5uFt6Uz3e1uv9NtaK7znFPBQltohiXhQ5jRQxAU9FpR+By9+L9xgZ09 fr98P3w/BLKYEEEQ+UxtS0tN4zHGbq87vVtQWhmhlZu0g+bvoezJ7KU9z7T1/fhMEa4sxMf3 ITNBXLx8g+E8fd6OdpefPsIcpSurqs7S1d2st8Pp6KHtDr+L7Xb4jeCmr3LODtbfd4Kudrvp pl3CRzexPtZ7j237f8lw3Z5eP+ul7Vwb6+1BCJn8XQg1o3pkNgRRDhongjuEvbmxYMd0anEm lNGI15hJE19+mPEn7UAxzrXOgCzHY/HY6GNIkFNB4CndZJ35lphPrkGidKo/5eN9Ic8QJfDJ N7f0BlLPs94PAscrkKrAZqtbL4Aop1uE3iE3DJBNb52fcf5XXJZWeIgEpEi/QHUy9tZrQHYN zi2o8ujIeIUhs13uCWXw7cUXv9UMvv6OwCs/P2ybNUv2cHFMgRGIg6ESiOqFD0v4qBQVIhFB HIAwyaugyCmQJqlpSRZhCESQhD6d+rteEgmCZCz8qf70yviyEqPWcP18FBcNQ00pDENEHBAf QNhY1Hxsf//nJT6U3FXkDVygBl0955qBvCssz8qgxKYqYqr8CMbgl26arIs/VVefq8rm2sar TZiDRDgRjoIgStAagDsgknzSl0mvqhvr7MLN2iutjRcoF9fpdQbIgt7Z7PlZ/cnExIRVdyg5 S7lbeVSupcG2d2nMZtuy5SP0D7JU/04KZW5kc3RyZWFtCmVuZG9iago3MyAwIG9iago1OTMK ZW5kb2JqCjMxIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvTVhMT0JLK0NNVEkx MC9UeXBlL0ZvbnQvTmFtZS9SMzEvRm9udERlc2NyaXB0b3IgMzAgMCBSL0ZpcnN0Q2hhciA5 Ny9MYXN0Q2hhciAxMjEvV2lkdGhzWyA1MTEgNDU5IDQ1OSA1MTEgNDU5IDMwNiA0NTkgNTEx IDMwNiAzNTcgNDU5IDI1NSA4MTcgNTYxIDUxMQo1MTEgMzU3IDQyMSA0MDkgMzMyIDUzNiAz NTcgNjY0IDQ2NCA0ODVdCj4+CmVuZG9iagoyOCAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jh c2VGb250L1hQTk5ZSStDTVNZNy9UeXBlL0ZvbnQvTmFtZS9SMjgvRm9udERlc2NyaXB0b3Ig MjcgMCBSL0ZpcnN0Q2hhciAzL0xhc3RDaGFyIDE2NC9XaWR0aHNbIDU4NSAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMzI5IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgNTg1XQo+PgplbmRv YmoKMjUgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9CTk1KRkorQ01UVDEwL1R5 cGUvRm9udC9OYW1lL1IyNS9Gb250RGVzY3JpcHRvciAyNCAwIFIvRmlyc3RDaGFyIDY1L0xh c3RDaGFyIDg2L1dpZHRoc1sgNTI0IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjQg NTI1IDUyNSA1MjUgNTI0IDUyNSA1MjUKNTI0IDUyNSA1MjQgNTI0IDUyNSA1MjUgNTI0XQo+ PgplbmRvYmoKMjIgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9XUEhHWEwrQ01N STEwL1R5cGUvRm9udC9OYW1lL1IyMi9Gb250RGVzY3JpcHRvciAyMSAwIFIvRmlyc3RDaGFy IDMwL0xhc3RDaGFyIDE5My9XaWR0aHNbIDU5NiAzMzMKMzMzIDMzMyAzMzMgMzMzIDMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzCjMzMyAzMzMgMzMz IDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMjc3IDc3NyAzMzMgMzMzIDMzMwoz MzMgNzQ5IDc1OCAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgNTU0IDg0OSAzMzMgOTcw IDMzMyAzMzMKMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyA4MjggNTgwIDMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzCjMzMyAzMzMgMzMzIDQzMiAzMzMgNDY1IDMzMyAzMzMgMzMz IDMzMyAzMzMgMzMzIDMzMyA4NzggMzMzIDMzMwo1MDMgMzMzIDQ1MCAzMzMgMzYxIDMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMKMzMzIDMzMyAzMzMgMzMz IDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzCjMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMz IDMzMwozMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAz MzMgMzMzIDMzMyAzMzMKMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMz IDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzCjMzMyA1OTZdCj4+CmVuZG9iagoxOSAwIG9iago8 PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L0NPUklSTytDTVIxMC9UeXBlL0ZvbnQvTmFtZS9S MTkvRm9udERlc2NyaXB0b3IgMTggMCBSL0ZpcnN0Q2hhciAxMS9MYXN0Q2hhciAxNzYvV2lk dGhzWyA1ODMgNTU1IDU1NSAzMzMgMzMzCjMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAz MzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMwozMzMgMzMzIDMzMyAzMzMgMzMz IDMzMyAzMzMgMjc3IDM4OCAzODggMzMzIDc3NyAyNzcgMzMzIDI3NyAzMzMKMzMzIDQ5OSA0 OTkgNDk5IDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAyNzcgMzMzIDc3NyAzMzMgMzMz CjMzMyA3NDkgNzA4IDcyMSA3NjQgNjgwIDY1MyA3ODUgNzQ5IDM2MSA1MTQgMzMzIDMzMyA5 MTYgMzMzIDc3Nwo2ODAgMzMzIDczNiA1NTUgNzIxIDMzMyAzMzMgMTAyOCAzMzMgMzMzIDMz MyAzMzMgMzMzIDMzMyAzMzMgMzMzCjMzMyA0OTkgNTU1IDQ0NCA1NTUgNDQ0IDMwNSA0OTkg NTU1IDI3NyAzMDUgNTI3IDI3NyA4MzIgNTU1IDQ5OQo1NTUgNTI3IDM5MiAzOTQgMzg4IDU1 NSA1MjcgNzIxIDUyNyA1MjcgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMKMzMzIDMzMyAzMzMg MzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzCjMz MyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg MzMzIDMzMwozMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMz MyAzMzMgMzMzIDU4MyA1NTUKNTU1XQo+PgplbmRvYmoKMTYgMCBvYmoKPDwvU3VidHlwZS9U eXBlMS9CYXNlRm9udC9NQVJJREorQ01CWDEyL1R5cGUvRm9udC9OYW1lL1IxNi9Gb250RGVz Y3JpcHRvciAxNSAwIFIvRmlyc3RDaGFyIDQ2L0xhc3RDaGFyIDEyMS9XaWR0aHNbIDMxMiAz NzUKMzc1IDU2MiA1NjIgNTYyIDU2MiA1NjIgMzc1IDM3NSAzNzUgMzc1IDM3NSAzNzUgMzc1 IDM3NSAzNzUgMzc1CjM3NSA4NDkgMzc1IDM3NSA4NjIgMzc1IDcwNyAzNzUgMzc1IDQxOSAz NzUgMzc1IDM3NSAzNzUgMzc1IDM3NQo3NjggMzc1IDM3NSA2MjQgMzc1IDM3NSAzNzUgMzc1 IDM3NSAzNzUgMzc1IDM3NSAzNzUgMzc1IDM3NSAzNzUKMzc1IDU0NiA2MjUgNDk5IDYyNCA1 MTMgMzQzIDU2MiA2MjUgMzEyIDM3NSAzNzUgMzEyIDM3NSA2MjQgNTYyCjYyNCAzNzUgNDU5 IDQ0MyA0MzcgNjI0IDM3NSA4MTIgMzc1IDU5M10KPj4KZW5kb2JqCjEzIDAgb2JqCjw8L1N1 YnR5cGUvVHlwZTEvQmFzZUZvbnQvWU5OTkZXK0NNUjEyL1R5cGUvRm9udC9OYW1lL1IxMy9G b250RGVzY3JpcHRvciAxMiAwIFIvRmlyc3RDaGFyIDQ0L0xhc3RDaGFyIDEyMS9XaWR0aHNb IDI3MSAzMjYgMzI2IDMyNgo0ODkgNDg5IDQ4OSA0ODkgMzI2IDMyNiA0ODkgMzI2IDMyNiAz MjYgMzI2IDMyNiAzMjYgMzI2IDMyNiAzMjYKMzI2IDczMyA2OTMgMzI2IDMyNiAzMjYgNjM5 IDMyNiAzMjYgMzI2IDUwMiAzMjYgMzI2IDg5NyAzMjYgMzI2CjMyNiAzMjYgMzI2IDMyNiAz MjYgMzI2IDMyNiAzMjYgMzI2IDMyNiAzMjYgMzI2IDMyNiAzMjYgMzI2IDMyNgozMjYgNDg5 IDU0NCAzMjYgNTQ0IDQzNSAzMjYgMzI2IDMyNiAyNzEgMzI2IDMyNiAzMjYgMzI2IDU0NCA0 ODkKMzI2IDMyNiAzODAgMzg2IDMyNiA1NDQgMzI2IDcwNiAzMjYgNTE2XQo+PgplbmRvYmoK MTAgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9IVFdOUVQrQ01SMTcvVHlwZS9G b250L05hbWUvUjEwL0ZvbnREZXNjcmlwdG9yIDkgMCBSL0ZpcnN0Q2hhciA3OS9MYXN0Q2hh ciAxMTYvV2lkdGhzWyA3MTkKNjI4IDMwMSA2ODAgMzAxIDY2NyAzMDEgMzAxIDMwMSAzMDEg MzAxIDMwMSAzMDEgMzAxIDMwMSAzMDEgMzAxCjMwMSAzMDEgMzAxIDMwMSAzMDEgNDA2IDMw MSAzMDEgMzAxIDI0OSAzMDEgMzAxIDMwMSAzMDEgMzAxIDQ1OAo1MTAgMzAxIDM1MyAzNTkg MzUzXQo+PgplbmRvYmoKNTQgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9PU0dN QUsrQ01CWDEwL1R5cGUvRm9udC9OYW1lL1I1NC9Gb250RGVzY3JpcHRvciA1MyAwIFIvRmly c3RDaGFyIDQ2L0xhc3RDaGFyIDEyMS9XaWR0aHNbIDMxOSAzODMKMzgzIDU3NCA1NzQgMzgz IDM4MyA1NzQgMzgzIDM4MyAzODMgMzgzIDM4MyAzODMgMzgzIDM4MyAzODMgMzgzCjM4MyAz ODMgMzgzIDM4MyA4ODEgMzgzIDM4MyAzODMgMzgzIDM4MyAzODMgMzgzIDM4MyAzODMgMzgz IDM4MwozODMgMzgzIDM4MyA2MzggMzgzIDM4MyAzODMgMTE4OCAzODMgMzgzIDM4MyAzODMg MzgzIDM4MyAzODMgMzgzCjM4MyA1NTkgNjM4IDM4MyAzODMgNTI2IDM4MyA1NzQgMzgzIDMx OSAzODMgNjA3IDMxOSAzODMgNjM4IDU3NAozODMgMzgzIDQ3MyAzODMgNDQ3IDM4MyAzODMg MzgzIDM4MyA2MDddCj4+CmVuZG9iago1MSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VG b250L0xWTExITytDTVNZNS9UeXBlL0ZvbnQvTmFtZS9SNTEvRm9udERlc2NyaXB0b3IgNTAg MCBSL0ZpcnN0Q2hhciAzL0xhc3RDaGFyIDE2NC9XaWR0aHNbIDczNSAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAow IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDczNV0KPj4KZW5kb2JqCjQ4 IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvQ0dWVkRQK0NNTUk1L1R5cGUvRm9u dC9OYW1lL1I0OC9Gb250RGVzY3JpcHRvciA0NyAwIFIvRmlyc3RDaGFyIDEwNy9MYXN0Q2hh ciAxMTYvV2lkdGhzWyA3NTggMzMzIDMzMyAzMzMgMzMzCjMzMyAzMzMgMzMzIDMzMyA1NjNd Cj4+CmVuZG9iago0NSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L01NSk9PWStD TU1JNy9UeXBlL0ZvbnQvTmFtZS9SNDUvRm9udERlc2NyaXB0b3IgNDQgMCBSL0ZpcnN0Q2hh ciA1OS9MYXN0Q2hhciAxMTYvV2lkdGhzWyAzMzkgMzMzIDMzMyAzMzMgMzMzCjMzMyA4NTkg ODYzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMz MwozMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMg MzMzIDMzMyAzMzMKMzMzIDMzMyAzMzMgNTExIDMzMyA1NDIgMzMzIDMzMyAzMzMgMzMzIDMz MyA2MDcgMzMzIDEwMTQgMzMzIDMzMwo1ODggMzMzIDMzMyAzMzMgNDMxXQo+PgplbmRvYmoK NDIgMCBvYmoKPDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9TWlFNTVcrQ01TWTEwL1R5cGUv Rm9udC9OYW1lL1I0Mi9Gb250RGVzY3JpcHRvciA0MSAwIFIvRmlyc3RDaGFyIDUwL0xhc3RD aGFyIDEwMy9XaWR0aHNbIDY2NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCAwIDAgMCA0OTkgNDk5XQo+PgplbmRvYmoKMzYgMCBvYmoKPDwvU3VidHlwZS9U eXBlMS9CYXNlRm9udC9OWVRRUUkrQ01CWDEyfjIzL1R5cGUvRm9udC9OYW1lL1IzNi9Gb250 RGVzY3JpcHRvciAzNSAwIFIvRmlyc3RDaGFyIDQ2L0xhc3RDaGFyIDEyMS9XaWR0aHNbIDMx MiAzNzUKMzc1IDU2MiA1NjIgNTYyIDU2MiA1NjIgMzc1IDM3NSAzNzUgMzc1IDM3NSAzNzUg Mzc1IDM3NSAzNzUgMzc1CjM3NSA4NDkgMzc1IDM3NSA4NjEgMzc1IDcwNiAzNzUgMzc1IDQx OSAzNzUgMzc1IDM3NSAzNzUgMzc1IDM3NQo3NjggMzc1IDM3NSA2MjQgMzc1IDM3NSAzNzUg Mzc1IDM3NSAzNzUgMzc1IDM3NSAzNzUgMzc1IDM3NSAzNzUKMzc1IDU0NiA2MjQgNDk5IDYy NCA1MTMgMzQ0IDU2MiA2MjQgMzEyIDM3NSAzNzUgMzEyIDM3NSA2MjQgNTYyCjYyNSAzNzUg NDU5IDQ0MyA0MzcgNjI0IDM3NSA4MTIgMzc1IDU5M10KPj4KZW5kb2JqCjIgMCBvYmoKPDwv UHJvZHVjZXIoRVNQIEdob3N0c2NyaXB0IDcuMDcpPj5lbmRvYmoKeHJlZgowIDc0CjAwMDAw MDAwMDAgNjU1MzUgZiAKMDAwMDAwOTkxMSAwMDAwMCBuIAowMDAwMDQ4MDQ5IDAwMDAwIG4g CjAwMDAwMDk4MzggMDAwMDAgbiAKMDAwMDAwOTk1OSAwMDAwMCBuIAowMDAwMDA5MzkwIDAw MDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMzQ0OSAwMDAwMCBuIAowMDAwMDEz Njk4IDAwMDAwIG4gCjAwMDAwMTM0NjcgMDAwMDAgbiAKMDAwMDA0NTYzMCAwMDAwMCBuIAow MDAwMDEwNjM3IDAwMDAwIG4gCjAwMDAwMTAzNjMgMDAwMDAgbiAKMDAwMDA0NTE4NCAwMDAw MCBuIAowMDAwMDI0NjEyIDAwMDAwIG4gCjAwMDAwMjQzNjIgMDAwMDAgbiAKMDAwMDA0NDc0 NSAwMDAwMCBuIAowMDAwMDE4NDQ3IDAwMDAwIG4gCjAwMDAwMTgwNTQgMDAwMDAgbiAKMDAw MDA0Mzk0NiAwMDAwMCBuIAowMDAwMDE1NDQyIDAwMDAwIG4gCjAwMDAwMTUxODcgMDAwMDAg biAKMDAwMDA0MzE1NSAwMDAwMCBuIAowMDAwMDMwNjAyIDAwMDAwIG4gCjAwMDAwMzAzNzkg MDAwMDAgbiAKMDAwMDA0MjkzMyAwMDAwMCBuIAowMDAwMDI5ODM2IDAwMDAwIG4gCjAwMDAw Mjk2MzIgMDAwMDAgbiAKMDAwMDA0MjQ3MCAwMDAwMCBuIAowMDAwMDI2Nzg2IDAwMDAwIG4g CjAwMDAwMjY1MjkgMDAwMDAgbiAKMDAwMDA0MjIzNSAwMDAwMCBuIAowMDAwMDEwMDI4IDAw MDAwIG4gCjAwMDAwMTAwNTggMDAwMDAgbiAKMDAwMDAzNDg0NiAwMDAwMCBuIAowMDAwMDM0 NTUyIDAwMDAwIG4gCjAwMDAwNDc2MDcgMDAwMDAgbiAKMDAwMDAwOTU1MCAwMDAwMCBuIAow MDAwMDAzNDY5IDAwMDAwIG4gCjAwMDAwMDgyOTkgMDAwMDAgbiAKMDAwMDAzMzc5MSAwMDAw MCBuIAowMDAwMDMzNTU2IDAwMDAwIG4gCjAwMDAwNDczNTggMDAwMDAgbiAKMDAwMDAzMTkz NCAwMDAwMCBuIAowMDAwMDMxNzAxIDAwMDAwIG4gCjAwMDAwNDY5OTEgMDAwMDAgbiAKMDAw MDA0MTUzNiAwMDAwMCBuIAowMDAwMDQxMzIzIDAwMDAwIG4gCjAwMDAwNDY4MTYgMDAwMDAg biAKMDAwMDA0MDgyOSAwMDAwMCBuIAowMDAwMDQwNTg1IDAwMDAwIG4gCjAwMDAwNDYzNTUg MDAwMDAgbiAKMDAwMDAzODI0NyAwMDAwMCBuIAowMDAwMDM3OTg0IDAwMDAwIG4gCjAwMDAw NDU5MTUgMDAwMDAgbiAKMDAwMDAxMDE2NyAwMDAwMCBuIAowMDAwMDA5Njk0IDAwMDAwIG4g CjAwMDAwMDgzMjAgMDAwMDAgbiAKMDAwMDAwOTM3MCAwMDAwMCBuIAowMDAwMDEwMjk4IDAw MDAwIG4gCjAwMDAwMTM0NDYgMDAwMDAgbiAKMDAwMDAxNTE2NiAwMDAwMCBuIAowMDAwMDE4 MDMzIDAwMDAwIG4gCjAwMDAwMjQzNDEgMDAwMDAgbiAKMDAwMDAyNjUwOCAwMDAwMCBuIAow MDAwMDI5NjExIDAwMDAwIG4gCjAwMDAwMzAzNTkgMDAwMDAgbiAKMDAwMDAzMTY4MSAwMDAw MCBuIAowMDAwMDMzNTM1IDAwMDAwIG4gCjAwMDAwMzQ1MzIgMDAwMDAgbiAKMDAwMDAzNzk2 MyAwMDAwMCBuIAowMDAwMDQwNTY0IDAwMDAwIG4gCjAwMDAwNDEzMDMgMDAwMDAgbiAKMDAw MDA0MjIxNSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDc0IC9Sb290IDEgMCBSIC9JbmZv IDIgMCBSCj4+CnN0YXJ0eHJlZgo0ODA5OQolJUVPRgo= --PEIAKu/WMn1b1Hv9-- --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFD8Tq+F3ck4uEX/ycRAmxaAJoDD5og010xG0GLwWPNcI8WRCX6rQCgmy6k 9XY+vxw4uRWslxoB/Av83r8= =RhLF -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From ian@cypherpunks.ca Tue Feb 14 19:56:49 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 14 Feb 2006 14:56:49 -0500 Subject: [OTR-dev] OTR Formal Analysis Security Properties In-Reply-To: <20060214020446.GA4865@xenon.Stanford.EDU> References: <20060214020446.GA4865@xenon.Stanford.EDU> Message-ID: <20060214195649.GZ31096@smtp.paip.net> On Mon, Feb 13, 2006 at 06:04:46PM -0800, Andrew S. Morrison wrote: > As mentioned awhile back, myself and a partner are working on a formal > security analysis of OTR. Before we try to break it, I just wanted to send > you what we're working on in terms of what security properties OTR claims > to see if we're in agreement. Attached is a PDF of our working definitions > for the properties that should hold on OTR. Do you guys agree or disagree > on any of the definitions? Is anything missing? Are any of the claims too > strong or weak? Thanks. I took a quick look. In the PFS definition, Mallory *is* allowed to be able to read _very recent_ messages sent between Alice and Bob (i.e. messages sent with keys Alice and/or Bob are still using). So just saying Mallory cannot read messages with timestamp t' < t isn't quite right, I think. And a tiny nit, but I think you mean "principal" where you write "principle". ;-) Otherwise, it looks pretty plausible. I look forward to seeing the results of your work! - Ian From twanfox@gmail.com Wed Feb 15 19:15:03 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 13:15:03 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 Message-ID: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> ------=_Part_12652_10155541.1140030903900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Greetings, New to this list but using Trillian for a while, I have been getting a little antsy about not being able to encrypt messages across multiple IM clients. Having originally intended to use another encryption protocol to d= o this (already supported on Gaim), I find myself redirected to use OTR for various reasons. At any rate, my whole goal is to craft up a plugin which impliments OTR encryption for Trillian (latest version being 3.1). I come across lacking a few things, though. Due to the basics of plugin development for Trillian having been designed i= n Visual Studio (it seems), that is likely the tool under which I am going to develop the plugin. However, obtaining or building a VS-usable library for libotr seems to be quite an excersize (for me, especially). I understand that, at least in the case of Libgcrypt, .dll files have been built, but I have yet to come across a dynamic (or static) library of libotr available for Windows development. To me, ideally, I would like to build libotr as a statically linked library within the plugin, to make it simple on placing the final plugin within Trillian, but I haven't a notion where to begin in porting the build environment over. Any assistance is gladly appreciated. Thanks ------=_Part_12652_10155541.1140030903900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Greetings,
 
New to this list but using Trillian for a while, I have been getting a= little antsy about not being able to encrypt messages across multiple IM c= lients. Having originally intended to use another encryption protocol to do= this (already supported on Gaim), I find myself redirected to use OTR for = various reasons. At any rate, my whole goal is to craft up a plugin which i= mpliments OTR encryption for Trillian (latest version being=20 3.1). I come across lacking a few things, though.
 
Due to the basics of plugin development for Trillian having been desig= ned in Visual Studio (it seems), that is likely the tool under which I am g= oing to develop the plugin. However, obtaining or building a VS-usable libr= ary for libotr seems to be quite an excersize (for me, especially). I under= stand that, at least in the case of Libgcrypt, .dll files have been built, = but I have yet to come across a dynamic (or static) library of libotr = available for Windows development. To me, ideally, I would like to build li= botr as a statically linked library within the plugin, to make it simple on= placing the final plugin within Trillian, but I haven't a notion= where to begin in porting the build environment over.=20
 
Any assistance is gladly appreciated.
 
Thanks
------=_Part_12652_10155541.1140030903900-- From ian@cypherpunks.ca Wed Feb 15 19:25:56 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Feb 2006 14:25:56 -0500 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> Message-ID: <20060215192556.GL31096@smtp.paip.net> On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > Greetings, > > New to this list but using Trillian for a while, I have been getting a > little antsy about not being able to encrypt messages across multiple IM > clients. Having originally intended to use another encryption protocol to do > this (already supported on Gaim), I find myself redirected to use OTR for > various reasons. At any rate, my whole goal is to craft up a plugin which > impliments OTR encryption for Trillian (latest version being 3.1). I come > across lacking a few things, though. > > Due to the basics of plugin development for Trillian having been designed in > Visual Studio (it seems), that is likely the tool under which I am going to > develop the plugin. However, obtaining or building a VS-usable library for > libotr seems to be quite an excersize (for me, especially). I understand > that, at least in the case of Libgcrypt, .dll files have been built, but I > have yet to come across a dynamic (or static) library of libotr available > for Windows development. To me, ideally, I would like to build libotr as a > statically linked library within the plugin, to make it simple on > placing the final plugin within Trillian, but I haven't a notion where to > begin in porting the build environment over. > > Any assistance is gladly appreciated. Francesco "s0rr0w" Picasso reported he'd done this: http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html - Ian From twanfox@gmail.com Wed Feb 15 19:45:58 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 13:45:58 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <20060215192556.GL31096@smtp.paip.net> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> Message-ID: <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> ------=_Part_13116_18745500.1140032758027 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I had attempted to use that visual studio environment, but when I tried, it was a little less than intuitive to set up, and the build attempt I made wa= s all horktified (ie: it be broke). I've been using Visual Studio .NET 2003 and the environments given were at best Visual Studio 6. If there is more documentation on how to use that environment, I'm more than willing to use an already set up project to kick this thing off. I suppose I can tinker with it more. Also just contemplating building the environment from scratch in VS.NET 2k3 for sanity sake, if I can figure out what must be done for it= . On 2/15/06, Ian Goldberg wrote: > > On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > > Greetings, > > > > New to this list but using Trillian for a while, I have been getting a > > little antsy about not being able to encrypt messages across multiple I= M > > clients. Having originally intended to use another encryption protocol > to do > > this (already supported on Gaim), I find myself redirected to use OTR > for > > various reasons. At any rate, my whole goal is to craft up a plugin > which > > impliments OTR encryption for Trillian (latest version being 3.1). I > come > > across lacking a few things, though. > > > > Due to the basics of plugin development for Trillian having been > designed in > > Visual Studio (it seems), that is likely the tool under which I am goin= g > to > > develop the plugin. However, obtaining or building a VS-usable library > for > > libotr seems to be quite an excersize (for me, especially). I understan= d > > that, at least in the case of Libgcrypt, .dll files have been built, bu= t > I > > have yet to come across a dynamic (or static) library of libotr > available > > for Windows development. To me, ideally, I would like to build libotr a= s > a > > statically linked library within the plugin, to make it simple on > > placing the final plugin within Trillian, but I haven't a notion where > to > > begin in porting the build environment over. > > > > Any assistance is gladly appreciated. > > Francesco "s0rr0w" Picasso reported he'd done this: > > http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > ------=_Part_13116_18745500.1140032758027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I had attempted to use that visual studio environment, but when I tried, it= was a little less than intuitive to set up, and the build attempt I made w= as all horktified (ie: it be broke). I've been using Visual Studio .NET 200= 3 and the environments given were at best Visual Studio 6. If there is more= documentation on how to use that environment, I'm more than willing to use= an already set up project to kick this thing off. I suppose I can tinker w= ith it more. Also just contemplating building the environment from scratch = in=20 VS.NET 2k3 for sanity sake, if I can figure o= ut what must be done for it.

On 2/15/06, = Ian Goldberg <ian@cypherpunks.= ca> wrote:
On Wed, Feb 15, 2006 at 01:15:03= PM -0600, Twan Fox wrote:
> Greetings,
>
> New to this li= st but using Trillian for a while, I have been getting a
> little antsy about not being able to encrypt messages across multi= ple IM
> clients. Having originally intended to use another encryptio= n protocol to do
> this (already supported on Gaim), I find myself re= directed to use OTR for
> various reasons. At any rate, my whole goal is to craft up a plugi= n which
> impliments OTR encryption for Trillian (latest version bein= g 3.1). I come
> across lacking a few things, though.
>
> Due to the basics of plugin development for Trillian having been desig= ned in
> Visual Studio (it seems), that is likely the tool under whic= h I am going to
> develop the plugin. However, obtaining or building = a VS-usable library for
> libotr seems to be quite an excersize (for me, especially). I unde= rstand
> that, at least in the case of Libgcrypt, .dll files have bee= n built, but I
> have yet to come across a dynamic (or static) librar= y of libotr available
> for Windows development. To me, ideally, I would like to build lib= otr as a
> statically linked library within the plugin, to make it si= mple on
> placing the final plugin within Trillian, but I haven't a n= otion where to
> begin in porting the build environment over.
>
> Any a= ssistance is gladly appreciated.

Francesco "s0rr0w" Picass= o reported he'd done this:

http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html<= br>
  - Ian
_______________________________________________=
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
ht= tp://lists.cypherpunks.ca/mailman/listinfo/otr-dev

------=_Part_13116_18745500.1140032758027-- From twanfox@gmail.com Wed Feb 15 20:00:44 2006 From: twanfox@gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 14:00:44 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> Message-ID: <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> ------=_Part_13208_8716576.1140033644229 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ok, well, I don't know what I did differently yesterday to today, but it seems like I just figured out how to make a libotr 'head' build of a VS.NETcompatable static library. On 2/15/06, Twan Fox wrote: > > I had attempted to use that visual studio environment, but when I tried, > it was a little less than intuitive to set up, and the build attempt I ma= de > was all horktified (ie: it be broke). I've been using Visual Studio .NET > 2003 and the environments given were at best Visual Studio 6. If there is > more documentation on how to use that environment, I'm more than willing = to > use an already set up project to kick this thing off. I suppose I can tin= ker > with it more. Also just contemplating building the environment from scrat= ch > in VS.NET 2k3 for sanity sake, if I can figure out what > must be done for it. > > On 2/15/06, Ian Goldberg wrote: > > > > On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > > > Greetings, > > > > > > New to this list but using Trillian for a while, I have been getting = a > > > > > little antsy about not being able to encrypt messages across multiple > > IM > > > clients. Having originally intended to use another encryption protoco= l > > to do > > > this (already supported on Gaim), I find myself redirected to use OTR > > for > > > various reasons. At any rate, my whole goal is to craft up a plugin > > which > > > impliments OTR encryption for Trillian (latest version being 3.1). I > > come > > > across lacking a few things, though. > > > > > > Due to the basics of plugin development for Trillian having been > > designed in > > > Visual Studio (it seems), that is likely the tool under which I am > > going to > > > develop the plugin. However, obtaining or building a VS-usable librar= y > > for > > > libotr seems to be quite an excersize (for me, especially). I > > understand > > > that, at least in the case of Libgcrypt, .dll files have been built, > > but I > > > have yet to come across a dynamic (or static) library of libotr > > available > > > for Windows development. To me, ideally, I would like to build libotr > > as a > > > statically linked library within the plugin, to make it simple on > > > placing the final plugin within Trillian, but I haven't a notion wher= e > > to > > > begin in porting the build environment over. > > > > > > Any assistance is gladly appreciated. > > > > Francesco "s0rr0w" Picasso reported he'd done this: > > > > http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html > > > > - Ian > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev@lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > ------=_Part_13208_8716576.1140033644229 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Ok, well, I don't know what I did differently yesterday to today, but = it seems like I just figured out how to make a libotr 'head' build of a VS.NET compatable static library.

On 2/15/06, = Twan Fox <twanfox@gmail.com= > wrote:
I had attempted to use that visu= al studio environment, but when I tried, it was a little less than intuitiv= e to set up, and the build attempt I made was all horktified (ie: it be bro= ke). I've been using Visual Studio .NET 2003 and the environments given wer= e at best Visual Studio 6. If there is more documentation on how to use tha= t environment, I'm more than willing to use an already set up project to ki= ck this thing off. I suppose I can tinker with it more. Also just contempla= ting building the environment from scratch in=20 VS.NET 2k3 for sanity sake, if I can figure = out what must be done for it.=20


On 2/15/06, = Ian Goldberg <ian@cypherpunks.= ca > wrote:=20
On Wed, Feb 15, 2006 at 01:15:03= PM -0600, Twan Fox wrote:
> Greetings,
>
> New to this li= st but using Trillian for a while, I have been getting a=20
> little antsy about not being able to encrypt messages across multi= ple IM
> clients. Having originally intended to use another encryptio= n protocol to do
> this (already supported on Gaim), I find myself re= directed to use OTR for=20
> various reasons. At any rate, my whole goal is to craft up a plugi= n which
> impliments OTR encryption for Trillian (latest version bein= g 3.1). I come
> across lacking a few things, though.
>
> Due to the basics of plugin development for Trillian having been desig= ned in
> Visual Studio (it seems), that is likely the tool under whic= h I am going to
> develop the plugin. However, obtaining or building = a VS-usable library for=20
> libotr seems to be quite an excersize (for me, especially). I unde= rstand
> that, at least in the case of Libgcrypt, .dll files have bee= n built, but I
> have yet to come across a dynamic (or static) librar= y of libotr available=20
> for Windows development. To me, ideally, I would like to build lib= otr as a
> statically linked library within the plugin, to make it si= mple on
> placing the final plugin within Trillian, but I haven't a n= otion where to=20
> begin in porting the build environment over.
>
> Any a= ssistance is gladly appreciated.

Francesco "s0rr0w" Picass= o reported he'd done this:

http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html<= br>
  - Ian
_______________________________________________=
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr= -dev


------=_Part_13208_8716576.1140033644229-- From mr.s0rr0w@gmail.com Thu Feb 16 12:58:10 2006 From: mr.s0rr0w@gmail.com (s0rr0w) Date: Thu, 16 Feb 2006 13:58:10 +0100 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> Message-ID: <43F476E2.9020002@gmail.com> Twan Fox ha scritto: > Ok, well, I don't know what I did differently yesterday to today, but it > seems like I just figured out how to make a libotr 'head' build of a > VS.NETcompatable static library. >>>> Any assistance is gladly appreciated. >>> Francesco "s0rr0w" Picasso reported he'd done this: >>> >>> http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html >>> >>> - Ian hi all, I have not updated the project on sourcesafe, but I will do Twan: if you need help feel free to write directly to me, if argument is off-topic From evan.s@dreskin.net Fri Feb 17 18:57:37 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Fri, 17 Feb 2006 13:57:37 -0500 Subject: [OTR-dev] gaim-OTR, AIM DirectIM, and messaging signals Message-ID: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-10-834183803 Content-Type: multipart/alternative; boundary=Apple-Mail-9-834183601 --Apple-Mail-9-834183601 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed (Please reply-to-all, as I'm sending this to both relevant lists) AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any other gaim plugin-based encryption scheme. 1) User sends message in Gaim 2) Gaim gives plugins an opportunity to modify the message; an encryption plugin such as gaim-otr encrypts the message if appropriate, returning the encrypted message 3) Gaim sends the encrypted message to the prpl 4) In the case of oscar within a DirectIM session, the message is normally post-processed, looking for tags, which reference ids from the gaim img store in the form where gaim_imgstore_get (2) will return the GaimStoredImage* for the image. The image's data, size, etc. are inserted into the message..... but the message is encoded, so such a tag isn't found, and images can not be sent. A similar situation exists on the receiving side, where the prpl processes the incoming message, looking for tags to convert to the gaim img store and their corresponding IDs but sees only the gibberish of an encrypted message. As I mentioned, this is not specific to the gaim-otr implementation but rather a result of how the signals are set up. One solution I've come up with is giving the prpl a chance to modify the outgoing message before it is sent to plugins via a signal, and similarly call the prpl for final post-processing of incoming messages after the first signal is sent when receiving a message. Thoughts? Cheers, Evan www.adiumx.com --Apple-Mail-9-834183601 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 (Please reply-to-all, as I'm = sending this to both relevant lists)

AIM DirectIM can't work = within an OTR-encrypted chat; the same is true of any other gaim = plugin-based encryption scheme.

1) User sends message in = Gaim
2) Gaim gives plugins an opportunity to modify the = message; an encryption plugin such as gaim-otr encrypts the message if = appropriate, returning the encrypted message
3) Gaim sends the = encrypted message to the prpl
4) In the case of oscar within a = DirectIM session, the message is normally post-processed, looking for = <IMG> tags, which reference ids from the gaim img store in the = form <img=3D'2'> where=A0gaim_imgstore_get(2)=A0will return the = GaimStoredImage* for the image.=A0 The image's data, size, etc. are = inserted into the message..... but the message is encoded, so such a tag = isn't found, and images can not be = sent.

A similar situation exists = on the receiving side, where the prpl processes the incoming message, = looking for <img> tags to convert to the gaim img store and their = corresponding IDs but sees only the gibberish of an encrypted = message.

As I mentioned, this is not=A0specific = to the gaim-otr implementation but rather a result of how the signals = are set up.=A0 One solution I've come up with is giving the prpl a = chance to modify the outgoing message before it is sent to plugins via a = signal, and similarly call the prpl for final post-processing of = incoming messages after the first signal is sent when receiving a = message.

Thoughts?

Cheers,
Evan
<= DIV>www.adiumx.com
= --Apple-Mail-9-834183601-- --Apple-Mail-10-834183803 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD9hyhI5gp6xQhrvcRAqzQAJ9IoIAyKGfN660Z8e1PfdzgiOidXwCdEC2Y dSguHs6MbGTYWHtdkPnUh+0= =mFZZ -----END PGP SIGNATURE----- --Apple-Mail-10-834183803-- From siege@preoccupied.net Fri Feb 17 19:16:56 2006 From: siege@preoccupied.net (Christopher (siege) O'Brien) Date: Fri, 17 Feb 2006 14:16:56 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <1140203817.29615.4.camel@stella> On Fri, 2006-02-17 at 13:57 -0500, Evan Schoenberg wrote: > AIM DirectIM can't work within an OTR-encrypted chat; the same is true > of any other gaim plugin-based encryption scheme. The Sametime plugin has this problem as well, as it uses the same process as outlined in the previous email to determine if an outgoing message needs any embedded imaged to be built into a multipart MIME document. - siege -- Christopher (siege) O'Brien http://preoccupied.net/~siege/ From Scott Ellis" ------=_Part_13533_24735157.1140405145487 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline ok, this is the 'misbehaviour'... on one end (receiver), i set the sender contact to 'never' as the OTR polic= y on the other end (sender), i select 'start OTR' with the receiver contact on the reciever end i get the message: ?OTR?v2? 'OTR' has requested an Off-the-Record private conversation. However, you d= o not have a plugin to support that. See "http://www.cypherpunks.ca/otr/" for more information. it's incorrect on two counts - first, i do have the plugin...and secondly, it was not OTR that requested the session (the accountname is OTR) have i done something wrong? or, can something be done about this? Scott ------=_Part_13533_24735157.1140405145487 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
ok, this is the 'misbehaviour'...
 
on one end (receiver), i set the sender contact to 'never' a= s the OTR policy
on the other end (sender), i select 'start OTR' with the receiver cont= act
 
on the reciever end i get the message:
 
 ?OTR?v2?
'OTR' has requested an Off-the-Record private convers= ation.  However, you do not have a plugin to support that.
See &quo= t; http://www.cypherpunks.ca/otr/" for more i= nformation.
 =
it's incorrect on tw= o counts - first, i do have the plugin...and secondly, it was not OTR that = requested the session (the accountname is OTR)
 =
have i done somethin= g wrong? or, can something be done about this?
 
Scott
------=_Part_13533_24735157.1140405145487-- From evan.s@dreskin.net Mon Feb 20 13:37:16 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 08:37:16 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220060222.M10471@kingant.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> Message-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-18--1073320383 Content-Type: multipart/alternative; boundary=Apple-Mail-17--1073320594 --Apple-Mail-17--1073320594 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: > That would be kind of a pain, but if you really want to fix it I > guess that's > the only way to do it. Personally I'd rather see us implement > AIM's built-in > encryption capabilities. That wouldn't solve the problem, but it > would > hopefully make it less of an issue? Eh, from what I've heard, AIM's built-in encryption is nothing to write home about nor possibly even to write gaim-devl about. IANAC, though. Either way, even if we implement AIM's solution, that doesn't mean that (a) people won't still want to use the less- configuration, documented-protocol, etc. OTR solution, (b) other, similar solutions won't come up in the future, and (c) Sametime and any other prpl that needs pre/post prpl-level message processing will be fixed. It may be some time before I have a chance to fix it, so if someone else wants to work on it feel free -- but I'll look into a clean, minimally invasive solution in the not too distant future. -Evan --Apple-Mail-17--1073320594 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 20, 2006, = at 1:04 AM, Mark Doliner wrote:

That would be kind of a = pain, but if you really want to fix it I guess that's

the only way to do it.=A0 Personally I'd rather see us = implement AIM's built-in

encryption capabilities.=A0= That wouldn't solve the problem, but it would

hopefully make it less of an = issue?


Eh, from what I've heard, = AIM's built-in encryption is nothing to write home about nor possibly = even to write gaim-devl about.=A0 IANAC, though.=A0 Either way, even if = we implement AIM's solution, that doesn't mean that (a) people won't = still want to use the less-configuration, documented-protocol, etc. OTR = solution, (b) other, similar solutions won't come up in the future, and = (c) Sametime and any other prpl that needs pre/post prpl-level message = processing will be fixed.

It may be some time before = I have a chance to fix it, so if someone else wants to work on it feel = free -- but I'll look into a clean, minimally invasive solution in the = not too distant future.

-Evan
= --Apple-Mail-17--1073320594-- --Apple-Mail-18--1073320383 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD+cYNI5gp6xQhrvcRAmlBAKClsUcvVYl95fDluTJi/2PD3yUVngCgtKfh qesQftSJDkrcLaYMU1YOkGM= =UmD/ -----END PGP SIGNATURE----- --Apple-Mail-18--1073320383-- From mark@kingant.net Mon Feb 20 06:04:04 2006 From: mark@kingant.net (Mark Doliner) Date: Mon, 20 Feb 2006 01:04:04 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <20060220060222.M10471@kingant.net> On Fri, 17 Feb 2006 13:57:37 -0500, Evan Schoenberg wrote > (Please reply-to-all, as I'm sending this to both relevant lists) > > AIM DirectIM can't work within an OTR-encrypted chat; the same is > true of any other gaim plugin-based encryption scheme. > > 1) User sends message in Gaim > 2) Gaim gives plugins an opportunity to modify the message; an > encryption plugin such as gaim-otr encrypts the message if > appropriate, returning the encrypted message > 3) Gaim sends the encrypted message to the prpl > 4) In the case of oscar within a DirectIM session, the message is > normally post-processed, looking for tags, which reference ids > from the gaim img store in the form where > gaim_imgstore_get > (2) will return the GaimStoredImage* for the image. The image's > data, size, etc. are inserted into the message..... but the message > is encoded, so such a tag isn't found, and images can not be sent. > > A similar situation exists on the receiving side, where the prpl > processes the incoming message, looking for tags to convert to > the gaim img store and their corresponding IDs but sees only the > gibberish of an encrypted message. > > As I mentioned, this is not specific to the gaim-otr implementation > but rather a result of how the signals are set up. One solution > I've come up with is giving the prpl a chance to modify the > outgoing message before it is sent to plugins via a signal, and > similarly call the prpl for final post-processing of incoming > messages after the first signal is sent when receiving a message. > > Thoughts? > > Cheers, > Evan > www.adiumx.com That would be kind of a pain, but if you really want to fix it I guess that's the only way to do it. Personally I'd rather see us implement AIM's built-in encryption capabilities. That wouldn't solve the problem, but it would hopefully make it less of an issue? -Mark From eblanton@cs.ohiou.edu Mon Feb 20 17:11:48 2006 From: eblanton@cs.ohiou.edu (Ethan Blanton) Date: Mon, 20 Feb 2006 12:11:48 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> Message-ID: <20060220171148.GA3902@localhost.localdomain> --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Evan Schoenberg spake unto us the following wisdom: > On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: > >That would be kind of a pain, but if you really want to fix it I=20 > >guess that's the only way to do it. Personally I'd rather see us > >implement AIM's built-in encryption capabilities. That wouldn't solve > >the problem, but it would hopefully make it less of an issue? >=20 > Eh, from what I've heard, AIM's built-in encryption is nothing to =20 > write home about nor possibly even to write gaim-devl about. IANAC, =20 > though. Either way, even if we implement AIM's solution, that =20 > doesn't mean that (a) people won't still want to use the less-=20 > configuration, documented-protocol, etc. OTR solution, (b) other, =20 > similar solutions won't come up in the future, and (c) Sametime and =20 > any other prpl that needs pre/post prpl-level message processing will =20 > be fixed. It's interesting that you say it's nothing to write home about ... what have you heard? My understanding is that it uses AOL-signed SSL-style certificates for authentication, although I don't know what it does for encryption past that and it's certainly possible that they did something stupid in their algorithms. Assuming that they do *any* sort of identity checking at all before issuing the certificate, it's at least equivalent to almost everything else out there (and practically better, since most people don't verify their keys at *all*, but that's not a technical point), and even if they don't but they register certificates to screen names, it's worth *something*. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --jI8keyz6grp/JLjh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD+fhUr9kA9Ig8HBQRAtkcAJ9xtoY/TBFOKqHavFYstDb7CyAEgACfaaz5 aS3oUOTiX/Dtl5rr99HfXfA= =5kXZ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From ian@cypherpunks.ca Mon Feb 20 18:55:00 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 13:55:00 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602191912o4e636f89u@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> Message-ID: <20060220185500.GW31096@smtp.paip.net> On Mon, Feb 20, 2006 at 02:12:25PM +1100, Scott Ellis wrote: > ok, this is the 'misbehaviour'... > > on one end (receiver), i set the sender contact to 'never' as the OTR policy > on the other end (sender), i select 'start OTR' with the receiver contact > > on the reciever end i get the message: > > ?OTR?v2? > 'OTR' has requested an Off-the-Record private conversation. However, you do > not have a plugin to support that. > See "http://www.cypherpunks.ca/otr/" for more information. > > it's incorrect on two counts - first, i do have the plugin... Well, yes, but you've disabled it for that contact. Maybe "you do not have an active plugin..." would be better? > and secondly, it was not OTR that requested the session (the > accountname is OTR) I'm not sure I understand here. It looks like you're passing the string "OTR" as the first parameter to otrl_proto_default_query_msg() when the user selects "start OTR" instead of passing the account name. - Ian From evan.s@dreskin.net Mon Feb 20 20:16:20 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 15:16:20 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <20060220185500.GW31096@smtp.paip.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> Message-ID: <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-5--1049376870 Content-Type: multipart/alternative; boundary=Apple-Mail-4--1049377144 --Apple-Mail-4--1049377144 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 20, 2006, at 1:55 PM, Ian Goldberg wrote: > Well, yes, but you've disabled it for that contact. Maybe "you do not > have an active plugin..." would be better? Is the goal to completely avoid processing text when Never is the policy? If not, what about reinterpreting that message as "Joe has request an Off-the-Record private conversation, but you have disabled Off-the-Record messaging to Joe. To allow OTR, change your policy for Joe." ? -Evan --Apple-Mail-4--1049377144 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 20, 2006, = at 1:55 PM, Ian Goldberg wrote:

Well, yes, but you've = disabled it for that contact.=A0 = Maybe "you do not

have an active plugin..." would be better?

=

Is the goal to completely avoid processing = text when Never is the policy?=A0 If not, what about reinterpreting that = message as "Joe has request an Off-the-Record private conversation, but = you have disabled=A0Off-the-Record messaging to Joe.=A0 To allow OTR, = change your policy for Joe." ?

-Evan
= --Apple-Mail-4--1049377144-- --Apple-Mail-5--1049376870 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD+iOUI5gp6xQhrvcRAjaoAKDAAprB3PW72wAQDchhQNb1PNf+7ACcC0cm xaZeAsLPB0okgfGkdfA5xKU= =Tc/q -----END PGP SIGNATURE----- --Apple-Mail-5--1049376870-- From ian@cypherpunks.ca Mon Feb 20 20:30:16 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 15:30:16 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> Message-ID: <20060220203016.GZ31096@smtp.paip.net> On Mon, Feb 20, 2006 at 03:16:20PM -0500, Evan Schoenberg wrote: > > On Feb 20, 2006, at 1:55 PM, Ian Goldberg wrote: > > >Well, yes, but you've disabled it for that contact. Maybe "you do not > >have an active plugin..." would be better? > > Is the goal to completely avoid processing text when Never is the > policy? It has been, up until this point. > If not, what about reinterpreting that message as "Joe has > request an Off-the-Record private conversation, but you have disabled > Off-the-Record messaging to Joe. To allow OTR, change your policy > for Joe." ? That's a plausible suggestion; I'd be willing to consider it. Thanks, - Ian From evan.s@dreskin.net Mon Feb 20 20:52:18 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 15:52:18 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220171148.GA3902@localhost.localdomain> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> Message-ID: <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-7--1047218287 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 20, 2006, at 12:11 PM, Ethan Blanton wrote: > Evan Schoenberg spake unto us the following wisdom: >> On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: >>> That would be kind of a pain, but if you really want to fix it I >>> guess that's the only way to do it. Personally I'd rather see us >>> implement AIM's built-in encryption capabilities. That wouldn't >>> solve >>> the problem, but it would hopefully make it less of an issue? >> >> Eh, from what I've heard, AIM's built-in encryption is nothing to >> write home about nor possibly even to write gaim-devl about. IANAC, >> though. > > It's interesting that you say it's nothing to write home about ... > what have you heard? My understanding is that it uses AOL-signed > SSL-style certificates for authentication, although I don't know what > it does for encryption past that and it's certainly possible that they > did something stupid in their algorithms. Assuming that they do *any* > sort of identity checking at all before issuing the certificate, it's > at least equivalent to almost everything else out there (and > practically better, since most people don't verify their keys at > *all*, but that's not a technical point), and even if they don't but > they register certificates to screen names, it's worth *something*. That hadn't been my understanding, so I did a bit of research. It turns out I was basically wrong about AOL's official encryption, and I apologize for spreading misinformation. :) It turns out what I was thinking of is Trillian's SecureIM which has become a common form of AIM encryption. SecureIM providese no authentication or signing whatsoever. As a side note, it uses Blowfish-based encryption. The AOL-official encryption is an entirely different story. joust.kano.net, where Keith Lea has a good description of the protocol and how it works, is down, and but google's cache of the appropriate page [1] isn't. Brief summary is that it's end-to-end SSL encryption, not only of messages but also of file transfers, direct IM connections, and Get File connections. It also allows for secure chat rooms via a very strange mechanism of the chat room creator sharing a secret key with invitees (anybody can join the room, but only those invited can read the plaintext... with the amusing side effect that you could have multiple encrypted chats simultaneously in the same room). Users of this mechanism need an SSL cert... savvy users can generate their own and self-sign them or pay to have them signed, and AOL offers verisign-signed certificates for a key. I have no idea what the registration / verification mechanism is for the latter process. A side note about the AOL encryption: As detailed at [2], there is an aimencrypt.com website which explains to clueless users how to obtain a free signed certificate. Fantastically, it's free because aimencrypt bought one and gives it to users to download so they can have a cool lock by their name... just wow. -Evan [1] http://64.233.179.104/search?q=cache:jYfa2ow86SUJ:joust.kano.net/ wiki/oscar/moin.cgi/AimSecureIm+AimSecureIM&hl=en&gl=us&ct=clnk&cd=1 [2] http://fae.cs.columbia.edu/aimencrypt.pdf --Apple-Mail-7--1047218287 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD+iwDI5gp6xQhrvcRAgcxAJ4kD5Cp+lkb8aQVW6T5gwn43vJdCACffcXR Mb0HMYJV/nsAwXmgjABENfY= =0GqI -----END PGP SIGNATURE----- --Apple-Mail-7--1047218287-- From ian@cypherpunks.ca Mon Feb 20 21:47:21 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 16:47:21 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> Message-ID: <20060220214721.GB31096@smtp.paip.net> On Mon, Feb 20, 2006 at 03:52:18PM -0500, Evan Schoenberg wrote: > That hadn't been my understanding, so I did a bit of research. It > turns out I was basically wrong about AOL's official encryption, and > I apologize for spreading misinformation. :) > > It turns out what I was thinking of is Trillian's SecureIM which has > become a common form of AIM encryption. SecureIM providese no > authentication or signing whatsoever. As a side note, it uses > Blowfish-based encryption. That's correct. SecureIM uses unauthenticated Diffie-Hellman for key agreement, followed by Blowfish for message encryption, and no message authentication or integrity checking at all. > joust.kano.net, where Keith Lea has a good description of the > protocol and how it works, is down, and but google's cache of the > appropriate page [1] isn't. Brief summary is that it's end-to-end > SSL encryption, not only of messages but also of file transfers, > direct IM connections, and Get File connections. Looking at that link, it seems to me that normal IM communication isn't just "tunnel over SSL"; it's sent by individually wrapping each message with an RSA encryption and an RSA signature. > Users of this mechanism need an > SSL cert... savvy users can generate their own and self-sign them or > pay to have them signed, and AOL offers verisign-signed certificates > for a key. I have no idea what the registration / verification > mechanism is for the latter process. So there's no binding whatsoever between the cert and the screen name? In what sense is it a cert, then? > A side note about the AOL encryption: As detailed at [2], there is an > aimencrypt.com website which explains to clueless users how to obtain > a free signed certificate. Fantastically, it's free because > aimencrypt bought one and gives it to users to download so they can > have a cool lock by their name... just wow. Wow indeed. So there's definitely *no* binding. I'm not saying that's necessarily bad; it just means you need to do the same type of out-of-band verification of the key that OTR requires. But from what I can tell of the UI, there's no indication that you need to do this in AIM-Encrypt. And the wiki page would seem to suggest that self-signed certs work just fine. So why would aimencrypt.com offer a constant cert to everyone when they could just offer a little widget to generate a fresh self-signed one? I wonder how quickly someone could throw together a patch to the OSCAR-parsing module of ethereal (or something like that) that automatically decrypts messages encrypted to this shared aimencrypt.com cert. :-) - Ian From kbeckman@students.mcg.edu Tue Feb 21 03:44:55 2006 From: kbeckman@students.mcg.edu (Keith Beckman) Date: Mon, 20 Feb 2006 22:44:55 -0500 Subject: [OTR-dev] Command-Line OTR Proxy? Message-ID: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> I've just installed OTR Proxy on Mac OS X 10.4.3, running on a PowerBook G4 500MHz. I've noted two things that would make it a much nicer program to run, in my opinion. The first is that the "quit" option doesn't work correctly. Rather than killing the proxy, it sits indefinitely with the file menu darkened and the proxy still running. It always requires a kill to shut the program down. The second is that it would be really nice to have the proxy be executable as a command-line app. That way I could just launch it into the background from the terminal, maybe defining an alternate oscar server (since AOL has been known to change that), and perhaps an alternate .otrproxyrc file (which would be a nice, tidy way to house settings). It's just a thought, but I don't think it ought to be too difficult to implement. I'd give it a shot, but I've never actually worked with C before . . . Thanks! Keith From Scott Ellis" References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> Message-ID: <96e269140602210108o4fbcbbdcj@mail.gmail.com> ------=_Part_7683_1036450.1140512917611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > >> ok, this is the 'misbehaviour'... > >> > >> on one end (receiver), i set the sender contact to 'never' as the OTR > policy > >> on the other end (sender), i select 'start OTR' with the receiver > contact > >> > >> on the reciever end i get the message: > >> > >> ?OTR?v2? > >> 'OTR' has requested an Off-the-Record private conversation. However, > you do > >> not have a plugin to support that. > >> See "http://www.cypherpunks.ca/otr/" for more information. > >> > >> it's incorrect on two counts - first, i do have the plugin... > > > >Well, yes, but you've disabled it for that contact. Maybe "you do not > >have an active plugin..." would be better? Yes, something like that - although detecting that it's just the policy, an= d saying something like 'plugin is inactive for this contact' would be ideal. > > >> and secondly, it was not OTR that requested the session (the > >> accountname is OTR) > > > >I'm not sure I understand here. It looks like you're passing the string > >"OTR" as the first parameter to otrl_proto_default_query_msg() when the > >user selects "start OTR" instead of passing the account name. Yes that's what i pass in. In miranda there aren't different accounts - onl= y different protocols. It is possible to have e.g. two MSN 'accounts' but you do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or th= e like, and miranda treats it as a seperate protocol. So, in the plugin there is only one account - i called it OTR, since i didn't think it'd make a difference. What I meant to point out is, since the username is passed into that function also, shouldn't the username be used in this message? ------=_Part_7683_1036450.1140512917611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
>> ok, this is the 'misbeh= aviour'...
>>
>> on one end (receiver), i set the sender = contact to 'never' as the OTR policy
>> on the other end (sender), i select 'start OTR' with the recei= ver contact
>>
>> on the reciever end i get the message:<= br>>>
>>  ?OTR?v2?
>> 'OTR' has requested= an Off-the-Record private conversation.  However, you do
>> not have a plugin to support that.
>> See "http://www.cypherpunks.ca/otr/&qu= ot; for more information.
>>
>> it's incorrect on two cou= nts - first, i do have the plugin...
>
>Well, yes, but you've disabled it for that contact. &n= bsp;Maybe "you do not
>have an active plugin..." would be b= etter?
 
Yes, something like that - although detecting that it's just the polic= y, and saying something like 'plugin is inactive for this contact' would be= ideal.

>
>> and secondly, i= t was not OTR that requested the session (the
>> accountname is OT= R)
>
>I'm not sure I understand here.  It looks like yo= u're passing the string
>"OTR" as the first parameter to ot= rl_proto_default_query_msg() when the
>user selects "start OTR&q= uot; instead of passing the account name.
 
Yes that's what i pass in. In miranda there aren't different accounts = - only different protocols. It is possible to have e.g. two MSN 'accounts' = but you do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.d= ll or the like, and miranda treats it as a seperate protocol. So, in the plug= in there is only one account - i called it OTR, since i didn't think it'd m= ake a difference. What I meant to point out is, since the username is passe= d into that function also, shouldn't the username be used in this message?
------=_Part_7683_1036450.1140512917611-- From Scott Ellis" ------=_Part_11149_24461256.1140532079930 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline i'm wondering, what would be the effect of adding the WHITESPACE_START_AKE flag into the MANUAL mode? i mean - in my testing it seems that opportunistic mode only starts OTR whe= n both sides have it set - if one side is set to manual, then automatic initialisation of OTR does not occur. if both sides are in manual, user 1 can 'force' user 2 to start OTR...so, i= f a user chooses 'opportunistic', wouldn't it make sense to force users they talk to who are in manual mode to start OTR also? would adding that flag have that effect? Scott ------=_Part_11149_24461256.1140532079930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
i'm wondering, what would be the effect of adding the WHITESPACE_= START_AKE flag into the MANUAL mode?
 
i mean - in my testing it seems that opportunistic mode only starts OT= R when both sides have it set - if one side is set to manual, then automati= c initialisation of OTR does not occur.
 
if both sides are in manual, user 1 can 'force' user 2 to start OTR...= so, if a user chooses 'opportunistic', wouldn't it make sense to force user= s they talk to who are in manual mode to start OTR also? would adding = that flag have that effect?
 
Scott
------=_Part_11149_24461256.1140532079930-- From evan.s@dreskin.net Tue Feb 21 15:23:08 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Tue, 21 Feb 2006 10:23:08 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <96e269140602210627j6f166685h@mail.gmail.com> References: <96e269140602210627j6f166685h@mail.gmail.com> Message-ID: <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--980568547 Content-Type: multipart/alternative; boundary=Apple-Mail-11--980568794 --Apple-Mail-11--980568794 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Scott, You've come to the exact same conclusion I did with the same rationale. Adium's "manual" mode is actually defined as: /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic attempts at encryption. * If either user has OTR set to Automatic, an OTR session should be begun; without this modified * mask, both users would have to be on automatic for OTR to begin automatically, even though one user * _manually_ attempting OTR will _automatically_ bring the other into OTR even if the setting is Manual. */ #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL | \ OTRL_POLICY_WHITESPACE_START_AKE | \ OTRL_POLICY_ERROR_START_AKE ) -Evan www.adiumx.com On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > i'm wondering, what would be the effect of adding the > WHITESPACE_START_AKE flag into the MANUAL mode? > > i mean - in my testing it seems that opportunistic mode only starts > OTR when both sides have it set - if one side is set to manual, > then automatic initialisation of OTR does not occur. > > if both sides are in manual, user 1 can 'force' user 2 to start > OTR...so, if a user chooses 'opportunistic', wouldn't it make sense > to force users they talk to who are in manual mode to start OTR > also? would adding that flag have that effect? > > Scott --Apple-Mail-11--980568794 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Scott,

You've come to the exact = same conclusion I did with the same rationale.=A0 Adium's "manual" mode = is actually defined as:
/* OTRL_POLICY_MANUAL doesn't let us respond to other users' = automatic attempts at encryption.
=A0* If either user has OTR set to Automatic, = an OTR session should be begun; without this = modified
=A0* mask, both users would have to be on automatic for OTR to = begin automatically, even though one user
=A0* _manually_ attempting OTR will = _automatically_ bring the other into OTR even if the setting is = Manual.
=A0*/
#define = OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( = OTRL_POLICY_MANUAL | \
=A0= OTRL_POLICY_WHITESPACE_START_AKE | = \
=A0 = OTRL_POLICY_ERROR_START_AKE = )

-Evan
www.adiumx.co= m

On Feb 21, 2006, at 9:27 AM, Scott Ellis = wrote:

i'm wondering, what would be the effect of=A0adding = the WHITESPACE_START_AKE flag into the MANUAL mode?
=A0
=
i mean - in my testing it seems that opportunistic mode only starts = OTR when both sides have it set - if one side is set to manual, then = automatic initialisation of OTR does not occur.
=A0
=
if both sides are in manual, user 1 can 'force' user 2 to start = OTR...so, if a user chooses 'opportunistic', wouldn't it make sense to = force users they talk to who are in manual mode to start OTR also? = would=A0adding that flag have that effect?
=A0
=
Scott

= --Apple-Mail-11--980568794-- --Apple-Mail-12--980568547 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD+zBcI5gp6xQhrvcRAuHJAJ9rj6+ZHUTKKr23C6k5A1CP0hIx7ACffdOJ vj3OtJEfXlFdw48C4jJ9ooo= =bGqv -----END PGP SIGNATURE----- --Apple-Mail-12--980568547-- From Scott Ellis" References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> Message-ID: <96e269140602211603l5d1afa19q@mail.gmail.com> ------=_Part_18774_26693028.1140566580093 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thanks Evan...but I tried it, and get a 'duplicate case' error in one of my switch statements... It turns out to be because 'send whitespace tag' and 'whitespace start ake' are both defined to be 0x08 - so they're actually both the same thing. This means, if I define manual the way you suggest, it is exactly the same as opportunistic - which is not what I want. So I guess the behaviour I'm after is not possible with the current source. On 22/02/06, Evan Schoenberg wrote: > > Scott, > > You've come to the exact same conclusion I did with the same rationale. > Adium's "manual" mode is actually defined as: > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic > attempts at encryption. > * If either user has OTR set to Automatic, an OTR session should be > begun; without this modified > * mask, both users would have to be on automatic for OTR to begin > automatically, even though one user > * _manually_ attempting OTR will _automatically_ bring the other into OT= R > even if the setting is Manual. > */ > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL = | > \ > OTRL_POLICY_WHITESPACE_START_AKE | \ > OTRL_POLICY_ERROR_START_AKE ) > > > -Evan > www.adiumx.com > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > > i'm wondering, what would be the effect of adding the > WHITESPACE_START_AKE flag into the MANUAL mode? > > i mean - in my testing it seems that opportunistic mode only starts OTR > when both sides have it set - if one side is set to manual, then automati= c > initialisation of OTR does not occur. > > if both sides are in manual, user 1 can 'force' user 2 to start OTR...so, > if a user chooses 'opportunistic', wouldn't it make sense to force users > they talk to who are in manual mode to start OTR also? would adding that > flag have that effect? > > Scott > > > > > ------=_Part_18774_26693028.1140566580093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Thanks Evan...but I tried it, and get a 'duplicate case' error in one = of my switch statements...
 
It turns out to be because 'send whitespace tag' and 'whitespace start= ake' are both defined to be 0x08 - so they're actually both the same thing= . This means, if I define manual the way you suggest, it is exactly the sam= e as opportunistic - which is not what I want.
 
So I guess the behaviour I'm after is not possible with the current so= urce.

 
On 22/02/06, Evan Schoenberg <evan.s@dresk= in.net> wrote:
Scott,=20

 
You've come to the exact same conclusion I did with the same rationale= .  Adium's "manual" mode is actually defined as:
/* OTRL_POLICY_MANUAL doesn't let us res= pond to other users' automatic attempts at encryption.
 * If either user has OTR set to Au= tomatic, an OTR session should be begun; without this modified
 * mask, both users would have to b= e on automatic for OTR to begin automatically, even though one user<= /font>
 * _manually_ attempting OTR will _= automatically_ bring the other into OTR even if the setting is Manual.
 */
#define OTRL_POLICY_MANUAL_AND_REPOND_TO= _WHITESPACE ( OTRL_POLICY_MANUAL | \
  OTRL_POLICY_WHITESPACE_START_AKE | \
  OTRL_POLICY_ERROR_START_AKE )

 
-Evan

On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote:

i'm wondering, what would be the effect of adding the WHITESPACE_= START_AKE flag into the MANUAL mode?
 
i mean - in my testing it seems that opportunistic mode only starts OT= R when both sides have it set - if one side is set to manual, then automati= c initialisation of OTR does not occur.
 
if both sides are in manual, user 1 can 'force' user 2 to start OTR...= so, if a user chooses 'opportunistic', wouldn't it make sense to force user= s they talk to who are in manual mode to start OTR also? would adding = that flag have that effect?=20
 
Scott

 


------=_Part_18774_26693028.1140566580093-- From Scott Ellis" References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> Message-ID: <96e269140602211659q7004b324m@mail.gmail.com> ------=_Part_19078_10686598.1140569965915 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline seems to work find with the flags in the source fixed On 22/02/06, Scott Ellis wrote: > > Thanks Evan...but I tried it, and get a 'duplicate case' error in one of > my switch statements... > > It turns out to be because 'send whitespace tag' and 'whitespace start > ake' are both defined to be 0x08 - so they're actually both the same thin= g. > This means, if I define manual the way you suggest, it is exactly the sam= e > as opportunistic - which is not what I want. > > So I guess the behaviour I'm after is not possible with the current > source. > > > On 22/02/06, Evan Schoenberg wrote: > > > > Scott, > > > > You've come to the exact same conclusion I did with the same rationale. > > Adium's "manual" mode is actually defined as: > > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic > > attempts at encryption. > > * If either user has OTR set to Automatic, an OTR session should be > > begun; without this modified > > * mask, both users would have to be on automatic for OTR to begin > > automatically, even though one user > > * _manually_ attempting OTR will _automatically_ bring the other into > > OTR even if the setting is Manual. > > */ > > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUA= L > > | \ > > OTRL_POLICY_WHITESPACE_START_AKE | \ > > OTRL_POLICY_ERROR_START_AKE ) > > > > > > -Evan > > www.adiumx.com > > > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > > > > i'm wondering, what would be the effect of adding the > > WHITESPACE_START_AKE flag into the MANUAL mode? > > > > i mean - in my testing it seems that opportunistic mode only starts OTR > > when both sides have it set - if one side is set to manual, then automa= tic > > initialisation of OTR does not occur. > > > > if both sides are in manual, user 1 can 'force' user 2 to start > > OTR...so, if a user chooses 'opportunistic', wouldn't it make sense to = force > > users they talk to who are in manual mode to start OTR also? would addi= ng > > that flag have that effect? > > > > Scott > > > > > > > > > > > ------=_Part_19078_10686598.1140569965915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline seems to work find with the flags in the source fixed

On 22/02/06, Scott Ellis <mail@scottel= lis.com.au> wrote:
Thanks Evan...but I tried it, and get a 'duplicate case' error in one = of my switch statements...
 
It turns out to be because 'send whitespace tag' and 'whitespace start= ake' are both defined to be 0x08 - so they're actually both the same thing= . This means, if I define manual the way you suggest, it is exactly the sam= e as opportunistic - which is not what I want.=20
 
So I guess the behaviour I'm after is not possible with the current so= urce.

 
On 22/02/06, Evan Schoenberg <evan.s@dresk= in.net > wrote:=20
Scott,=20

 
You've come to the exact same conclusion I did with the same rationale= .  Adium's "manual" mode is actually defined as:
/* OTRL_POLICY_MANUAL doesn't let us res= pond to other users' automatic attempts at encryption.
 * If either user has OTR set to Au= tomatic, an OTR session should be begun; without this modified
 * mask, both users would have to b= e on automatic for OTR to begin automatically, even though one user<= /font>
 * _manually_ attempting OTR will _= automatically_ bring the other into OTR even if the setting is Manual.
 */
#define OTRL_POLICY_MANUAL_AND_REPOND_TO= _WHITESPACE ( OTRL_POLICY_MANUAL | \
  OTRL_POLICY_WHITESPACE_START_AKE | \=20
  OTRL_POLICY_ERROR_START_AKE )=20

 
-Evan

On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote:

i'm wondering, what would be the effect of adding the WHITESPACE_= START_AKE flag into the MANUAL mode?
 
i mean - in my testing it seems that opportunistic mode only starts OT= R when both sides have it set - if one side is set to manual, then automati= c initialisation of OTR does not occur.
 
if both sides are in manual, user 1 can 'force' user 2 to start OTR...= so, if a user chooses 'opportunistic', wouldn't it make sense to force user= s they talk to who are in manual mode to start OTR also? would adding = that flag have that effect?=20
 
Scott

 



------=_Part_19078_10686598.1140569965915-- From evan.s@dreskin.net Wed Feb 22 03:52:50 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Tue, 21 Feb 2006 22:52:50 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <96e269140602211659q7004b324m@mail.gmail.com> References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> Message-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--935586802 Content-Type: multipart/alternative; boundary=Apple-Mail-21--935586949 --Apple-Mail-21--935586949 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The flags problem _should_ be fixed in HEAD -- I emailed with Ian about it previously. -Evan On Feb 21, 2006, at 7:59 PM, Scott Ellis wrote: > seems to work find with the flags in the source fixed > > On 22/02/06, Scott Ellis wrote: > Thanks Evan...but I tried it, and get a 'duplicate case' error in > one of my switch statements... > > It turns out to be because 'send whitespace tag' and 'whitespace > start ake' are both defined to be 0x08 - so they're actually both > the same thing. This means, if I define manual the way you suggest, > it is exactly the same as opportunistic - which is not what I want. > > So I guess the behaviour I'm after is not possible with the current > source. > > > On 22/02/06, Evan Schoenberg wrote: > Scott, > > > You've come to the exact same conclusion I did with the same > rationale. Adium's "manual" mode is actually defined as: > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' > automatic attempts at encryption. > * If either user has OTR set to Automatic, an OTR session should > be begun; without this modified > * mask, both users would have to be on automatic for OTR to begin > automatically, even though one user > * _manually_ attempting OTR will _automatically_ bring the other > into OTR even if the setting is Manual. > */ > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE > ( OTRL_POLICY_MANUAL | \ > OTRL_POLICY_WHITESPACE_START_AKE | \ > OTRL_POLICY_ERROR_START_AKE ) > > > -Evan > www.adiumx.com > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > >> i'm wondering, what would be the effect of adding the >> WHITESPACE_START_AKE flag into the MANUAL mode? >> >> i mean - in my testing it seems that opportunistic mode only >> starts OTR when both sides have it set - if one side is set to >> manual, then automatic initialisation of OTR does not occur. >> >> if both sides are in manual, user 1 can 'force' user 2 to start >> OTR...so, if a user chooses 'opportunistic', wouldn't it make >> sense to force users they talk to who are in manual mode to start >> OTR also? would adding that flag have that effect? >> >> Scott > > > > > --Apple-Mail-21--935586949 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 The flags problem _should_ be = fixed in HEAD -- I emailed with Ian about it previously.

-Evan

On Feb 21, 2006, at 7:59 PM, Scott Ellis wrote:

seems to = work find with the flags in the source fixed

On 22/02/06, Scott = Ellis <mail@scottellis.com.au> = wrote:
=
Thanks Evan...but I tried it, and get a 'duplicate case' error in = one of my switch statements...
=A0
It turns out to = be because 'send whitespace tag' and 'whitespace start ake' are both = defined to be 0x08 - so they're actually both the same thing. This = means, if I define manual the way you suggest, it is exactly the same as = opportunistic - which is not what I want.
=A0
So = I guess the behaviour I'm after is not possible with the current = source.

=A0
On = 22/02/06, Evan Schoenberg <evan.s@dreskin.net = > wrote:
Scott,

=A0
You've come to the exact same = conclusion I did with the same rationale.=A0 Adium's "manual" mode is = actually defined as:
/* OTRL_POLICY_MANUAL doesn't let us respond to other users' = automatic attempts at encryption.
=A0* If either user has OTR = set to Automatic, an OTR session should be begun; without this = modified
=A0* mask, both users would have to be on automatic for OTR to = begin automatically, even though one user
=A0* _manually_ attempting = OTR will _automatically_ bring the other into OTR even if the setting is = Manual.
=A0*/
#define = OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL | = \
=A0 OTRL_POLICY_WHITESPACE_START_AKE | \
= =A0 OTRL_POLICY_ERROR_START_AKE )
=

=A0
-Evan

=
On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote:

=
i'm wondering, what would be the effect = of=A0adding the WHITESPACE_START_AKE flag into the MANUAL mode?
=
=A0
i mean - in my testing it seems that opportunistic = mode only starts OTR when both sides have it set - if one side is set to = manual, then automatic initialisation of OTR does not occur.
=
=A0
if both sides are in manual, user 1 can 'force' user = 2 to start OTR...so, if a user chooses 'opportunistic', wouldn't it make = sense to force users they talk to who are in manual mode to start OTR = also? would=A0adding that flag have that effect?
=A0
=
Scott

=A0



<= /BLOCKQUOTE>

= --Apple-Mail-21--935586949-- --Apple-Mail-22--935586802 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD++ASI5gp6xQhrvcRAvJjAKCaJMJKYHkTugyvXAZ4+4hNfhi3uACeO/U2 eBYidxoq+FSdHcLU4ZSM17U= =L8aI -----END PGP SIGNATURE----- --Apple-Mail-22--935586802-- From ian@cypherpunks.ca Wed Feb 22 14:50:15 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 09:50:15 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602210108o4fbcbbdcj@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> Message-ID: <20060222145015.GI31096@smtp.paip.net> On Tue, Feb 21, 2006 at 08:08:37PM +1100, Scott Ellis wrote: > > >I'm not sure I understand here. It looks like you're passing the string > > >"OTR" as the first parameter to otrl_proto_default_query_msg() when the > > >user selects "start OTR" instead of passing the account name. > > > Yes that's what i pass in. In miranda there aren't different accounts - only > different protocols. It is possible to have e.g. two MSN 'accounts' but you > do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or the > like, and miranda treats it as a seperate protocol. Wow. That *is* a hack. Surely there's a way to extract your account name, though? > So, in the plugin there > is only one account - i called it OTR, since i didn't think it'd make a > difference. What I meant to point out is, since the username is passed into > that function also, shouldn't the username be used in this message? The remote username? That's not passed in: /* Return a pointer to a newly-allocated OTR query message, customized * with our name. The caller should free() the result when he's done * with it. */ char *otrl_proto_default_query_msg(const char *ourname, OtrlPolicy policy); - Ian From ian@cypherpunks.ca Wed Feb 22 14:55:08 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 09:55:08 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> Message-ID: <20060222145508.GJ31096@smtp.paip.net> On Tue, Feb 21, 2006 at 10:52:50PM -0500, Evan Schoenberg wrote: > The flags problem _should_ be fixed in HEAD -- I emailed with Ian > about it previously. It is, in fact. The fix was checked in in November. - Ian From eblanton@cs.ohiou.edu Tue Feb 21 03:35:29 2006 From: eblanton@cs.ohiou.edu (Ethan Blanton) Date: Mon, 20 Feb 2006 22:35:29 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220214721.GB31096@smtp.paip.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> <20060220214721.GB31096@smtp.paip.net> Message-ID: <20060221033528.GB3902@localhost.localdomain> --ZoaI/ZTpAVc4A5k6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ian Goldberg spake unto us the following wisdom: > > Users of this mechanism need an =20 > > SSL cert... savvy users can generate their own and self-sign them or = =20 > > pay to have them signed, and AOL offers verisign-signed certificates = =20 > > for a key. I have no idea what the registration / verification =20 > > mechanism is for the latter process. >=20 > So there's no binding whatsoever between the cert and the screen name? > In what sense is it a cert, then? Ideally the provided-by-AOL certifications would certify something about the identity of the owner; given their staunch position on not identifying the owners of screen names, this may not be the case. > And the wiki page would seem to suggest that self-signed certs work just > fine. So why would aimencrypt.com offer a constant cert to everyone > when they could just offer a little widget to generate a fresh > self-signed one? Not that this would provide a whole lot more (effective) security ... because they could just keep and distribute copies of the private keys. ;-) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --ZoaI/ZTpAVc4A5k6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD+oqAr9kA9Ig8HBQRAm8lAJsFO5XE7Alg1rp7uDNcY3uTCJgw+ACfWjO6 GGhgikg03HQ19Dv7lo7bhns= =JLQO -----END PGP SIGNATURE----- --ZoaI/ZTpAVc4A5k6-- From ian@cypherpunks.ca Wed Feb 22 17:38:48 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 12:38:48 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060221033528.GB3902@localhost.localdomain> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> <20060220214721.GB31096@smtp.paip.net> <20060221033528.GB3902@localhost.localdomain> Message-ID: <20060222173848.GO31096@smtp.paip.net> On Mon, Feb 20, 2006 at 10:35:29PM -0500, Ethan Blanton wrote: > > And the wiki page would seem to suggest that self-signed certs work just > > fine. So why would aimencrypt.com offer a constant cert to everyone > > when they could just offer a little widget to generate a fresh > > self-signed one? > > Not that this would provide a whole lot more (effective) security ... > because they could just keep and distribute copies of the private > keys. ;-) I would *hope* they would do something more secure, involving client-side generation, but considering what they do now... :-p - Ian From ian@cypherpunks.ca Wed Feb 22 17:41:02 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 12:41:02 -0500 Subject: [OTR-dev] Command-Line OTR Proxy? In-Reply-To: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> References: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> Message-ID: <20060222174102.GP31096@smtp.paip.net> On Mon, Feb 20, 2006 at 10:44:55PM -0500, Keith Beckman wrote: > I've just installed OTR Proxy on Mac OS X 10.4.3, running on a > PowerBook G4 500MHz. I've noted two things that would make it a much > nicer program to run, in my opinion. The first is that the "quit" > option doesn't work correctly. Rather than killing the proxy, it sits > indefinitely with the file menu darkened and the proxy still running. > It always requires a kill to shut the program down. Huh. Is this a known problem? Do other OSX people see this? > The second is that it would be really nice to have the proxy be > executable as a command-line app. That way I could just launch it > into the background from the terminal, maybe defining an alternate > oscar server (since AOL has been known to change that), and perhaps > an alternate .otrproxyrc file (which would be a nice, tidy way to > house settings). It's just a thought, but I don't think it ought to > be too difficult to implement. I'd give it a shot, but I've never > actually worked with C before . . . The proxy was written with seperate backend and UI components, for exactly this reason. It just needs someone with the time/ability to plug in a text-based (ncurses?) UI. - Ian From me@nikita.ca Wed Feb 22 20:01:06 2006 From: me@nikita.ca (Nikita Borisov) Date: Wed, 22 Feb 2006 14:01:06 -0600 Subject: [OTR-dev] Command-Line OTR Proxy? In-Reply-To: <20060222174102.GP31096@smtp.paip.net> References: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> <20060222174102.GP31096@smtp.paip.net> Message-ID: <16f0378d0602221201h5d2f629dl3af058bd1e34b8a@mail.gmail.com> On 2/22/06, Ian Goldberg wrote: > On Mon, Feb 20, 2006 at 10:44:55PM -0500, Keith Beckman wrote: > > I've just installed OTR Proxy on Mac OS X 10.4.3, running on a > > PowerBook G4 500MHz. I've noted two things that would make it a much > > nicer program to run, in my opinion. The first is that the "quit" > > option doesn't work correctly. Rather than killing the proxy, it sits > > indefinitely with the file menu darkened and the proxy still running. > > It always requires a kill to shut the program down. > > Huh. Is this a known problem? Do other OSX people see this? This is a known problem. There are actually two quit menus in OTR Proxy: the one in the application menu ("OTR Proxy"), which will actually let you quit the proxy, and the one in the "File" menu, which will have the behaviour your describe. It has to do with some particulars of wxMac and how it tries to hack the wxWidgets way of creating menus into the Apple interface. This is something that I'd like to fix for the 1.0 version of OTR Proxy, but I don't know when I'll next have some time to look at it. If another OS X developer wants to take a stab at it, that would be great. - Nikita From Scott Ellis" References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> Message-ID: <96e269140602221616g2d076287h@mail.gmail.com> ------=_Part_11615_12305978.1140653762133 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 23/02/06, Ian Goldberg wrote: > > On Tue, Feb 21, 2006 at 08:08:37PM +1100, Scott Ellis wrote: > > > >I'm not sure I understand here. It looks like you're passing the > string > > > >"OTR" as the first parameter to otrl_proto_default_query_msg() when > the > > > >user selects "start OTR" instead of passing the account name. > > > > > > Yes that's what i pass in. In miranda there aren't different accounts - > only > > different protocols. It is possible to have e.g. two MSN 'accounts' but > you > > do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll o= r > the > > like, and miranda treats it as a seperate protocol. > > Wow. That *is* a hack. Surely there's a way to extract your account > name, though? There really isn't the concept of an account name in miranda...I can get th= e protocol name, or the protocol unique identifier (e.g. UIN) which may not b= e human readable...or, which is about the closest thing, the name of the user's database file - but that is often 'default' or something like that. I guess what I'm suggesting is that the library do some processing of the query message even when the policy is 'never'. > So, in the plugin there > > is only one account - i called it OTR, since i didn't think it'd make a > > difference. What I meant to point out is, since the username is passed > into > > that function also, shouldn't the username be used in this message? > > The remote username? That's not passed in: > > /* Return a pointer to a newly-allocated OTR query message, customized > * with our name. The caller should free() the result when he's done > * with it. */ > char *otrl_proto_default_query_msg(const char *ourname, OtrlPolicy > policy); Sorry, I mean't the username is passed into the 'receieve' function, on the receiver side - i misunderstood your last post regarding that. ------=_Part_11615_12305978.1140653762133 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 23/02/06, Ian Goldberg <ian@cypherpunks= .ca> wrote:
On Tue, Feb 21, 2006 at 08:08:37= PM +1100, Scott Ellis wrote:
> > >I'm not sure I understand her= e.  It looks like you're passing the string
> > >"OTR" as the first parameter to otrl_proto_defa= ult_query_msg() when the
> > >user selects "start OTR"= ; instead of passing the account name.
>
>
> Yes that's w= hat i pass in. In miranda there aren't different accounts - only
> different protocols. It is possible to have e.g. two MSN 'accounts= ' but you
> do that using a 'hack' - i.e. you copy the msn.dll plugin= to msn2.dll or the
> like, and miranda treats it as a seperate proto= col.

Wow.  That *is* a hack.  Surely there's a way t= o extract your account
name, though?
 
There really isn't the concept of an account name in miranda...I can g= et the protocol name, or the protocol unique identifier (e.g. UIN) which ma= y not be human readable...or, which is about the closest thing, the name of= the user's database file - but that is often 'default' or something like t= hat.
 
I guess what I'm suggesting is that the library do some proc= essing of the query message even when the policy is 'never'.

> So, in the plugin there
= > is only one account - i called it OTR, since i didn't think it'd make = a
> difference. What I meant to point out is, since the username is pa= ssed into
> that function also, shouldn't the username be used in thi= s message?

The remote username?  That's not passed in:
=
/* Return a pointer to a newly-allocated OTR query message, customized
* with our name.  The caller should free() the result when he= 's done
* with it. */
char *otrl_proto_default_query_msg(const char *= ourname, OtrlPolicy policy);
 
Sorry, I mean't the username is passed into the 'receieve' functi= on, on the receiver side - i misunderstood your last post regarding that.
------=_Part_11615_12305978.1140653762133-- From Scott Ellis" References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> <20060222145508.GJ31096@smtp.paip.net> Message-ID: <96e269140602221617y1b1d1bf0w@mail.gmail.com> ------=_Part_11627_1557026.1140653825090 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline guess i ought to get the cvs version of the source, huh? :) i've been working from the archive on the website. sorry - i know better. On 23/02/06, Ian Goldberg wrote: > > On Tue, Feb 21, 2006 at 10:52:50PM -0500, Evan Schoenberg wrote: > > The flags problem _should_ be fixed in HEAD -- I emailed with Ian > > about it previously. > > It is, in fact. The fix was checked in in November. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > ------=_Part_11627_1557026.1140653825090 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline guess i ought to get the cvs version of the source, huh? :) i've been worki= ng from the archive on the website. sorry - i know better.

On 23/02/06, Ian Goldberg <ian@cypherpunks= .ca> wrote:
On Tue, Feb 21, 2006 at 10:52:50= PM -0500, Evan Schoenberg wrote:
> The flags problem _should_ be fixe= d in HEAD -- I emailed with Ian
> about it previously.

It is, in fact.  The fix was= checked in in November.

  - Ian
______________________= _________________________
OTR-dev mailing list
OTR-dev@lists.cypherpunks.ca
http://lists.cypherpunks.ca/mailman/listinfo/otr-= dev

------=_Part_11627_1557026.1140653825090-- From ian@cypherpunks.ca Thu Feb 23 00:34:51 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 19:34:51 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221616g2d076287h@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> Message-ID: <20060223003451.GF31096@smtp.paip.net> On Thu, Feb 23, 2006 at 11:16:02AM +1100, Scott Ellis wrote: > > Wow. That *is* a hack. Surely there's a way to extract your account > > name, though? > > There really isn't the concept of an account name in miranda...I can get the > protocol name, or the protocol unique identifier (e.g. UIN) which may not be > human readable...or, which is about the closest thing, the name of the > user's database file - but that is often 'default' or something like that. In what protocols is the "unique identifier" not human-readable? Is this not the string that someone else would type in to their IM client in order to send you a message? If not, I'd think there's got to be a way to determine what that string is. > I guess what I'm suggesting is that the library do some processing of the > query message even when the policy is 'never'. > > Sorry, I mean't the username is passed into the 'receieve' function, on the > receiver side - i misunderstood your last post regarding that. Ah, but that message (generated by the sender) needs to be readable and make sense to someone that really *doesn't* have an OTR plugin. So you can't rely on the receiver to fill in the sender's name properly. - Ian From Scott Ellis" References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> Message-ID: <96e269140602221734j2a51dda7g@mail.gmail.com> ------=_Part_12239_7386622.1140658486511 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 23/02/06, Ian Goldberg wrote: > > On Thu, Feb 23, 2006 at 11:16:02AM +1100, Scott Ellis wrote: > > > Wow. That *is* a hack. Surely there's a way to extract your account > > > name, though? > > > > There really isn't the concept of an account name in miranda...I can ge= t > the > > protocol name, or the protocol unique identifier (e.g. UIN) which may > not be > > human readable...or, which is about the closest thing, the name of the > > user's database file - but that is often 'default' or something like > that. > > In what protocols is the "unique identifier" not human-readable? Is > this not the string that someone else would type in to their IM client > in order to send you a message? If not, I'd think there's got to be a > way to determine what that string is. e.g ICQ - the UIN is just a number - readable but not meaningful to me. The nickname they're given on the receiving end (if any) is not necessarily known to the sender > I guess what I'm suggesting is that the library do some processing of the > > query message even when the policy is 'never'. > > > > Sorry, I mean't the username is passed into the 'receieve' function, on > the > > receiver side - i misunderstood your last post regarding that. > > Ah, but that message (generated by the sender) needs to be readable and > make sense to someone that really *doesn't* have an OTR plugin. So you > can't rely on the receiver to fill in the sender's name properly. yes I realise that - but it's prefixed with the ?OTR? thing - so if there does happen to be an otr plugin on the receiving end, and if the message ha= d some sort of recognisable standard content (e.g. i've modified the lib to remove html tags, so straight strcmp wouldn't work) then the receiver could do something more useful with it - and also fill in the nickname of the sender ------=_Part_12239_7386622.1140658486511 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 23/02/06, Ian Goldberg <ian@cypherpunks= .ca> wrote:
On Thu, Feb 23, 2006 at 11:16:02= AM +1100, Scott Ellis wrote:
> > Wow.  That *is* a hack.=   Surely there's a way to extract your account
> > name, though?
>
> There really isn't the concept = of an account name in miranda...I can get the
> protocol name, or the= protocol unique identifier (e.g. UIN) which may not be
> human reada= ble...or, which is about the closest thing, the name of the
> user's database file - but that is often 'default' or something li= ke that.

In what protocols is the "unique identifier" not = human-readable?  Is
this not the string that someone else woul= d type in to their IM client
in order to send you a message?  If not, I'd think there's go= t to be a
way to determine what that string is.
 
e.g ICQ - the UIN is just a number - readable but not meaningful to me= . The nickname they're given on the receiving end (if any) is not nece= ssarily known to the sender

> I guess what I'm suggesting= is that the library do some processing of the
> query message even w= hen the policy is 'never'.
>
> Sorry, I mean't the username is passed into the 'receieve'= function, on the
> receiver side - i misunderstood your last post re= garding that.

Ah, but that message (generated by the sender) needs t= o be readable and
make sense to someone that really *doesn't* have an OTR plugin. &n= bsp;So you
can't rely on the receiver to fill in the sender's name prope= rly.
 
yes I realise that - but it's prefixed with the ?OTR? thing - so if th= ere does happen to be an otr plugin on the receiving end, and if the messag= e had some sort of recognisable standard content (e.g. i've modified the li= b to remove html tags, so straight strcmp wouldn't work) then the receiver = could do something more useful with it - and also fill in the nickname of t= he sender
------=_Part_12239_7386622.1140658486511-- From evan.s@dreskin.net Thu Feb 23 14:22:19 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Thu, 23 Feb 2006 09:22:19 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221734j2a51dda7g@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> <96e269140602221734j2a51dda7g@mail.gmail.com> Message-ID: <14A38819-8376-48F1-88B2-D4C9200BA09D@dreskin.net> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--811417602 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 22, 2006, at 8:34 PM, Scott Ellis wrote: > e.g ICQ - the UIN is just a number - readable but not meaningful to > me. The nickname they're given on the receiving end (if any) is not > necessarily known to the sender Readable and completely meaningful. It's the only identifying characteristic for an ICQ contact. Among other things, you can look up the person's name in the web directory, presumably you can do a Get Info request in Miranda to learn more about the contact, etc. -Evan --Apple-Mail-1--811417602 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD/cUbI5gp6xQhrvcRApcSAJ9a+GWDBx5xGp88OoNaVQhpNVCzAwCg1twJ aRya0fUz/uf6PVIBB3rjsTU= =A2W1 -----END PGP SIGNATURE----- --Apple-Mail-1--811417602-- From ian@cypherpunks.ca Thu Feb 23 14:49:26 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 23 Feb 2006 09:49:26 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221734j2a51dda7g@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> <96e269140602221734j2a51dda7g@mail.gmail.com> Message-ID: <20060223144926.GL31096@smtp.paip.net> On Thu, Feb 23, 2006 at 12:34:46PM +1100, Scott Ellis wrote: > > In what protocols is the "unique identifier" not human-readable? Is > > this not the string that someone else would type in to their IM client > > in order to send you a message? If not, I'd think there's got to be a > > way to determine what that string is. > > e.g ICQ - the UIN is just a number - readable but not meaningful to me. The > nickname they're given on the receiving end (if any) is not necessarily > known to the sender That's certainly true. But the account name is certainly better for a non-OTR person to see than something else. > > Ah, but that message (generated by the sender) needs to be readable and > > make sense to someone that really *doesn't* have an OTR plugin. So you > > can't rely on the receiver to fill in the sender's name properly. > > yes I realise that - but it's prefixed with the ?OTR? thing - so if there > does happen to be an otr plugin on the receiving end, and if the message had > some sort of recognisable standard content (e.g. i've modified the lib to > remove html tags, so straight strcmp wouldn't work) then the receiver could > do something more useful with it - and also fill in the nickname of the > sender You don't need standard content: the "?OTR?" is enough to indicate what's going on, *if* the user has an active OTR plugin that just happens to be set to "Never" for this contact. How common is that, though? In what situations do I want OTR *not* to start, *even if* the other guy pushes the "Start OTR" button? Does this come up a lot for other people? Thanks, - Ian From Etan Reisner Fri Feb 24 03:33:20 2006 From: Etan Reisner (Etan Reisner) Date: Thu, 23 Feb 2006 22:33:20 -0500 (EST) Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: On Fri, 17 Feb 2006, Evan Schoenberg wrote: > (Please reply-to-all, as I'm sending this to both relevant lists) > > AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any > other gaim plugin-based encryption scheme. > > 1) User sends message in Gaim > 2) Gaim gives plugins an opportunity to modify the message; an encryption > plugin such as gaim-otr encrypts the message if appropriate, returning the > encrypted message > 3) Gaim sends the encrypted message to the prpl > 4) In the case of oscar within a DirectIM session, the message is normally > post-processed, looking for tags, which reference ids from the gaim img > store in the form where gaim_imgstore_get(2) will return the > GaimStoredImage* for the image. The image's data, size, etc. are inserted > into the message..... but the message is encoded, so such a tag isn't found, > and images can not be sent. > > A similar situation exists on the receiving side, where the prpl processes > the incoming message, looking for tags to convert to the gaim img store > and their corresponding IDs but sees only the gibberish of an encrypted > message. > > As I mentioned, this is not specific to the gaim-otr implementation but > rather a result of how the signals are set up. One solution I've come up > with is giving the prpl a chance to modify the outgoing message before it is > sent to plugins via a signal, and similarly call the prpl for final > post-processing of incoming messages after the first signal is sent when > receiving a message. > > Thoughts? > > Cheers, > Evan > www.adiumx.com I only partly understand the issue here, and I have next to know undertanding of the underlying encryption stuff, but couldn't a prpl that needs to do this processing just use the same signals that the encryption plugins use? And use the signal priority stuff to ensure that they come first, to facilitate this we can change the handful of GAIM_PRIORITY defines to be an enum with default levels for PRPL/ENCRYPTION/etc. Would that not solve at least some of the problems? Or is there something I'm missing? Does the prpl processing do funny things to the message that the plugins would have to know about to deal with or something? Would the prpls need to keep track of messages between the signal and the normal mechanism somehow? (Would we need to start tagging messages with per-conversation ids to make this work more easily?) -Etan From alex323@gmail.com Fri Feb 24 20:05:28 2006 From: alex323@gmail.com (Alex) Date: Fri, 24 Feb 2006 15:05:28 -0500 Subject: [OTR-dev] libotr API documentation Message-ID: <43FF6708.6050809@gmail.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig36F80B9DEE3E14C2FDAAFBFC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey. Does libotr have any API documentation that I could take a look at? I am coding an application that uses the library, and am looking at gaim-otr as my guide for now. If you want, I can write up a doc when I am done coding my application. - Alex --------------enig36F80B9DEE3E14C2FDAAFBFC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQIVAwUBQ/9nDYNsvbPFJtOPAQrKaA//byuRuTUa1Fdph5300JEGMDjJ12Uc6gCT BSi+HxPOenyEx6PSq26J9am8UzVwjKgt1EHPkVu+6DSoNKfXPwQMv6XPivRpwjng fIeL1YLtJkG/TCl61aoejKKVlaw3oYIhmSobfiPRJY5sClhjpnPWML2K19elq7ej oxtLDw9FVbl1BNcXbcyDFm5VgaXS/huk1j6MkYVqWsYH+TJ72wOh+vKgoL71GTlR 9raivt2J+U7Q3TqZZRQbRK5CeUx4DdVZrYuVvsugB/hmnkylD3l74sjFZbIt6Bs9 jXld0Vr6wgGRVpaupa1sIa/Tbw4ILbXQllTdObOvkTyxC/o9yvIAMA2rdm7so+4f SshllwpxwLa3ov70rNL1x10/PIXqmwzxsBbkzAgqG1EmQ5pvwwOWNfUDP1Sxdxx1 zKa6+t/FAZBTqhdJPgUWVWg6eIBfPZdVex2S3VQKIeRdkhoDMsj8y5t5qhGppURz ByHx0s8bPC0UCO73Aj5Zr7ZpVBRjCXp/P0mXwCkPENEb9Noty4d48AReyWtYkWFc QjRyJQWbN8Hdx6tz+KMIXAtAGQyjHoZEp5h8OUuhtqEWG0lVCxP6JP9wzjuzufHa OTP8Ly8vGtLDCaC3sKTq+ljh6PfS/nUIn8O7dlpDEIHTfxeg1Ojsrt45aEU9hjUt vZnBJUZz9Zw= =eBhL -----END PGP SIGNATURE----- --------------enig36F80B9DEE3E14C2FDAAFBFC-- From ian@cypherpunks.ca Fri Feb 24 20:31:10 2006 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 24 Feb 2006 15:31:10 -0500 Subject: [OTR-dev] libotr API documentation In-Reply-To: <43FF6708.6050809@gmail.com> References: <43FF6708.6050809@gmail.com> Message-ID: <20060224203110.GB31096@smtp.paip.net> On Fri, Feb 24, 2006 at 03:05:28PM -0500, Alex wrote: > Hey. Does libotr have any API documentation that I could take a look at? > I am coding an application that uses the library, and am looking at > gaim-otr as my guide for now. If you want, I can write up a doc when I > am done coding my application. Right now, it's just what's in libotr/README. If you'd like to write up better documentation, we'd love you to do it! :-) - Ian From evan.s@dreskin.net Sat Feb 25 23:28:59 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Sat, 25 Feb 2006 18:28:59 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-8--605817267 Content-Type: multipart/alternative; boundary=Apple-Mail-7--605817402 --Apple-Mail-7--605817402 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 23, 2006, at 10:33 PM, Etan Reisner wrote: > I only partly understand the issue here, and I have next to know > undertanding of the underlying encryption stuff, but couldn't a > prpl that needs to do this processing just use the same signals > that the encryption plugins use? And use the signal priority stuff > to ensure that they come first, to facilitate this we can change > the handful of GAIM_PRIORITY defines to be an enum with default > levels for PRPL/ENCRYPTION/etc. Would that not solve at least some > of the problems? Or is there something I'm missing? Does the prpl > processing do funny things to the message that the plugins would > have to know about to deal with or something? Would the prpls need > to keep track of messages between the signal and the normal > mechanism somehow? (Would we need to start tagging messages with > per-conversation ids to make this work more easily?) > > -Etan So long as the message signal allows access to the GaimConversation for the message (which it does IIRC), nothing needs to be added -- and I think this would work nicely, indeed, with the added bonus of minimal new code needing to be written. I just noticed that the 'sub away formatters' in AIM -- %n for name, % d for date, etc. -- are also broken in OTR chats for the same reason; gaim_str_sub_away_formatters() should be done in such a signal handler even outside of directIMs. -Evan --Apple-Mail-7--605817402 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 23, 2006, = at 10:33 PM, Etan Reisner wrote:

I only partly understand the = issue here, and I have next to know undertanding of the underlying = encryption stuff, but couldn't a prpl that needs to do this processing = just use the same signals that the encryption plugins use? And use the = signal priority stuff to ensure that they come first, to facilitate this = we can change the handful of GAIM_PRIORITY defines to be an enum with = default levels for PRPL/ENCRYPTION/etc. Would that not solve at least = some of the problems? Or is there something I'm missing? Does the prpl = processing do funny things to the message that the plugins would have to = know about to deal with or something? Would the prpls need to keep track = of messages between the signal and the normal mechanism somehow? (Would = we need to start tagging messages with per-conversation ids to make this = work more easily?)


-Etan

=

So long as the message signal allows access = to the GaimConversation for the message (which it does IIRC), nothing = needs to be added -- and I think this would work nicely, indeed, with = the added bonus of minimal new code needing to be written.

I just noticed that the = 'sub away formatters' in AIM -- %n for name, %d for date, etc. -- are = also broken in OTR chats for the same reason;=A0gaim_str_sub_away_formatters() should be done in = such a signal handler even outside of = directIMs.

-Evan
= --Apple-Mail-7--605817402-- --Apple-Mail-8--605817267 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEAOg8I5gp6xQhrvcRAso1AKDXRoY4JlHz97ooz1DzeHQP4AwnswCgszH/ B0dBQg9LQvrU5pho0oJqsO0= =1Swy -----END PGP SIGNATURE----- --Apple-Mail-8--605817267-- From mark@kingant.net Sat Feb 25 23:12:24 2006 From: mark@kingant.net (Mark Doliner) Date: Sat, 25 Feb 2006 18:12:24 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <20060225231205.M58983@kingant.net> On Thu, 23 Feb 2006 22:33:20 -0500 (EST), Etan Reisner wrote > On Fri, 17 Feb 2006, Evan Schoenberg wrote: > > (Please reply-to-all, as I'm sending this to both relevant lists) > > > > AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any > > other gaim plugin-based encryption scheme. > > > > 1) User sends message in Gaim > > 2) Gaim gives plugins an opportunity to modify the message; an encryption > > plugin such as gaim-otr encrypts the message if appropriate, returning the > > encrypted message > > 3) Gaim sends the encrypted message to the prpl > > 4) In the case of oscar within a DirectIM session, the message is normally > > post-processed, looking for tags, which reference ids from the gaim img > > store in the form where gaim_imgstore_get(2) will return the > > GaimStoredImage* for the image. The image's data, size, etc. are inserted > > into the message..... but the message is encoded, so such a tag isn't found, > > and images can not be sent. > > > > A similar situation exists on the receiving side, where the prpl processes > > the incoming message, looking for tags to convert to the gaim img store > > and their corresponding IDs but sees only the gibberish of an encrypted > > message. > > > > As I mentioned, this is not specific to the gaim-otr implementation but > > rather a result of how the signals are set up. One solution I've come up > > with is giving the prpl a chance to modify the outgoing message before it is > > sent to plugins via a signal, and similarly call the prpl for final > > post-processing of incoming messages after the first signal is sent when > > receiving a message. > > > > Thoughts? > > > > Cheers, > > Evan > > www.adiumx.com > > I only partly understand the issue here, and I have next to know > undertanding of the underlying encryption stuff, but couldn't a prpl > that needs to do this processing just use the same signals that the > encryption plugins use? And use the signal priority stuff to ensure > that they come first, to facilitate this we can change the handful > of GAIM_PRIORITY defines to be an enum with default levels for > PRPL/ENCRYPTION/etc. Would that not solve at least some of the > problems? Or is there something I'm missing? Does the prpl > processing do funny things to the message that the plugins would > have to know about to deal with or something? Would the prpls need > to keep track of messages between the signal and the normal > mechanism somehow? (Would we need to start tagging messages with per- > conversation ids to make this work more easily?) > > -Etan It sounds like that would work, and would be cleaner -Mark From evan.s@dreskin.net Mon Feb 27 18:40:20 2006 From: evan.s@dreskin.net (Evan Schoenberg) Date: Mon, 27 Feb 2006 13:40:20 -0500 Subject: [OTR-dev] Decrypting messages from an old OTR conversation Message-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-12--450336706 Content-Type: multipart/alternative; boundary=Apple-Mail-11--450336997 --Apple-Mail-11--450336997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I have a user bugging me about this, and I'm not sure how to respond. The problem: some services support serverside offline messaging. Yahoo and ICQ, for example. If Bob is in an encrypted conversation with Alice, and Alice signs offline, the service still allows Bob to message Alice, storing the (encrypted) message on the server for delivery when Alice next signs online. Bob knows that Alice has the information for decrypting his message, since they've been communicating previously... So Alice signs on a day later... but she can't read the message, since the conversation has since ended. She receives: The encrypted message received from Bob is unreadable, as you are not currently communicating privately. Any thoughts? -Evan --Apple-Mail-11--450336997 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I have a user bugging me about = this, and I'm not sure how to respond.

The problem: some services = support serverside offline messaging.=A0 Yahoo and ICQ, for example.=A0 = If Bob is in an encrypted conversation with Alice, and Alice signs = offline, the service still allows Bob to message Alice, storing the = (encrypted) message on the server for delivery when Alice next signs = online.=A0 Bob knows that Alice has the information for decrypting his = message, since they've been communicating previously...

So Alice signs on a day = later... but she can't read the message, since the conversation has = since ended.=A0 She receives:
The encrypted message = received from Bob is unreadable, as you are not currently communicating = privately.

Any = thoughts?

-Evan
= --Apple-Mail-11--450336997-- --Apple-Mail-12--450336706 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEA0eUI5gp6xQhrvcRAgQUAJ0U7FbADHumJKwKKucHO2J4VWzeDACbBhD1 2a3jwCwu5dbqW5/NyMQW7MA= =DMNj -----END PGP SIGNATURE----- --Apple-Mail-12--450336706-- From paul@cypherpunks.ca Mon Feb 27 19:08:38 2006 From: paul@cypherpunks.ca (Paul Wouters) Date: Mon, 27 Feb 2006 20:08:38 +0100 (CET) Subject: [OTR-dev] Decrypting messages from an old OTR conversation In-Reply-To: References: Message-ID: On Mon, 27 Feb 2006, Evan Schoenberg wrote: > The problem: some services support serverside offline messaging. Yahoo and > ICQ, for example. If Bob is in an encrypted conversation with Alice, and > Alice signs offline, the service still allows Bob to message Alice, storing > the (encrypted) message on the server for delivery when Alice next signs > online. Bob knows that Alice has the information for decrypting his message, > since they've been communicating previously... > > So Alice signs on a day later... but she can't read the message, since the > conversation has since ended. She receives: > The encrypted message received from Bob is unreadable, as you are not > currently communicating privately. When signing off, the client should close the OTR connection to the "finished" state. Paul -- "Do it today, tomorrow it will be illegal" --- Source unknown