This project has moved. For the latest updates, please go here.

Best practice for dealing with unencrypted open documents after VeraCrypt closes

Topics: Users Discussion
Mar 13, 2016 at 10:18 PM
After veracrypt unencrypts and 'mounts' a document to open it, that document stays open and unencrypted, even after veracrypt closes.

Does this mean that once a document is unencrypted, opened, by VeraCrypt, that it's in ram and could be read by any other app on the system -- even if the document is closed?

What's a 'best practice' for dealing with open documents after veracrypt is closed?
Mar 14, 2016 at 4:00 AM
Edited Mar 14, 2016 at 4:00 AM
See the documentation.

https://veracrypt.codeplex.com/wikipage?title=Unencrypted%20Data%20in%20RAM

https://veracrypt.codeplex.com/wikipage?title=Data%20Leaks

.
What's a 'best practice' for dealing with open documents after veracrypt is closed?
.
System encryption.
Mar 14, 2016 at 12:51 PM
Edited Mar 14, 2016 at 1:02 PM
This is a huge help -- thank you!

This statement, "It is important to note that VeraCrypt is disk encryption software, which encrypts only disks, not RAM (memory)." should be posted everywhere and made as plain as day to everyone.

There are journalists and civil rights leaders who depend on encryption for life and death issues. The above statement is critical for those people. As long as I've used truecrypt and now veracrypt, and as much as I've been curious about encryption software, I've NEVER REALIZED THIS.

Before you beat me up for being ignorant, or for not finding and reading some instructions, I'm sure that many journalists and civil rights leaders are also just as ignorant. Be clear on what this software does, and what it doesn't.

I always thought that all the difficulty in encryption of computer files and the audits and the endless lines of code was precisely the issue of what to do about what is retained by Windows, and RAM, etc. Surprises me that it's only about encrypting a file on a hard drive.

The encrypting a file task intuitively seemed far easier. I would have imagined that sophmores in computer science have been given such an assignment. Alas, how was I to know that the file remains in RAM, plain as day, after "unmounting"?

Furthermore, the feature of automatically 'unmounting' after x minutes always gave me the incorrect feeling that the 'file' was 'gone' after 'unmounting'. No, it's not. No ... it is not.

Veracrypt 'closed' after 'unmounting'. That's all. The program closed. Only the program. Anything in RAM, any open, file, windows thingies, whatever else, apparently remained 'unmounted'.

How much of an encrypted file on a computer stays unencrypted after veracrypt 'unmounts'?
Drive caches?
Windows sytem files?
Indexes?
Cortana?
Spools?
Etc etc

I understand -- now -- that none of these things are veracrypt's responsibility. That's cool. But let us know.

Always seemed to me that a word like 'unmounting' meant that veracrypt was 'taking care of business'. 'Unmounting' sounded sexier than 'closing'. It's as if the word 'close' wasn't good enough. Alas, there are probably more words that describe computer programming than there are words that describe beer. Please, lighten up on the market speak, go back to the dictionary, be clear.

Again, many thanks for this reply and for the work that you are doing. My rant is meant to show another viewpoint and to give back. Hope it's helpful, somehow.
Mar 14, 2016 at 4:15 PM
Edited Mar 14, 2016 at 4:15 PM
I am not aware of any disk encryption product that maintains the data encryption in the RAM and still allows access to the applications.

https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software

For VeraCrypt, you can read other precautions to disk encryption at the link below.

https://veracrypt.codeplex.com/wikipage?title=Security%20Requirements%20and%20Precautions
Mar 14, 2016 at 7:45 PM
Robert2016.... I think you are overreacting a bit.... there is nothing "dangerous" by not encrypting the RAM... just relax.....
Mar 16, 2016 at 4:36 AM
OP, you've misunderstood. Half of what you fear is NOT happening. The half that
is, is extremely well publicized. To get a better handle on this, it would
be helpful first to get a clear understanding of the nomenclature. When you have
false ideas about what the WORDS mean, you don't get much benefit from reading
the manual. When you misuse the words, people's explanations are less likely to
help because they are guessing at what you meant and are likely to be addressing
questions that aren't really what you had in mind, which leads to still more
misunderstanding when you make perfectly reasonable inferences that are based
on the false assumption they are answering the question you were asking, and . . .
it snowballs into a massive wtf storm. I'm not trying to be a smart ass - I really think
the best first step you can take is to go to Wikipedia or someplace like that and
look up all the concepts that you aren't 110% certain you understand. The biggest
enemies of comprehension are the premature belief that it has been attained and
the use of jargon that isn't perfectly grasped. Please be patient if I point out what
you already know - my mind reading skills are quite poor. Nor, I warn you, am I
omniscient, or even deminiscient. Maybe quarter-niscient. So I welcome, more, I
appreciate, correction to what follows by my betters. ;-)
  • files are not "mounted". Strictly speaking partitions are not "mounted". Only file
    systems are mounted. In this special context, we might speak of a container
    crypt as "mounted", but even that is a stretch. It would be more kosher to say
    that VC has the crypt file open (assuming it does) and that the filesystem inside
    it is mounted.
  • an application (such as a text editor) must "open" a file to display its content, but
    it may continue to display that content after the file is "closed". If the file was on
    a crypt that was dismounted in the Veracrypt GUI, it most assuredly is NOT "open."
    When an application opens a file and then reads it, it's data will typically be stored
    in "memory". I put that in quotes because memory, which we classically take to
    mean RAM (more fully, DRAM or D-RAM), can in most modern systems be either
    RAM or drive space that the OS is managing so that it LOOKS like RAM to the
    application. Some applications will attempt to keep the file "open" to prevent
    other applications from doing anything to it while that application is using it, but
    most don't. In some applications it depends on the circumstances. Fbreader, for
    example, will cheerfully open a small epub, read it
    into "memory", and close the file immediately, while Fbreader itself continues to
    display the content of the file for you to read. But if the file is larger, it keeps the
    file open. "Open" or not is basically something the filesystem keeps track of to
    keep applications from getting confused or doing disastrous things to your data
    when more that one program is doing something with the same data.
  • You can disable this emulation of RAM in hard drive space if you want to.
    In unix-like operating systems it is called "swap", in Windows, I believe they call
    it "paging". Or you can tell the system to put the "pages" or the "swap" on an
    encrypted partition. Frankly, in most modern boxes, for the things most people
    do, neither will hurt performance much, because most of us never
    come close to using all our RAM anyway so the swap rarely if ever gets used.
    And that does close one potential way information can be leaked. But for the
    same reason, it doesn't usually hurt performance much to disable swap or
    paging, it usually doesn't make a huge security difference either - because
    most of us have so much more RAM than we need, that swap is rarely used,
    which is a GOOD thing. D-RAM, good; swap, bad; out of memory, more bad.
  • If a file is located in a crypt, and that file is opened, read (and typically closed)
    by an application which continues to display the content of that file (such as a
    text editor continuing to show the content of a text file or a picture viewer
    continuing to show the image) and the crypt is then dismounted by VC, the
    content of that file does NOT continue to be available to other normal programs.
    It is in a bit of memory normally available only to the program displaying it.
    I hedge by saying "normal programs" and "normally" because there is very little
    limit to how malware may peek over your shoulder, especially in Windows, but if
    you have that kind of problem the bad guys probably already have all your
    passwords anyway and I hope you keep the nuclear launch codes somewhere
    else - a post-it note by the red button would be good.
  • data that was in RAM, such as the content of a text file that was recently read
    with an editor, will, to some extent, persist in RAM for a while but not for long and
    not after that RAM has been used for something else. But it isn't available to any
    normal software, and if you reboot, I believe it should be gone in 10 minutes or so.
    The reason they call it "D[ynamic]-RAM" is that it has to be constantly refreshed
    or the information fades away. This it the basis of the "cold boot attack" - but the
    cold boot attack takes physical access to your machine while the data is still there
    and it doesn't hang around long, unless maybe you live in Antarctica.
  • The fact that a great deal of metadata about files is stored in places other than the
    directories with the files - is very real, and very widely discussed. Things like
    filenames & locations, thumbnails of visual media files, maybe even file hashes.
    Exactly what is stored and where it is stored will vary greatly depending on the
    system. A lot of applications keep their own most-recently-uses lists. OSs do also.
    Obviously if you have some sort of fast-file-finder program indexing your system
    it will keep the information it has found - otherwise it would be pointless. Some
    file browsers have even been known to send all trash from all mounted
    filesystems to the SAME trash can, which is incredibly stupid, not just from a
    security viewpoint but for performance as well. And the details constantly change
    as things get updated. So even though nearly all, maybe truly all, of this can be
    set up so it doesn't leak information, it won't STAY set up, so piecemeal solutions
    like Window Washer or BleachBit have some uses, mainly in recovering drive
    space, but they can't be depended on for security if your adversary is competent.
There are 3 solutions to this:
  1. Whole disk encryption (strictly a misnomer, but it's
    close), especially with a second hidden OS. That's a complicated solution, but the
    most favored in the Windows world.
  2. Live disks. That's a heck of a lot simpler
    and is the almost universal solution in unix-like systems.
  3. Virtual machines managed with software like Virtualbox. Not perfect, unless
    you can find a VM manager that's a strictly portable program (and how can you
    be sure it is?), or run the VM from a live disk. But if you have the live disk, you
    don't need the VM. That is however, probably the best solution for people who
    insist on running Windows.
Setting up a live disk system is much more difficult with Windows, ultimately
probably because of IP related issues. I know of 2 systems for Windows live disks,
but I don't keep up
with Windows. One of them was a for-internal-use-only tool from MS, and the
other was an independent turn-your-windows-into-a-live-disk system. I don't
recall the name and I'm not sure if it has been maintained. I'm pretty sure it was
around in the XP era and it went through several versions. And whole disk
encryption, or, more accurately, near-whole disk encryption, is extremely difficult
on 'nixes. Probably mainly because live disks are so easy there isn't a lot of
incentive for developing them.

"Drive caches?"

No. Not if you mean the on-drive hardware caches that are the only kind common
nowadays. Data is decrypted and encrypted in system RAM. Everything that went
on to the drive encrypted to begin with has no reason to exist on the drive in
decrypted form in the cache.

"Please, lighten up on the market speak, go back to the dictionary, be clear."

And you're the one asking that nobody "beat up" on you?
Just because you haven't made sufficient effort to understand it does not make it
"market speak". The manual is very clearly written, but you have to read it. Do
you complain to a mechanic if he insist on calling a carburetor a carburetor and
fuel injectors fuel injectors? Specialised areas of intellectual endeavour have
specialised terminology in order to communicate clearly about the subject
matter. They correspond to IDEAS that must be carefully distinguished. Dumb down
the terminology and you dumb down the explanations. I don't think
the people who have put their time into developing this are the ones that need
to use a dictionary. I think that is PRECISELY what you need to do.
But if you feel differently, you could apply for a refund. (Let's see, with compound
interest . . . hmmm, I guess Hendrix was a pretty good math geek).

None of these ideas are particularly obscure. Nobody is trying to
"beat up" on you, but realistically, it isn't like you have to study the
manual at length to come in contact with them. The metadata problem is so
widely written about, NOT just in the manual, you can't possibly avoid reading
enough to at least show you
that there is something there you NEED to understand if you read any background
on the subject AT ALL. As for the journalists you are worried about, frankly there
are words for people who engage in dangerous activities without taking the most
common sense precaution of actually reading about the tools they plan to protect
themselves with and just casually assuming they can wing it. The first ones to come
to mind are prisoner, martyr, dead, and foolish.
Mar 16, 2016 at 6:44 AM
continentalop,
thank you very much for this broad and good comment.

Besides the technical part of your comment, you mentioned a very very serious problem of the "language issue" - the specialized terminology in every field that one must learn. It belongs not only to the tech field, of course. that's exactly what i thought about many times while reading this kind of comments (like roberts) on many technical forums.

It would be helpful first to get a clear understanding of the nomenclature. When you have false ideas about what the WORDS mean, you don't get much benefit from reading the manual. it snowballs into a massive wtf storm.

I'm not trying to be a smart ass - I really think the best first step you can take is to go to Wikipedia or someplace like that and look up all the concepts that you aren't 110% certain you understand. The biggest enemies of comprehension are the premature belief that it has been attained and the use of jargon that isn't perfectly grasped.

People who are not "techie" don't take time to investigate, to read, to learn, at least, the basics of the field of computers/ encryption.... but on the contrary, not just that they speak of (with full confidence!) what they don't understand/don't know at all -> thus confusing themselves and others with FALSE conclusions, BUT ALSO they demand a magic stick solution (in this case the VC program) that will solve everything without them (or attack the developer that didn't "warn" them about this or that).

continentalop, i just wanted to emphasize your main idea one more time. To all of us. Because it is so fundamental. It is the root of so many mis-understandings that could lead (in this field of encryption) to DISASTROUS EFFECTS.

PEOPLE, PLEASE, ask professionals AND learn (as broad as you can) the technical issues you don't understand! Don't be lazy or arrogant thinking you "know" AND don't be fool making false conclusions that will mislead you and others!

With respect.
A.
Mar 16, 2016 at 8:06 PM
Thank you, Algreider8.

This:
algreider8 wrote:
. . . a very very serious problem . . . belongs not only to the
tech field . . .
People . . . don't take time to investigate, to read, to learn, . . .
but on the contrary, not just that they speak of (with full
confidence!) what they don't understand/don't know at all - thus
confusing themselves AND OTHERS [emphasis added] with FALSE
conclusions, BUT ALSO they demand a magic stick solution . . .
is very insightful. Indeed, I believe this is one of the most
fundamental problems with the massively parallel information
processing system we call "democracy" and the "DISASTROUS EFFECTS"
there are far more dangerous than anything that happens in our
little corner of reality.