Comments (4)
I'm a strong believer in that the API should do the right thing and I think you have some good points here. I'm aware of this and this is definitely a limitation of any streaming API. This is the case because we've made a decision to use the least amount of memory possible in the API, so holding all the data in memory is not an option for us. The second option suggested which is to invent our own cryptographic construction (the notion of a block), which we'd rather not do just because there are a lot of tricky problems to deal with here, for example we need to make sure that the blocks form a hash mac chain, otherwise you can rearrange parts of the stream and still have the stream's mac be valid. We'd rather use publicly vetted crypto algorithms here, and might replace HMAC in the future. However, I agree we should definitely change the documentation to make that more clear.
We've decided to keep the InputStream abstraction because Java programmers love dealing and passing around streams rather than passing around byte arrays. This makes the API more compatible with other libraries because streams are so general, and it is the norm rather than the exception that reading would happen at several layers of abstraction higher than the crypto library just because Java. I think this is a very useful API if you consider that one of the most common ways streams are read in java is:
ByteArrayOutputStream bout = new ByteArrayOutputStream();
while ((read = in.read(buffer) == -1)) {
bout.write(buffer, 0, read);
}
We're planning to add some features to the Crypto api in the near future which will alleviate these concerns for people who don't mind using it, and don't have these deep abstraction layers:
Crypto {
get(x)InputStream(byte[] buffer);
get(x)InputStream(File file);
}
Which makes the Crypto lib own the writing to a buffer and a file and only passes back the buffer or File back only if it's valid which would I think address your concern.
I'm going to mark this as a enhancement request. You're welcome to submit a pull request if you're passionate about working on this.
from conceal.
What restrictions do we have on the format of the stream? I would like to propose modifying it to look like this:
block[0] || MAC(0 || block[0]) || block[1] || MAC(1 || block[1]) || ... || block[n] || MAC(n || block[n])
where all blocks but the last have a preselected, constant size. This way we can read a block at a time and verify it before returning any data from it. If that's acceptable, I will look for a well established way of doing something like this (I think this is secure by a simple application of MAC's security guarantees, but I may very well be missing something) and submit a pull request.
EDIT: Sorry, should have replied when I've really woken up. I will try to find a sufficiently vetted protocol that does something similar and get back if i do find it. If that wouldn't be convincing enough for you anyway, please say so.
from conceal.
I think what would have a huge impact on this project would be the implementation of the abstraction that I mentioned before:
Crypto {
get(x)InputStream(byte[] buffer);
get(x)InputStream(File file);
}
I'd rather not re-invent crypto constructions precisely because it's really difficult to get them right. For example in the suggested construction, let's say the attacker sees 2 messages:
m1 = b01 || b11
m2 = b02 || b12
the tags for these two messages would be (effectively)
t1 = Mac(0 || b01) || Mac(1 || b11)
t2 = Mac(0 || b02) || Mac(1 || b12)
an attacker could then guess a mac on a message m3
m3 = b01 || b12
t3 = Mac(0 || b01) || Mac (1 || b12)
breaking the mac security guarantee
I love that you're thinking of new schemes to make this library better. The point of this proof is not to shoot down your idea, but to stress the importance of peer review in security constructions.
If you would like to work on the other idea that I mentioned let me know 👍
from conceal.
I've changed the title of the issue to be less alarmist and to reflect the current state of the discussion.
from conceal.
Related Issues (20)
- Why not think about using the cpu feature like ANDROID_CPU_ARM64_FEATURE_AES?
- Native Crash!!! HOT 6
- [Question] Password based key derivation usage HOT 5
- native crash and app can't pickup the exception,Can this exception wrap with java exception,then i can catch it
- native crash on Samsung HOT 1
- README.md refers to deprecated crypto.getCipherOutputStream
- What do I need to know in order to encrypt elsewhere for Conceal to decrypt? HOT 3
- The speed of decrypting the file is twice faster than the speed of encrypting the same file
- How to save encrypted file to internal folder ?
- App crashed in native method
- Conflicts using in React Native project due to com.facebook.jni.DestructorThread HOT 3
- showing NoSuchMethodException on Android P when initialing the SoLoader HOT 10
- Incompatibility with the Facebook library Flipper
- Conflict with React Native in v2.0.2 HOT 6
- Subpar PBKDF2 performance
- PHP Implementation HOT 1
- signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) Native Crash in Google Play Console HOT 5
- App crashes when running as 64 bit version: `libfb.so is 64-bit instead of 32-bit` HOT 1
- Fatal signal 11 (SIGSEGV), code 2 upon file decryption.
- Native crash (conceal version 2.0.2) java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libfb.so HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conceal.