Self Encryption on the SAFE Network

Community Videos
82

A jist canny help it sometimes, but man convoy every time :wink:

2 Likes
83

Yeh, he thinks he can outskate me too [face to side, eyes wide]

1 Like
84

For anyone who’s still curious: based on one of the docs that I reread multiple time it actually looks like the AES key is based off of the hash of the current block and neighboring blocks, so the scheme doesn’t suffer from a known-plaintext attack (because it uses the current block). Could someone in fact confirm this is the case – i.e., that the AES is based off of the current chunk as well?

As it stands, I still don’t see a rationale for the XOR’ing (and in general, in security if a component is not required, you eliminate it to minimize your attack surface), but can’t see any glaring problems.

[Before everyone starts bashing me again: The reason I thought the AES key was not (partially) based off of the current chunk was because the video said it wasn’t and also @dirvine’s comments seem to confirm that was the case. But I was correct when I said that such a scheme (which is not the one seemingly used – but is the one described in the video and subsequent comments) has a major security issue.]

1 Like
85

Hello.
I am reading through some documents, currently “Autonomous Network”, and am suggested to read a prerequisite “Self Encrypting Data” by David Irvine. I have searched the Internet and can’t seem to find it. It would be nice if maidsafe.net had a search function, but it doesn’t. Can anyone give me a link to where I can find this document, and also “Peer to Peer Public Key Infrastructure”, also by David Irvine. . . . Thanks.

86
1 Like
87
1 Like
88

Is the self encryption code here: GitHub - maidsafe/self_encryption: file self encryptor?

Specifically:

    fn encrypt_chunk(&self, chunk_number: u32, content: Vec<u8>) -> Deferred<Vec<u8>,String> {
        // [TODO]: work out passing functors properly - 2015-03-02 07:00pm
        let kvp = self.get_pad_iv_key(chunk_number);
        Deferred::<Vec<u8>, String>::new(move ||{
            let enc = &encryption::encrypt(&content, &kvp.1[..], &kvp.2[..]).unwrap();
            Ok(xor(&enc, &kvp.0))
        })
    }

and this is the keygen:

   // [TODO]: use fixed width arrays here, derived
   // from key size of cipher used (compile time) - 2015-03-02 01:01am
    fn get_pad_iv_key(&self, chunk_number: u32) -> (Vec<u8>, Vec<u8>, Vec<u8>) {
        let mut vec = self.my_datamap.get_sorted_chunks()[chunk_number as usize].pre_hash.clone();
        let n_1 = self.get_previous_chunk_number(chunk_number);
        let n_1_vec = self.my_datamap.get_sorted_chunks()[n_1 as usize].pre_hash.clone();
        let n_2 = self.get_previous_chunk_number(n_1);
        let n_2_vec = self.my_datamap.get_sorted_chunks()[n_2 as usize].pre_hash.clone();

        vec.extend(n_1_vec[48..64].to_vec());
        vec.extend(n_2_vec[..].to_vec());

        (vec, n_1_vec[0..32].to_vec(), n_1_vec[32..48].to_vec())
    }

So for chunk_i the pad is the pre-hash of chunk_i and the AES key/IV are slices of the hash of chunk_i-1?

1 Like
89

I have asked the core dev (Brian Smith) responsible for maintaining this lib to get back to you when he gets a sec.

1 Like
90

Almost, So for chunk_i the pad is the pre-hash of chunk_i + i-1 (unused part) + i-2 (concatenated) and the AES key/IV are slices of the hash of chunk_i-1?

91

I’m assuming that was a statement, not a question.

Anyways, if I were to provide a case where knowing part of the plaintext of a file (e.g., a proper subset of chunks) allowed me to decrypt another part of the ciphertext of that file (e.g., a chunk not in that subset), would you then agree that the scheme is insecure?

92

XOR rulez OK :stuck_out_tongue_closed_eyes:

Is joas a fan of ROT13?.. or prefers everyone uses ROT26?

3 Likes
93

In the case you’ve outlined, having a proper subset of chunks means you’ve got encrypted content, so you’ll have to first explain how you came to know what the plaintext for them is?

1 Like
94

A good threat model takes into account the fact that the attacker might have partial knowledge of the plaintext.

Imagine downloading a web-page (over HTTPS) that has a static/publicly known bits but private information as well (like an email client, bank page, etc.). An attacker knows the static bits because it’s public knowledge. If he can then go ahead and decrypt the entire page that was downloaded, I’m sure we can all agree that SSL would be insecure.

1 Like
95

Read Zooko’s answer in particular, two highlights: Hack Tahoe-LAFS! and http://www.pinkas.net/PAPERS/hps.pdf

2 Likes
96

Thanks for bringing that up. From the paper that curious’ lists:

Privacy. No MLE scheme can achieve semantic-security-style privacy in the spirit of [13, 28]. Indeed, if
the target message M is drawn from a space S of size s then an adversary, given an encryption C of M , can
recover M in O(s) trials. (For each candidate M 0 ∈ S test whether D(K(M 0 ), C) = M 0 and if so return
M 0 .) As with deterministic public-key encryption [11], we therefore ask for the best possible privacy,
namely semantic security when messages are unpredictable (have high min-entropy).

(emphasis mine)

In short, if the entire message has low entropy, then any convergent encryption scheme is insecure. That need not not be the case if only part of the message has low entropy.

To take the example of a web-page: the web-page has a low-entropy part (from the static content) and a high entropy part from the private content (since that private content is harder to guess). As a whole, however, the page would have high entropy. So, a good convergent encryption scheme should still be robust in this instance – it shouldn’t allow plaintext recovery if there is part of the plaintext that is computationally infeasible to guess (regardless if there are other parts that are guessable).