Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OMEMO Media Sharing via HTTP File Upload #317

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

vanitasvitae
Copy link
Member

@vanitasvitae vanitasvitae commented May 3, 2019

This PR adds support for OMEMO Media Sharing to Smacks HttpFileUploadManager.

The manager can now upload files encrypted to the server. As a result the user gets a aesgcm url-string which can be shared with others. There is also a function that retrieves a Cipher from an aesgcm string, which can then be used to decrypt the file/stream.

Since OMEMO Media Sharing is basically independent of OMEMO, I chose the HttpFileUploadManager as the best place to implement this feature.

There are also some changes to other packages. StringUtils now contains a method to decode hexadecimal Strings into byte arrays and the OMEMO code can generate IVs more flexible in order to prepare for the switch from 16 byte IVs to 12 byte IVs.

Missing:

  • decide, whether or not Smack should provide a function to convert a aesgcm string into a URL
  • figure out, whether a aesgcm:// url should be translated to http or https

    Note: HTTP Upload has transport encryption as a MUST. Non HTTPS URLs MUST not be converted to the aesgcm URL scheme.

  • maybe create custom data type for aesgcm urls?
  • code clean up
  • decide, if a method to download + decrypt files would be necessary

    naah

  • get feedback
  • squash

@vanitasvitae vanitasvitae changed the title WIP: OMEMO Media Sharing via HTTP File Upload OMEMO Media Sharing via HTTP File Upload May 3, 2019
@Flowdalic
Copy link
Member

Regarding the API design you probably should keep https://issues.igniterealtime.org/browse/SMACK-867 in mind.

@vanitasvitae
Copy link
Member Author

I'm not quite happy with this as of now. I'm not entirely sure, if I used the AlgorithmParameterSpecs correctly. Currently the decrypted file is 32 bytes longer than the original. This is probably the authentication tag and/or IV. However, since the tag length of AESGCM is configurable, I'm not sure, how one can calculate that length reliably when receiving a file.

@cmeng-git
Copy link
Contributor

aTalk v1.8.3 has implemented OMEMO Media Sharing using your source. Thanks for the contribution.

@vanitasvitae
Copy link
Member Author

The integration test does now no longer fail.

@Neustradamus
Copy link
Contributor

@vanitasvitae: Have you progressed on it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants