11–20 of 194 posts
If a passphrase was lost, the security of every past file would be at risk.
This is what has kept me from approaches like this in the past.
Earlier quoted context omitted.
According to their whitepaper the encryption keys stay on the device and can be only recovered with a seed phrase which Slik has no access to, allegedly. There is no source code to verify the details, but they use AES-GCM. That either requires hardware support or a technique called bitslicing to be secure, but it runs on the client, which is fine. The confidentiality of the data however might not be protected because…
We could definitely expand on the search protocol in our WhitePaper, thanks for the input! However, we provide client side search and not server side search, thus, our servers have no idea of what the user is searching. The keywords (along with other file metadata) are also encrypted using the user's key, so analyzing access patterns of the chunks, would not be possible for us.
Until you all are coerced by some legal authority to code a passphrase intercept into the client ala ProtonMail, right?
1) a Linux app
2) an Android app
3) on-demand syncing, aka "smart sync"Earlier quoted context omitted.
Great question - we just keep the encrypting keys on the user's device and in-memory. The keys are encrypted using the user's seed phrase that is only known to the user, and not to Slik. Feel free to read more implementation details in our WhitePaper - https://sliksafe.com/whitepaper.pdf
How do you prevent yourselves from serving a version of the web app that sends the user’s seed phrase to yourself? (A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)
How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
I'm trying to decode the trend for decentralized services. If you have a sec:
Q1: In your case, why did you opt for decentralized storage?
Q2: Which benefits do I get as a consumer that I wouldn't if this was encoded, but centralized with a lot of redundance?
Don't take me the wrong way, really trying to understand where this is all going.
Cheers
Isn't it impossible to really delete something from ipfs? I'd think that would make this dangerous, as any security flaw would be impossible to fix retroactively. Everything before the flaw would be compromised and can't be reencrypted safely. If a passphrase was lost, the security of every past file would be at risk. This is what has kept me from approaches like this in the past.
Isn't it impossible to really delete something from ipfs? I'd think that would make this dangerous, as any security flaw would be impossible to fix retroactively. Everything before the flaw would be compromised and can't be reencrypted safely. If a passphrase was lost, the security of every past file would be at risk. This is what has kept me from approaches like this in the past.
For me the problem with IPFS is - it is just not interesting enough. It's not a storage solution, it is distribution and caching mechanism. You can't really upload to IPFS, you can only publish via IPFS - the same way you publish via HTTP.
Earlier quoted context omitted.
How do you prevent yourselves from serving a version of the web app that sends the user’s seed phrase to yourself? (A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)
How is this problem specific to web apps? How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
An e2e Dropbox alternative would be great. Though for it to actually count as a Dropbox alternative (to me) it would need: 1) a Linux app 2) an Android app 3) on-demand syncing, aka "smart sync"