Notices

Current version: 7.1-maemo6
---

I've uploaded TrueCrypt 7.1 to Extras-testing. It is latest upstream version - additionally, following things changed from 6.3a-maemo4 (available in extras):

• GUI available (command-line operations still possible).
• Hardcoded -m nokernelcrypto removed - kernel-power users may benefit from cryptographic module.
• Included wrapper, that determines, if kernel-crypto module is available, and make TrueCrypt use it (xts support). Otherwise, falls back to -m nokernelcrypto parameter. Additionally, wrapper unset GTK2_RC_FILES for TrueCrypt occurrence (disable hildon theme for it), thus making GUI usable - no parts should printed out of screen.

All code has been written by TrueCrypt foundation (excluding external wrapper). I just uploaded it, thus I take no credits for any other work, involved in bringing it to our device.

For now, to run it, open terminal, and as root, execute:
If, for any reason, You want to omit wrapper (*not* recommended), use as root:
It's *heavily* recommended, to turn TrueCrypt background task off - in our case, it doesn't provide any true benefit, yet consumes ~17MB of memory and CPU cycles. To do it, from TrueCrypt GUI enter "Settings -> Preferrences -> Background Task (Tab)" and untick "Enabled".

.desktop shortcut and icon coming up in next version (contribution of nice TrueCrypt'ish icon(s) highly appreciated). Instructions on usage to be found here:
http://talk.maemo.org/showthread.php...ight=truecrypt
Ignore parts about installing, unsetting GTK2_RC_FILES etc - jump straight to usage (Instructions will be update soon by original author, to comply with repos-available incarnation). Also, please post all questions/problems related to TrueCrypt usage there. This topic is meant only for development suggestions and bug reporting (and, of course, announcing further versions).
---

Mass-storage mode:
---

You can use N900's encrypted partitions via mass-storage mode, *without* need for TrueCrypt installed on desktop (all decrypted in N900, transparently for desktop). This way, You can use content of Your encrypted volumes in desktops, without actually using them to input passwords/keyfiles = no risk, that software or hardware keyloggers attached to said desktops, will catch your password. Just remember, that it *doesn't* protect Your encrypted volume from getting unwanted files written by malware, or even being deleted/overwritten, if connected in read&write mode.

It's very simple to achieve - just execute in terminal (as root):
...replacing [your-encrypted-device] with path to Your encrypted device (*not* partition containing it). Examples:
It's very easy, to determine, where Your encrypted device is located - just execute:
in terminal. First column is partition/container location, 2nd one is Your encrypted device location, and 3th is mountpoint for actual file access. You use 2nd one, as argument for mass-storage'ing.

Side note:
If, for any reasons, You want simple code to grep your encrypted device location, by providing it's actual location (partition or encrypted file container), you can use this (courtesy of NIN101):
...where [path to volume] should be replaced with path to partition or file container (for example, /dev/mmcblk1p2, or /home/user/MyDocs/my-encrypted-file-container).

It doesn't have any benefit over writing argument directly, but may be useful, if You're planning to write simple GUI for that, or to include support for it in your program.

Known flaws:
Mass-storage'd volumes doesn't respect special filesystem options passed to Maemo by trueCrypt, during mounting (they're still valid for Maemo, but not for desktop). So, if You mount Your volume with read-only flag, and latter mass-storage it, desktop will be able to write to it anyway. Of course, Maemo still respects read and write flags. If You want to export volume for desktop via mass-storage in read-only state, you must create Your copy of [b]osso-usb-mass-storage-enable.sh (remember to chmod +x it afterwards), edit it to use read-only, and use it instead of vanilla osso-usb-mass-storage-enable.sh, everytime You want to export volume as read-only.

Known "special" benefits:
As for volumes with ''Hidden volume protection'', mass storage respect it and provide some kind of extended plausible deniability. Such volume, when exported to desktop via mass-storage, still protect blocks of hidden volume, yet *doesn't* throw any warnings on desktop side. Furthermore, "blocked" file appear to be written successfully from desktop side. For example, if You copy music file, that gets write blocked, it's fully usable from desktop, as long as You don't disconnect mass-storage and connect it again.

That is, You can have, lets say, 20MB outer volume, with 15MB hidden volume inside, then copy 17MB music file to outer volume (obviously, with "hidden Volume Protection", it will get blocked as soon as it reach any hidden volume block), and then, perfectly play it from desktop - from start to the end. Also, using "safe device removal" will not pop-up any errors.

in reality, such file will be copied only in part that was written to outer volume, with rest just plain cut-off (in my tests, I was able to play such music file furthermore, but instead 3 minutes, it played only for 29 seconds).

Of course, I've tested it with another music file occupying 98% of hidden volume, and despite "writing" repeatedly many different files to outer volume (from desktop, via mass-storage mode), file on hidden volume was kept intact.

Only one moment, when You'll get notification "warning, TrueCrypt protected hidden volume from damage (...)", is when You unmount TrueCrypt containers (if you've followed my advice and disabled "background task").

(technical explanation of this phenomena)
When volumes are mounted successfully with hidden volume protection, they're mounted as encrypted loop devices (for example, /dev/loop0). Unlike filesystem options (like read and write flags), which are set at later part - while mounting encrypted device as actual access point for filesystem (i.e. /media/truecrypt1), thus ignored by mass-storage target desktop - "hidden volume protection" is set as special option of such loop device. As we export loop device as mass-storage, protecting bits are respected, yet desktop OS doesn't have a clue about them, and isn't informed. Common sense would tell, that during "Safe Device Removal", desktop's Os should be informed about "delayed write fail", yet, it seems that it's not informed about any failures, and consider operation finished OK.

Normally, this would be bug, but in our case, it's a feature providing additional benefit
---

FAQ:
---

Q: I don't trust some random guy providing TrueCrypt binaries.
A: No problem, you can compile Your own from sources, instead of using one from repositories:
Q: Does wear-leveling used on N900's rootfs (software one, except kernel part) and eMMC (hardware one) affect security?
A: From trueCrypt documentation:

Despite it stating, that plausible deniability isn't possible on devices utilizing wear-leveling, it's not entirely precise. All mechanism providing plausible deniability still works - yet, if attacker is able to perform hardware analysis of storage medium, he can determine that hidden volume is used (but, still *not* able to decrypt it).

Also, You should avoid changing password/keyfiles for already existing encrypted volumes, on devices that use wear-leveling. Instead, in such case, create new encrypted volume (or backup files from encrypted volume, and re-create it from scratch), and copy data there. As stated in quoted documentation, overwriting volume header (in case of changing password/keyfile) implies security risk of having both old and new header spread (physically) on partition (again, using that security hole isn't trivial, but possible).

Q: Is it safe to use Maemo auto-completion feature with TrueCrypt?
A: No. Maemo auto-completion feature is well-known for remembering *every* word You put into any Maemo dialog box, including passwords (!) - same apply for TrueCrypt GUI windows asking for password. This implicit huge security risk in any password-protected application, thus it's recommended to turn it off.

If You've already used Maemo auto-completion, after turning it off, recognized words are *still* stored in it's database, located on: /home/user/.osso/dictionaries/.personal.dictionary
Delete this file, but doesn't try shredding it - it's utterly useless on storage with wear-leveling (thanks for spotting it, Niwakame). the only way to securely get rid of database remnants, is filling *whole* free space in partition with zero's (not random numbers, as on flash storage, zero's are faster to write after - unless you want to kill your partition performance for quite a while).

Q: Is there any way to force unmount encrypted partition, in case of stolen/lost phone?
A: When encrypted partitions are mounted (by TrueCrypt, I don't mean regular linux mounting), they're - obviously - unprotected, unless unmounted (to mount it again, one need to provide password). Currently, only one possibility is to set relatively short auto-lock time - for example, 5 min - lock code can be disabled by reflashing, but it require turning phone off/rebooting, anyway (in which case, encrypted partitions are unmounted).

Yet, it isn't ideal solution - if thief know about Your "secret" files and want to access them, he can perform any operation on phone (to not allow triggering of inactivity autolock), until he finish copying files from mounted, encrypted volume. Unfortunately, same apply for notebooks, desktops etc, and it's generally not TrueCrypt-side problem. For "paranoia" level of required security, always unmount encrypted partition, before going away from phone/putting it into pocket/etc.

I'll ask developers of SMSCON, about possibility to include special SMS command, remotely unmounting all TrueCrypt partitions. IIRC, it's even possible to achieve now, by using SMSCON custom command.

Q: I have some problems with version 6.3a-maemo4 available via extras...
A: 6.3a-maemo4 wasn't uploaded by me, and I haven't even used it, so I can't help with that. Furthermore, 6.3a-maemo4 is depreciated, as it got -m nokernelcrypto hardcoded (no way to use XTS via module shipped with kernel-power). TrueCrypt 7.1 is now available through extras-testing, so you don't need to have -devel enabled to use install it.
---

First post will be updated when appropriate (with notes left as post, inside this thread). Wiki page is also on it's way (if You can create it before me/fill with content, when it appears, I would be most grateful).

/Estel

First post updated with FAQ about wear-leveling vs security, and bunch of other possible questions.

sorry for a very noob question..i dont understand what is this for (truecrypt)? will it lock files or folders?

See:
http://www.truecrypt.org/docs/
...and:
http://www.truecrypt.org/docs/tutorial

Scratch this, as it's applicable to cryptsetup, *not* TrueCrypt - my bad. It was already deleted from FAQ.

Of course, automount script on device startup is still perfectly achievable.

/Estel

// Edit

Yet, for people interested in encrypting *whole* '/home/user/' (not only private things and symlinking) I've come across this:
http://talk.maemo.org/showpost.php?p...0&postcount=36

I was written for older version of TrueCrypt, but should work exactly the same on 7.1. Be warned though, I haven't tested it myself (personally, I think encrypting /home/user/ as a whole is a little counter-productive performance wise, considering that we're able to encrypt only private things), and it's definitely advanced topic, not for those of faint heart. Use at Your own risk.

/Estel

The progam manager automatically updated truecrypt to the 7.1 gui version.
How can I get the old version without gui again?

Is it optified?
I'd thank but my thanks button disappeared..

disable extras-devel, which you shouldn't use (probably) anyway, if You don't know why it has been automatically upgraded.

Totally no offense - it's just like, that some things in -devel can be really troublesome for people without sufficient knowledge. Look at this real example - first of all, I've uploaded version maemo5, which was containing major dependency flaw, allowing it to create encrypted partition, but without any chance to mount them. version maemo6 addressing this issue was uploaded in few minutes, but if, by any chance, You would follow HAM update notification in such short interval, and went to mess with TrueCrypt immediately, You would end up encrypting - let's say - /home/user, without chance to mount it. Would You be able to fix it on Your own?

Things in -devel *aren't* guaranteed to work at all, even despite fact, that developers do what they can to ensure proper working and no screwed system. The fact, that majority of users have -devel enabled by default, isn't good thing - and fact that it's mainly X-Fade fault (some major packages, like kernel-power can be installed properly *only* from -devel), isn't changing it.

@marmistrz
Yes, it is optified. I would explicitly state it, in other case. And don't worry about thanks - You'll do it, after fixing Your account

----------
Working again whithout gui. Thank you!
The other Version also worked without any problem but the gui was to small for my eyes.

Bulletproof approach - disable extras-devel, and extras-testing, 'apt-get update', 'apt-get install --reinstall truecrypt', and - if you still wish to - enable extras-devel and extras-testing, 'apt-get update' again.

Of course, you can also use command to explicitly install set version (refer to apt manual), OR temporarily set extras as a target (manual again), OR use other fancy way to skin this antelope.

Anyway, why do you find GUI non-usable? Also, do You know, that you can still use truecrypt as command-line only (just don't use GUI) - invoke 'truecrypt --help'' for list of supported commands. also, keep in mind, that old version is depreciated, as it got -m nokernelcrypto hardcoded, hurting performance in case of cryptographic module being available.

Of course, it's totally up to You - if You got some masochist tendencies, have fun. Yet, I can't help you with old version, as i've stated in FAQ - it wasn't uploaded by me, and I wasn't using it in any way.

/Estel