<div dir="ltr">What are the main disadvantages to an NDK build of libotr / libgcrypt? The main issue seems that you need to include binaries for multiple architectures that can increase app size significantly. However having two actively maintained implementations could be good for diversity.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 10:02 AM, Nathan of Guardian <span dir="ltr"><<a href="mailto:nathan@guardianproject.info" target="_blank">nathan@guardianproject.info</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 09/06/2013 12:40 PM, Mike Minor wrote:<br>
> I thought I might poke some discussion as to where the weaknesses might be in an OTR implementation where you are using the currently known best practices (verifying fingerprints, etc)<br>
</div>Excellent point, and true that if there were mass MITM on OTR sessions,<br>
those of us who do verify would notice.<br>
<br>
One fear I have had has been around OTR4J (which we use in Gibberbot,<br>
and others like Jitsi do as well) and our dependency on BouncyCastle<br>
libraries, and Java, as well for that.<br>
<br>
With the recent weakness found in the Android PRNG, I fear there may be<br>
other "oops" bugs, either intentional or not, somewhere in that stack.<br>
<span class="HOEnZb"><font color="#888888"><br>
+n<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OTR-users mailing list<br>
<a href="mailto:OTR-users@lists.cypherpunks.ca">OTR-users@lists.cypherpunks.ca</a><br>
<a href="http://lists.cypherpunks.ca/mailman/listinfo/otr-users" target="_blank">http://lists.cypherpunks.ca/mailman/listinfo/otr-users</a><br>
</div></div></blockquote></div><br></div>