ZRTP can&#39;t be used for arbitrary encryption since the whole SAS thing is tied to voice media. And if you aren&#39;t going to check the SAS, I don&#39;t see the point of ZRTP - you could just use SRTP with self-signed certs and have the same protection.<div>
<br></div><div>I am sure that some firewalls can tap TLS, but that will trigger a MITM warning on properly-written software; it may be possible in an enterprise to suppress the MITM warning to facilitate this scenario. However, this does not mean that TLS is broken.</div>
<div><br><div class="gmail_quote">On Wed, Jan 14, 2009 at 4:15 PM, Earl <span dir="ltr">&lt;<a href="mailto:Large.Files@gmx.net">Large.Files@gmx.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">&gt; Aren&#39;t there also patent issues with ZRTP?<br>
<br></div>
If I remember correctly, ZRTP is open source, but patented to keep<br>
it from being mis-used by the bad guys. &nbsp;Phil explained his reasoning<br>
about this. &nbsp;GNU ZRTP exists, and a port to java is used in SIP-<br>
Communicator. &nbsp;So maybe the answer is patent yes, issues no.<br>
=======<br>
Dirk is right that file transfers should not be missing pieces or be corrupted.<br>
If RTP is throwing out UDP packets and hoping that most arrive, this is not<br>
good enough for file transfer. &nbsp;So the question how to do secure XMPP file<br>
transfer is still open.<br>
ZRTP was developed for voice, which implies UDP, but that does not mean<br>
that a software coder could not use the encryption routines to encode/decode<br>
a TCP/IP file transfer.<br>
<br>
As a non programmer, it seems to me that both UDP and TCP are data streams<br>
and either can have pseudo-random bits added to them. &nbsp;I see ZRTP in a broad<br>
sense as a crypto-enabler and not limited to being only a UDP scrambler.<br>
<br>
Phil developed ZRTP only as a UDP scrambler, but is it not easy to make it<br>
both a UDP and a TCP scrambler?. &nbsp;This would break the IETF standard,<br>
which is only for voice, unless the ZRTP spec was modified to allow scrambling<br>
both UDP and TCP streams. &nbsp;If XMPP should decide to use ZRTP, is it<br>
permissible / desirable / tolerable that an XMPP ZRTP+TCP spec be 1%<br>
different from the IETF ZRTP spec?<br>
<br>
I imagine, as a non programmer, that there is only a trivial difference between<br>
ZRTP massaging a UDP stream or a TCP stream, but I could be wrong if<br>
TCP has to resend some packets and this complicates things terribly.<br>
Skype seems to use one, single encryption enabler for text, voice, video,<br>
and file transfer. &nbsp;Why can not ZRTP do the same, or be modified to be<br>
a generic end-to-end encryption enabler? &nbsp;I see ZRTP as 99% crypto enabler<br>
and only 1% UDP scrambler. A good crypto implementation is very difficult,<br>
adding or subtracting bits to/from a datastream should be trivial (?).<br>
<br>
&gt; I don&#39;t think this is very realistic. As I said earlier there are lots of situations<br>
&gt; where this doesn&#39;t work at all (e.g. IVR). And even in human to human settings<br>
&gt; the available data suggests that people will not actually check the sas.<br>
<br>
One conclusion could be that IVR might inherently be less secure than human<br>
to human comms. &nbsp;Whether people check the SAS should have no impact on<br>
requiring it to be displayed. &nbsp;For example, just because some people do not<br>
fasten their seat belts, should not mean dropping the obligation to have them<br>
in autos.<br>
<br>
An off-topic note. &nbsp;Not only does a Chinese company claim to decrypt SSL,<br>
but a Google search for firewall decode ssl turns up 194k hits, among them<br>
&quot;Palo Alto Networks&#39; PA-4000 transparent /firewall/ claims to decrypt /SSL/<br>
traffic passing through it .....&quot; &nbsp;As Peter reminded us, this topic is for the<br>
security list.<br>
<br>
Regards, Earl<br>
</blockquote></div><br></div>