I read in DEVONthink Pro’s Help (under the heading Database Properties) that “DEVONthink does not yet provide file encryption for enhance[d] security.” That “yet” implies there are plans to provide encryption at some point. Is that the case - and if so, will it be for the Pro version, or only Enterprise?
Probably the simplest approach is to use encrypted disk images.
From the Support perspective: Please don’t ask how to recover your data if you’ve used encryption and forget your password. 
Hi again, Bill. I know there’s a whole debate about in-app encryption versus disk images. I use both, and still think there’s a lot to recommend the MacJournal approach, which lets you encrypt individual folders/“journals” within a database. That aside, what are Devon’s plans? It’s that word “yet”, you see.
I’m not aware of any current plans to add encryption to DT PE or DT Pro. There’s a simple password protection for databases.
Eric, for example, uses encrypted disk images for sensitive-information DT Pro databases. That’s much less problematic than File Vault, as losing a disk image is less of a problem than losing one’s entire home directory.
Mixing encrypted and unencrypted material in a database raises a number of issues. At best, it hampers the ease of access to information, including contextual relationship associations. At worst, it could reduce the security of the encrypted portions of the database. Example: If the content of a secured group were encrypted, it wouldn’t be searchable. On the other hand, if the Glossary were to be rebuilt while that content was ‘open’ it would compromise the security of those contents.
There are a number of encryption schemes out there. Note that some of them that claim to be much more secure than 128-bit encryption (which you get with encrypted disk images) are in reality less secure than claimed. Anyway, the vast majority of successful thefts of secured information are not made by people who break encryption codes. Most thefts involve human engineering, such as getting access to passwords, or (in a great many cases) figuring out what an individual might choose for a password. In such cases, there’s no difference between 128-bit and 128-gigabit encryption.
I’ve always been fascinated by cryptography and data encryption.
Sorry for the thread necromancy (resurrecting a long-dead thread), but I would love group-level and/or document-level encryption added for DTpro2…
I would have no problems with a limitation that any such encrypted groups/documents would be excluded from classification, wiki-type features, global search, and (as Bill so succinctly put it) “contextual relationship associations”.
I’d use this encryption for passwords, financial information, and other sensitive data that wouldn’t need the above “contextual relationship associations”, but that I’d like to have conveniently available via my favorite organizational tool (meaning DEVONthink Pro, of course).
I agree that it would be a small trade-off to give up classification in exchange for encryption on some things such as passwords, financial information, etc. I know I could use a Disk Image for a dtBase, but then I’d have to use a password every time I opened it, instead of only for a particular files within it that I (rarely) open.
I just looked at a piece of software named Yojimbo that does some of the things DTPro does (not even close, but nevermind that) and it includes file encryption options. Looks very convenient.
Encrypting specific records, even if this means requiring GPG be installed, would be very useful.
For me this is partly a convenience issue (as mentioned, being able to store sensitive data in the db), and partly a paranoia issue … I’m not sure if the crypto for Apple’s disk images takes place at the block level (good) or the filesystem level (bad), but since it was developed in-house I fear the worst (not a slam on Apple, but rather sound crypto advice: always get a specialist or re-use a proven product).
The matter of indexing and the glossary, as mentioned, is significant: no-one wants to have their passwords turn up in the Concordance, or to have encrypted documents show up in search results (i.e. targeted search results would yield enough plaintext in the encrypted document to use a known-plaintext attack). The key is to restrict the data of the document from searches, and to just use the Name, Comments, and Label information. I thought of suggesting this when I read about Bill’s problem PDF :
http://www.devon-technologies.com/phpBB2/viewtopic.php?t=3199
Preventing a record from being indexed flies in the face of the DT philosophy, but would be useful for problem documents, encrypted documents, and some of the experiments I am toying with (e.g. seeing if I can ‘train’ the DT AI to recognize irrelevant URLs in a DA results list).
My hunch is that indexing (and by this I mean in the database sense, not in the DT sense of ‘indexing’ versus ‘importing’ a file) is used throughout DT and could not be easily disabled. Instead, it might be useful to extend the ‘Exclude From Classification’ property to a set of controls: exclude from search results, exclude from concordance (i.e. do not count or add words from this record), exclude from ‘See Also’. It is easy enough to make exclusions of records when generating the lists (e.g. of search results) for display; the trick will be ensuring that the content of the record is not considered during searches while its metadata is.
Also, at the risk of sounding obsessed with scripting, it’s possible that encryption of text records could be crudely implemented using Applescripts. A first script, ‘encrypt contents’, would prompt the user for their GPG password, encrypt the contents of the record (‘do shell script gpg’), replace the record data with the encrypted version, and attach a decryption script to the record.
When the record is viewed, the triggered() handler would prompt for the password, replace the data of the record with its decrypted version (via shelling out to gpg), and attach the original encryption script to the record.
This has the problem that the user has to re-open the record and re-enter their password to re-encrypt it. A better solution would be to decrypt into a new record (in a new viewer window), with a script attached that erases the data of the record and deletes the record itself the next time it is viewed. Not sure how well that would work though.
I know this has had quite a bit of discussion already, but I want to add another vote in favor of database encryption in Devon Think Pro. I have a “personal file cabinet” database in which I keep everything from warranty receipts and light bills to bank statements and credit reports. While not all of the information is particularly sensitive (light bills), some of it is. At first I added a password, but then I happened to notice that a spotlight search pointed out a PDF file in my database. Huh, that’s curious. What I discovered is that if a hacker has the spy-like prowess to be able to right mouse click on the database file and select “show contents”, within this is a folder called Files which contains all the PDF files, which are very much able to be opened with Adobe reader. In short, the password protects your data against casual intruders and the “electronically-challenged”.
I am not worried about having my password hacked to gain access to my files, but I would like it to be at least minutely challenging to someone who steals my laptop to be able to get these files. I have now put all my financial information and the database file onto an encrypted disk image, but that’s a bit a of hassle (but very workable) to get encryption. The ability for Devon Think Pro to encrypt and decrypt it’s own data (even weak encryption would be fine for my purposes (I’m trying to foil laptop thieves, not the NSA) would be very nice.
Thanks,
Michael