[guardian-dev] OTR file transfer

Hans-Christoph Steiner hans at guardianproject.info
Thu Jun 6 14:28:10 EDT 2013


I like the idea of an HTTP header, that sounds quite useful.

.hc

On 06/05/2013 12:58 AM, Miron wrote:
> Abel,
> 
> I have the pure OTR approach implemented with a trivial test harness.  See:
> 
> https://github.com/guardianproject/Gibberbot/pull/210#issuecomment-18955457
> 
> One possible improvement is to add an HTTP style header to convey to the
> recipient some metadata, such as the MIME type.  Opinions?
> 
> On 06/03/2013 09:28 AM, Abel Luck wrote:
>> Georg Lukas:
>>> * Abel Luck <abel at guardianproject.info> [2013-06-03 17:19]:
>>>> There are two proposed mechanisms
>>>>
>>>> 1) XMPP+OTR: In-band byte streams using XEP-0047 with the symmetric key
>>>> being derived from OTRv4 TLV8
>>>
>>> AES256-CTR with HMAC-SHA512. What are the reasons for using CTR versus
>>> the other modes, its support of arbitrary payload length? Anything else?
>>>
>>> How is the CTR nonce derived / communicated to the other party?
>>>
>>> How is the use of OTR for the file transfer communicated during handshake?
>>>
>>> How does the other party obtain the HMAC value?
>>>
>> What are these questions addressing? I didn't link to any
>> implementations or specifications...
>>
>> ~abel
>>
>>>> 2) Pure OTR: A new TLV essentially providing in-band bytestreams at the
>>>> OTR layer
>>>
>>> I am not quite convinced by the second approach. From the client
>>> implementation perspective, that means all the file transfer logic needs
>>> to be done twice: once for regular insecure XEP-0096, and once again for
>>> file-transfer over OTR... Or maybe even a third time for Jingle file
>>> transfers... Even with the right internal abstractions this looks like a
>>> layer break to me... With the first approach, it would be possible to
>>> switch to a different transmission mechansim (OOB, Jingle) later on,
>>> e.g. to preserve bandwidth.
>>>
>>>
>>> Ge0rG
>>>
>>>
>>>
>>> _______________________________________________
>>> Guardian-dev mailing list
>>>
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>
>>> To Unsubscribe
>>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info
>>>
>>> You are subscribed as: abel at guardianproject.info
>>>
>>
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/c1.android%40niftybox.net
>>
>> You are subscribed as: c1.android at niftybox.net
>>
> 
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info
> 


More information about the Guardian-dev mailing list