All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timo Ketola <Timo.Ketola@exertus.fi>
To: Andrew Murray <amurray@embedded-bits.co.uk>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [RFC] mtd: ubi: UBI Encryption
Date: Tue, 11 Aug 2015 05:38:20 +0000	[thread overview]
Message-ID: <55C98A3B.3010405@exertus.fi> (raw)
In-Reply-To: <CAPcvp5GZi0gV=J2Zbz_Sp+NmZNKnA38JAsYtbuNiwsq84yMDfg@mail.gmail.com>

Hi,

I have been lurking in this list for a long time and this is my first
post here. I decided to write because I think I have yet another idea
for this one:

On 10.08.2015 22:56, Andrew Murray wrote:
> ...
>  - My work around for this erased flash issue was to conditionally
>    encrypt/decrypt only when the input data is not 'all bits set'. This had
>    minimal impact on UBI/UBIFS/etc but it is possible (though very unlikely)
>    that the output of an encryption algorithm is 'all bits set' - Thus when you
>    later attempt to decrypt the 'all bits set' cipher text we incorrectly treat
>    it as erased flash so return it verbatim and thus cause corruption. I've not
>    seen this issue occur despite reading and writing more than 50GB of data.
> ...

Why not postprocess the data so that the encrypted FF becomes FF again
like this:

Lets say clear text data is I, encrypted data is O, encryption function
is e() and decryption function is d(). Then, what is normally done, is
of course:

Write: O = e(I)
Read: I = d(O)

Calculate F = ~e(FF), where F is encrypted and inverted version of 'all
bits set' (FF) data, and modify writing and reading:

Write: O = e(I) ^ F
Read: I = d(O ^ F)

Now encrypting FF input results in FF output and vice versa.

Just wanted to introduce an idea.

--

Timo

  reply	other threads:[~2015-08-11  5:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-10 19:56 [RFC] mtd: ubi: UBI Encryption Andrew Murray
2015-08-11  5:38 ` Timo Ketola [this message]
2015-08-11  6:22   ` Richard Weinberger
2015-08-11  6:35     ` Timo Ketola
2015-08-11  6:30 ` Richard Weinberger
2015-08-11  9:47   ` Andrew Murray
2015-08-11 10:23     ` Michal Suchanek
2015-08-11 11:03       ` Andrew Murray
2015-08-11 11:39         ` Michal Suchanek
2015-08-11 12:40           ` Andrew Murray
2015-08-11 13:24             ` Michal Suchanek
2015-08-12  9:39               ` Andrew Murray
2015-08-12 17:19 ` David Gstir
2015-08-14  7:25   ` Michal Suchanek
2015-08-14  8:08     ` Andrew Murray
2015-08-14 14:11       ` Murali Karicheri
2015-08-14 14:28         ` Richard Weinberger
2015-08-14  7:48   ` Andrew Murray
2015-08-15 11:43     ` David Gstir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C98A3B.3010405@exertus.fi \
    --to=timo.ketola@exertus.fi \
    --cc=amurray@embedded-bits.co.uk \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.