[guardian-dev] OTR file transfer

[Abel Luck]

I'm not opposed to the HTTP header idea, but I think mimetype should
just be handled by the receiver's system if we pass the filename+extension?

~abel

Hans-Christoph Steiner:
> 
> 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
>>
> _______________________________________________
> 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
>