> > Has anyone investigated the issues surrounding encryption and yaffs2?
> > I realize it may be impossible to solve, but I really don't want to
> > have a system that is NAND<->FTL<->dmcrypt<->ext3.
> >
> > I understand that it would be very difficult to not leak information,
> > encrypting the oob seems impratical (excepting of course the ecc, and
> > block state). Let me know if anyone has given this any thought.
> >
> Russ,
>
> I don't know a lot about encryption, but I know people who do. However I
> know less about the terminology you used here than most readers of this
> list. Can you explain what dmcrypt and ext3 mean ? I guess FTL is
> File Transfe/lation Layer.
ftl is the mtd flash translation layer, it presents a NAND flash
device as a block device. dmcrypt is a module for the linux device
mapper virtual block device layer.
(
http://deb.riseup.net/storage/encryption/dmcrypt/). ext3 is a
journalling file system that can be used on block devices.
So you make a block device out of your NAND flash with FTL, you
encrypt that with dmcrypt, and you mount an ext3 filesystem on top of
that. Only problem is that m-systems has a software patent on ftl last
I checked. I'm not sure with raw nand flash which ftl would be proper
to use, ftl, nftl, inflt, or rfd_ftl. Would be a better question for
the mtd list
> I am not clear if you want the information in NAND Flash to remain
> unintelligible to others who read it without authority, or never to be
> readable by any others. If the latter, is it others using the same
> YAFFS that you are concerned about, or others remote from that YAFFS ?
I'm not sure what you mean here, so I'll clarify. Encrypted as in,
using aes256 per block, and and some kind of hash across the blocks.
Reading and writing to the filesystem would require the kernel to have
the proper key.
(text/plain)