InformationHiding is a principle first published by DavidParnas in his seminal paper OnDecomposingSystems.
The basic idea is that if code chunk A doesn't really need to know something about how code chunk B (which it calls) does its job, don't make it know it. Then, when that part of B changes, you don't have to go back and change A.
It is widely recognized as the most important criterion for judging the quality of a software design, although many more people think of it under a different name. The current phrase "if we do X we increase coupling between A and B". Increasing coupling is equivalent with breaking InformationHiding.
Encapsulation, strictly speaking, means something different; it means collecting a bunch of stuff together and putting it in one box, or capsule. The box may or may not have opaque walls, so this may or may not involve information hiding. In practice a "class" will both encapsulate (ie bundle code and data together) and hide information (namely, implementation detail), and some people get so used to doing both at once they no longer bother to distinguish. A few pedants still care, though. See http://www.toa.com/pub/abstraction.txtExcept for C programers (where they're habituated to being exposed to raw memory), I think the gentleman/lady-programmer knows the box forms a tacit boundary that is to be respected.
Why is it not called "implementation hiding"? Is information hiding different than implementation hiding? It is also sometimes called the "black-box principle".
See also EncapsulationIsNotInformationHiding, GateKeeperCategoryInformationCategoryModelingLawsAndPrinciples