in app (Java) crypt "file store"/ media cache ?
In app media cache ought be in a crypt by default. Has anyone done this before and can give hints? Platforms: initially android, but should be compilable for others including Linux Object types: avatars, tweets, associated media including images and even vids - whatever is in a standard social media 'stream'. Obviously cache needs to be parameterizable as to size, eviction policy, but it's not going to be unencrypted. Come to think of it, FreeNet's code might be good, at the very least as a tutorial - but experience is always valuable, so if you have some experience you can share, please do. To simplify eviction, objects should be separate files, compressed prior to saving, with one or more indices (also encrypted) for the application to do it's thing efficiently, including store, lookup, read and re-enrypt when an object is to be on-forwarded. Content addressed in some way of course - git has lead the way on this principle - we just must make sure that if the user does not give up his password, anything lying around must meet some minimum "hiddenness" standard. Possible libs: # Tuweni https://github.com/apache/incubator-tuweni https://tuweni.apache.org # Ancient Nacl-Java https://github.com/freeeve/nacl-java # looks like a one man band, not updated for 5yrs # Libsodium https://github.com/jedisct1/libsodium https://doc.libsodium.org/ https://doc.libsodium.org/bindings_for_other_languages # "complete security audit" # Seems to be used by Tuweni Docs: # Java Cryptography Architecture (JCA) Reference Guide https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/Crypt... Tutorials: https://www.tutorialspoint.com/java_cryptography/index.htm https://www.tutorialspoint.com/java_cryptography/java_cryptography_encryptin... # simple block encryption # Java - Asymmetric Cryptography example - Mkyong.com https://mkyong.com/java/java-asymmetric-cryptography-example/ https://github.com/amiralis/Java-crypto-tutorial Encrypting and Decrypting Files in Java | Baeldung https://www.baeldung.com/java-cipher-input-output-stream How to easily encrypt and decrypt text in Java https://www.adeveloperdiary.com/java/how-to-easily-encrypt-and-decrypt-text-... Encrypt and Decrypt file/stream in Java https://self-learning-java-tutorial.blogspot.com/2017/09/encrypt-and-decrypt...
The very idea of cache is unsecure by nature... it's almost always functionally unnecessary unless we're talking of things like memoization etc... but since you mention a "media" app, I guess that's a cache for pictures, videos etc... Good point is: if a media app wants to really focus on security should it use a caching system ? ---------- CRYPTOANALYZER ---------- Sent from ProtonMail, encrypted email based in Switzerland. Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 5 July 2020 г., 17:38, Zenaan Harkness <zen@freedbms.net> wrote:
In app media cache ought be in a crypt by default. Has anyone done this before and can give hints?
Platforms: initially android, but should be compilable for others including Linux
Object types: avatars, tweets, associated media including images and even vids - whatever is in a standard social media 'stream'.
Obviously cache needs to be parameterizable as to size, eviction policy, but it's not going to be unencrypted.
Come to think of it, FreeNet's code might be good, at the very least as a tutorial - but experience is always valuable, so if you have some experience you can share, please do.
To simplify eviction, objects should be separate files, compressed prior to saving, with one or more indices (also encrypted) for the application to do it's thing efficiently, including store, lookup, read and re-enrypt when an object is to be on-forwarded.
Content addressed in some way of course - git has lead the way on this principle - we just must make sure that if the user does not give up his password, anything lying around must meet some minimum "hiddenness" standard.
Possible libs:
Tuweni
=======
https://github.com/apache/incubator-tuweni https://tuweni.apache.org
Ancient Nacl-Java
==================
https://github.com/freeeve/nacl-java
looks like a one man band, not updated for 5yrs
================================================
Libsodium
==========
https://github.com/jedisct1/libsodium https://doc.libsodium.org/ https://doc.libsodium.org/bindings_for_other_languages
"complete security audit"
==========================
Seems to be used by Tuweni
===========================
Docs:
Java Cryptography Architecture (JCA) Reference Guide
=====================================================
https://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/Crypt...
Tutorials:
https://www.tutorialspoint.com/java_cryptography/index.htm https://www.tutorialspoint.com/java_cryptography/java_cryptography_encryptin...
simple block encryption
========================
Java - Asymmetric Cryptography example - Mkyong.com
====================================================
https://mkyong.com/java/java-asymmetric-cryptography-example/
https://github.com/amiralis/Java-crypto-tutorial
Encrypting and Decrypting Files in Java | Baeldung https://www.baeldung.com/java-cipher-input-output-stream
How to easily encrypt and decrypt text in Java https://www.adeveloperdiary.com/java/how-to-easily-encrypt-and-decrypt-text-...
Encrypt and Decrypt file/stream in Java https://self-learning-java-tutorial.blogspot.com/2017/09/encrypt-and-decrypt...
On Mon, Jul 06, 2020 at 12:38:52PM +0000, таракан wrote:
The very idea of cache is unsecure by nature... it's almost always functionally unnecessary unless we're talking of things like memoization etc... but since you mention a "media" app, I guess that's a cache for pictures, videos etc...
Good point is: if a media app wants to really focus on security should it use a caching system ?
Let's say you're doing a discussion forum, and you want to allow user's to upload their own avatars. Other user's viewing my posts, will normally want my avatar to show. Why would an app _not_ cache avatars? Similarly, if a meme image is popular and get's reposted in multiple separate discussion threads, the same question: why would the app re-download that image every time it has to display that image, or even after shutting down and restarting the app or device? Surely failing to cache such things is a needless deficiency which would be called a bug by most user's? (Modulo cache aging, purging etc.)
Surely failing to cache such things is a needless deficiency which would be called a bug by most user's?
I wouldn't call that a bug... caching is very,very error-prone and as I said inherently a security problem. In other area than computation, AI, etc... caching is generally used for multimedia applications. I consider it as a stupid technique in such area. Sensitive things should never be cached...
On Mon, Jul 06, 2020 at 02:30:44PM +0000, таракан wrote:
Surely failing to cache such things is a needless deficiency which would be called a bug by most user's?
I wouldn't call that a bug... caching is very,very error-prone and as I said inherently a security problem. In other area than computation, AI, etc... caching is generally used for multimedia applications. I consider it as a stupid technique in such area. Sensitive things should never be cached...
Cahe enable/disable shall be a setting - that is trivial to do. Then the question of default rises. Failure to cache things that the user expects to be cached, is really irritating - firefox bugged me for years, despite many attempts to force caching of everything... We can also do something inbetween - e.g. have pop-up menu to swap current default setting for this item, or purge entire cache, or backup to another instance (say, from phone to your workstation across a local or ad-hoc wireless) any useful functions the user might want, with different defaults a click away :)
On Tue, Jul 07, 2020 at 04:32:11AM +1000, Zenaan Harkness wrote:
On Mon, Jul 06, 2020 at 02:30:44PM +0000, таракан wrote:
Surely failing to cache such things is a needless deficiency which would be called a bug by most user's?
I wouldn't call that a bug... caching is very,very error-prone and as I said inherently a security problem. In other area than computation, AI, etc... caching is generally used for multimedia applications. I consider it as a stupid technique in such area. Sensitive things should never be cached...
Cahe enable/disable shall be a setting - that is trivial to do.
Then the question of default rises.
Failure to cache things that the user expects to be cached, is really irritating - firefox bugged me for years, despite many attempts to force caching of everything...
We can also do something inbetween - e.g. have pop-up menu to swap current default setting for this item, or purge entire cache, or backup to another instance (say, from phone to your workstation across a local or ad-hoc wireless) any useful functions the user might want, with different defaults a click away :)
Also, the idea at least is P2P, so for e.g. avatars and images, if you don't cache, you'd be hitting your peers up each time you need to reload the resource. But your thought is very useful - the more fundamental issue here is "types of social media streams": - Twitter/facebook are like an endless forum - a stream of consciousness of photos of breakfast and coffee, and endless inane irrelevancies; as disheartening as the majority of this is, folks have a right to speak their inanity. - Email is longer tweets/wall posts. - Forums are similar to both. - Chat rooms are more ephemeral. Some folks will want archiving (long term cache) for all typesof streams. Others will want to create "ephemeral" chats and ensure no local cache, at least after whatever the discussion is they just had. In the strict P2P concept, your friends or contacts may well get annoyed if you keep hitting their phone with requests for the same image for example. There are many use cases and considerations in the social media design space...
In the strict P2P concept, your friends or contacts may well get annoyed if you keep hitting their phone with requests for the same image for example.
Caching and decentralized content are 2 different things I guess Well this is a mailing list of people who, more or less, are using technology and/or cryptographic science to ensure privacy for "anyone"... In such a task, caching appears futile, unnecessary and an obvious risk. Therefore, better not to even considering it, that solves the issues. I develop an embedded system for a secure communication station. I want everything to stays transient, to be erased as soon and as fast as possible. I don't want that it is possible to scan the memory to intercept any variable, deciphered stuff etc... In that communication station, communications can be eventually extremely scarce, internet very slow in extreme environments with all sort of modems involved. Since this is a secure communication station, the last thing I want is to cache anything, simply because that is a secure system. The received data are stored in encrypted external components. Etc...
On Mon, Jul 06, 2020 at 11:15:01PM +0000, таракан wrote:
In the strict P2P concept, your friends or contacts may well get annoyed if you keep hitting their phone with requests for the same image for example.
Caching and decentralized content are 2 different things I guess
Well this is a mailing list of people who, more or less, are using technology and/or cryptographic science to ensure privacy for "anyone"...
In such a task, caching appears futile, unnecessary and an obvious risk. Therefore, better not to even considering it, that solves the issues.
I develop an embedded system for a secure communication station. I want everything to stays transient, to be erased as soon and as fast as possible. I don't want that it is possible to scan the memory to intercept any variable, deciphered stuff etc...
In that communication station, communications can be eventually extremely scarce, internet very slow in extreme environments with all sort of modems involved.
Since this is a secure communication station, the last thing I want is to cache anything, simply because that is a secure system. The received data are stored in encrypted external components.
Etc...
Sounds like a relatively high security setup - this would likely be beyond the average user. This distributed/decentral content is interesting - I've been thinking of "cache" as the local node's "contribution" to the distributed P2P content store. In this context, some devices might be considered bridge or entry nodes as Tor call's them, but once a user start's viewing content, I had not imagined that their device for reading and responding would _not_ cache files, at a minimum for a session. In this early "explore the space" trial, I'm looking at the workings of such an app, so I can hopefully get a better understanding of the overall network and user needs. Also, despite the monumental first mover advantage that the incumbent _centralised_ social media giants have over everything, I still hope that one day something fully decentral might by some fluke of providence be at least marginally successful enough to provide an "off the grid" alternative. So in this decentral context, all "servers" are legacy or at least they "cannot be relied upon". So how do we design for this is the next question - "servers" must be as trivial as a hash tag, and this has implications. Each end user desired node is a use case - there is evident value e.g. in separation of one's Internet/overlay entry node, and one's browsing node. But I think that the use case of a cache-free browsing node needs more consideration: How do we avoid a node "hitting up their peer nodes for the same media object repeatedly"? In P2P, nodes must collectively provide the content store - how do they do this? Perhaps the "local distributed partial store", if a node has one, is never accessed by the local node? Possible I guess - had not thought of this, and there's no reason this could not work if it's useful, but it might bring pressure to simplify "offline replication into a secure vault/ encrypted store, for offline browsing of your past conversations". And once you have an offline vault sink, say a mounted Veracrypt volume, then why not also use this to store avatar icons? Once again, we're back to a form of local cache, albeit a little more complex for the user to set up - in that case, the pocial media client could be split into separate apps if it makes user's feel safer (may be there's already a Veracrypt for Android?), or if you have a local "browsing" computer, perhaps a "favoured peer node" (on your workstation) could serve all cache requests when that node is contactable so that your "browsing" node never caches? Once a use case is properly understood, it can be properly provided for... (BTW, in my initial concept tests, I'm implementing a social media client test ui, in order to understand the issues. Networking could run over Tor, I2P, clear net, or some future overlay.)
On Mon, Jul 06, 2020 at 11:15:01PM +0000, таракан wrote:
I develop an embedded system for a secure communication station. I want everything to stays transient, to be erased as soon and as fast as possible.
The authorities are more interested in the metadata, who is communicating with whom. To reduce the value of this information, needs to be embedded in a flood of unimportant chats. On 2020-07-07 11:55, Zenaan Harkness wrote:
This distributed/decentral content is interesting - I've been thinking of "cache" as the local node's "contribution" to the distributed P2P content store.
The strong cure for revealing metadata is to embed private communications in a pool of everyone to everyone public communications. Suppose everyone interested in signing or encrypting their tests in this pool as a Zooko identity. Encrypted messages are dumped into the pool with everything else, and downloaded by everyone, but if he does not have a key that can decrypt an encrypted message, his client does not show him that message. Let S be curve25519 public key of the sender, R the public key of the recipient, r and s the corresponding private keys. The message starts with S. It is encrypted using the symmetric key s*R. The recipient client software tries the symmetric key r*S, which, if the message is for him rather than someone else, is going to equal s*R. If it does not work, obviously for someone else.
On Tue, Jul 07, 2020 at 01:09:06PM +1000, jamesd@echeque.com wrote:
On Mon, Jul 06, 2020 at 11:15:01PM +0000, таракан wrote:
I develop an embedded system for a secure communication station. I want everything to stays transient, to be erased as soon and as fast as possible.
The authorities are more interested in the metadata, who is communicating with whom. To reduce the value of this information, needs to be embedded in a flood of unimportant chats.
Indeed.
On 2020-07-07 11:55, Zenaan Harkness wrote:
This distributed/decentral content is interesting - I've been thinking of "cache" as the local node's "contribution" to the distributed P2P content store.
The strong cure for revealing metadata is to embed private communications in a pool of everyone to everyone public communications.
Suppose everyone interested in signing or encrypting their tests in this pool as a Zooko identity.
Thanks for the Zooko reference - these days, the flood of material can be a problem to getting up to speed.. had yet to see the name Zooko - Keybase being read now (just not a social media user here..)
Encrypted messages are dumped into the pool with everything else, and downloaded by everyone, but if he does not have a key that can decrypt an encrypted message, his client does not show him that message.
Let S be curve25519 public key of the sender, R the public key of the recipient, r and s the corresponding private keys.
The message starts with S. It is encrypted using the symmetric key s*R.
The recipient client software tries the symmetric key r*S, which, if the message is for him rather than someone else, is going to equal s*R. If it does not work, obviously for someone else.
Keybase solves certain problems in apparently right ways. Thanks again,
The authorities are more interested in the metadata, who is communicating with whom. To reduce the value of this information, needs to be embedded in a flood of unimportant chats.
Yes this is an old technique called steganography. This is roughly the same as publishing the date of the attack by a foreign army to a given target inside thousands of other - unimportant - dates, like wedding ceremonies published openly. 2020-05-22 21:00 2020-01-14 21:00 2020-06-27 14:00 2020-03-05 19:00 2020-03-05 22:00 2020-02-19 17:00 2020-01-11 13:00 2020-01-12 05:00 2020-06-09 04:00 2020-04-12 03:00 2020-02-08 23:00 2020-04-09 12:00 2020-05-06 02:00 2020-01-20 09:00 2020-06-26 01:00 2020-05-03 14:00 2020-05-14 15:00 2020-02-27 21:00 2020-04-26 18:00 2020-06-10 19:00 2020-02-25 12:00 2020-04-01 11:00 2020-07-07 10:00 2020-06-12 19:00 2020-06-13 17:00 2020-03-02 09:00 2020-04-06 18:00 2020-01-11 00:00 2020-02-07 11:00 2020-05-19 20:00 2020-01-15 16:00 2020-05-26 08:00 2020-06-21 05:00 2020-01-11 01:00 2020-03-07 13:00 2020-06-16 16:00 2020-03-19 13:00 2020-05-05 17:00 2020-01-20 17:00 2020-04-18 15:00 2020-05-13 23:00 2020-07-02 06:00 2020-03-23 22:00 2020-01-25 12:00 2020-06-19 01:00 2020-05-09 06:00 2020-03-01 10:00 2020-01-14 11:00 [date of the attack] 2020-07-04 18:00 2020-03-15 14:00 2020-01-21 00:00 2020-06-19 21:00 2020-01-09 16:00 2020-03-18 05:00 2020-02-01 21:00 2020-01-05 10:00 2020-05-26 08:00 2020-05-08 15:00 2020-06-13 20:00 2020-01-30 20:00 2020-01-19 14:00 2020-04-08 17:00 2020-04-25 22:00 2020-01-02 03:00 2020-05-23 10:00 2020-02-10 22:00 2020-03-22 22:00 2020-01-18 10:00 2020-03-22 08:00 2020-06-29 03:00 2020-04-06 20:00 2020-06-13 11:00 2020-06-30 18:00 2020-06-20 14:00 2020-06-15 01:00 2020-06-28 11:00 2020-03-14 12:00 2020-06-20 05:00 2020-02-19 05:00 2020-02-15 07:00 2020-04-10 04:00 2020-03-26 02:00 2020-06-03 11:00 2020-02-20 13:00 2020-02-07 00:00 2020-04-18 19:00 2020-01-16 20:00 2020-01-28 22:00 2020-03-18 15:00 2020-05-14 06:00 2020-06-23 06:00 2020-05-16 15:00 2020-05-15 23:00 2020-06-21 20:00 2020-06-18 10:00 2020-04-12 06:00 2020-02-12 15:00 2020-03-24 10:00 2020-06-17 17:00 2020-04-10 17:00
participants (3)
-
jamesd＠echeque.com -
Zenaan Harkness -
таракан