11–20 of 39 posts
asymmetric key encryption is quite cpu intensive comparing to , say AES256. why not use the asymmetric keypair to guard an AES key, and use AES to do the encryption instead, something like what https is doing.
"Every time a new file is being written, owefs_encrypt creates a one-time random key. The random key is encrypted using the public key and is embedded in the new file. The contents of the file are encrypted using such random key."
Exposing filenames in the clear like that is a significant drawback. I'm not sure how you could get around it, though.
http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level...
https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa...
asymmetric key encryption is quite cpu intensive comparing to , say AES256. why not use the asymmetric keypair to guard an AES key, and use AES to do the encryption instead, something like what https is doing.
That is exactly what the project does: "Every time a new file is being written, owefs_encrypt creates a one-time random key. The random key is encrypted using the public key and is embedded in the new file. The contents of the file are encrypted using such random key."
> Some files may need to be written while the device is locked. A good example of this is a mail attachment downloading in the background. This behavior is achieved by using asymmetric elliptic curve cryptography (ECDH over Curve25519). The usual per-file key is protected by a key derived using One-Pass Diffie-Hellman Key Agreement as described in NIST SP 800-56A.
> The ephemeral public key for the agreement is stored alongside the wrapped per-file key. The KDF is Concatenation Key Derivation Function (Approved Alternative 1) as described in 5.8.1 of NIST SP 800-56A. AlgorithmID is omitted. PartyUInfo and PartyVInfo are the ephemeral and static public keys, respectively. SHA-256 is used as the hashing function. As soon as the file is closed, the per-file key is wiped from memory. To open the file again, the shared secret is re-created using the Protected Unless Open class’s private key and the file’s ephemeral public key; its hash is used to unwrap the per-file key, which is then used to decrypt the file.
Heads up to anyone considering using this: the author wrote their own crypto code[1]. I would recommend against using this until that is fixed... I've already spotted a few vulnerabilities. [1] https://github.com/FedericoCeratto/owefs/blob/master/pycrypt...
Heads up to anyone considering using this: the author wrote their own crypto code[1]. I would recommend against using this until that is fixed... I've already spotted a few vulnerabilities. [1] https://github.com/FedericoCeratto/owefs/blob/master/pycrypt...
I don't necessarily disagree, but at some point the buck has to stop, right? How would you implement this any other way? The author didn't implement AES or so on himself, he uses standard library encryption and applies it as appropriate. You should probably report the issues you find to federico.ceratto-at-gmail.com (from Github).
Exposing filenames in the clear like that is a significant drawback. I'm not sure how you could get around it, though.
Perhaps I'm missing something obvious, but why can't the filename be encrypted as well? (So you have public key 0xDEAFBEEF; you want to write a file named 'secret.txt' with the contents 'We attack at dawn'. OweFS encrypts 'We attack at dawn' to 010101 and writes that to 'secret.txt'. But why couldn't it have encrypted the contents to 010101 and encrypted the filename 'secret.txt' to 111000, and then written a file na…
Firstly, let's assume that directories aren't encrypted. Otherwise this would be a real PITA - just to locate /foo/bar/baz.txt you'd have to decrypt each component of 001001/011101/110101.encrypted separately.
More importantly, the decrypting software has no way to encrypt things, only decrypt them. So to read 'secret.txt' you can't just encrypt 'secret.txt' to '111000.encrypted'. Instead, you have to iterate through the entire directory listing and decrypt every single filename, until you find one that decrypts to 'secret.txt'.
Obviously this gets pretty bad with even moderately-sized directories. I assume this is why the project doesn't encrypt filenames.