In the recent past we have been working on a plugin that extends the functionality of Winamp, now it can play media files stored on encrypted containers created by Private Disk.

The key advantages are obvious:
In other words, now you can protect your music archive from unwanted eyes, with a minimal effort. The files are secured with the strongest encryption algorithm available today; your privacy is guaranteed, no three-letter or four-letter agency can challenge that!
The plugin mounts encrypted images created by Private Disk, this means that the same encrypted image can also be used for conventional file storage.
Private Disk plugin for Winamp will be followed by the release of Private Disk FileMove, a tool that finds, organizes and securely stores files on your system - a great addition to Private Disk and the plugin for Winamp.
The plugin is free of charge, and it will soon be made public in Dekart's main site.
Some might be interested in the history of data encryption programs developed by Dekart. The chronology is a bit different from what one expects, so here are some facts about what happened, as well as some ideas about what might happen in the future.
The first program in the line is Private Disk Multifactor, which was released somewhere in 1999; at that time it was called "Private Disk". This is a smart-card/token -oriented encryption tool that appeared as a "side effect" of Dekart's initial exposure to smart-card payment systems. It makes possible the use of three factors of authentication, adding a BioAPI or HA-API compliant scanner to the authentication procedure.
Some of Multifactor's core components are:
Other important components, such as the on-the-fly encryption, and the virtual drive mechanisms were tightly coupled to the program's source code. Later they were moved to a different module, to make maintainence easier. This is how Private Disk API was created.
Private Disk Light was released in 2001, being a "Hello world" application that demonstrates how the Private Disk API works. Eventually the program became more than just a simple demo.
In 2003 it was decided that Private Disk Light would evolve as Private Disk, a commercial product; the Light version continues to be a free encryption program. This is when the original "Private Disk" became "Private Disk Multifactor". It was expected that such a change would cause a confusion among end-users, but the transition went surprisingly smooth.
Throughout this time, Private Disk API was only used internally by Dekart developers. It was decided that the API would become a product on its own, which would encourage others to build their own encryption software with minimal time investments. The API was documented, and along with several sample projects, it is distributed as Private Disk SDK, the first date of release is August the 5th, 2005. The SDK is a very easy way to build a robust encryption solution, not only that it was tested by time (since Private Disk relies on the exact same API), but it also relies on NIST-certified cryptographic modules for encryption and hashing. Certification is handled by Dekart, so the coder who uses the SDK can have this at no additional cost. Other things that are there - support for 64-bit platforms (AMD64 and IA-64), as well as Windows Vista compatibility.
2006 is an important point on the timeline, Dekart has released Private Disk Multifactor 2.0, it was shown to the public during the Systems 2006 expo in Munich. This is a special release, the most important detail about it is that it relies on Private Disk API, rather than its old codebase.

(A silent photo of the Dekart-Ritlabs stand in Munich, click to enlarge)
At that point Multifactor became a super-set of Private Disk, if compared by the available features. This brought tools such as Disk Firewall, Autorun, Autofinish to the community of Private Disk Multifactor users. All of this happened without hindering the mobility of the program - Multifactor is fully self-contained, thus it can be used directly from a removable drive on another computer. Of course it is a bit different, because if multiple factors of authentication are used, drivers for the additional hardware are needed. However, if a USB drive (or a smart card reader for which Windows will automatically find a driver) is used as a key - two-factors of authentication can be applied.
The 2.0 release had a significant impact on the speed of development, because any change made in the underlying API would automatically become a part of Private Disk and Private Disk Multifactor.
It is now being discussed whether PD and PDMF should be merged into a single product, but a decision was not made yet.
Since several APIs were mentioned, it should be noted that Smartkey is also going to be available as a separate SDK. This makes the development of smart-card based solutions incredibly simple. Ease of use is not the only advantage; besides the fact that the API was thoroughly tested and used for many years, it provides compatibility with a lot of smart cards, tokens, and other types of storage devices.
Another important detail is that Smartkey interacts with the smart cards and tokens via APDU commands. As a result, the library is very light, and there is no need to install additional modules that came from the card or token manufacturer. A positive side-effect is that Smartkey can be used to build portable programs (i.e. programs that do not require a local installation).
Dekart also plans to release an API for SIM card management, as well as the biometric API which is used internally; it is not certain when they will become available to the public, but it is going to happen after Smartkey SDK is officially released. At that time it will probably be known as "Dekart Smart Card SDK".
Password Carrier is a tool that automatically fills web-forms that were previously filled, sparing you from the task of doing it again next time you visit the page. However, in some cases you may notice that the program does not handle a page correctly, either by filling the field with an incorrect value, or by not filling it at all.
We have anticipated such cases, which is why the tool was designed to be extendable, this guide will explain how to tweak Password Carrier in such a way that it will be able to handle the pages that don’t work in the ‘out of the box’ configuration.
How does it work?
Fine tuning works by letting Password Carrier know which forms of the web-page need to be processed in a special way. This is necessary because not all webmasters use meaningful names for their forms, making it impossible for a program to ‘understand’ that the field called ‘ABC123’ stands for ‘Password’, and so on.
Case#1 – A field is not filled
It is likely that the page uses a non-standard name for that field, we’ll have to determine the name of the field by studying the code of the page and configure Password Carrier respectively.

Case#2 – A field is not filled, but I can’t find the name of the field
Sometimes the name of the field is generated when the page loads, so it is different when you reload the page.
As an example, take a look at this picture, which illustrates the login page of a fictive company named ACME; if you examine the code of the page, the names of the fields are not defined with meaningful words, each time the page loads the field is given a name like ‘37379351906’ or ‘f01asd’, and so on. However, regardless of the actual name of the field, the label ‘ACMEid’ is always nearby, so we can use it as a reference.

Case#3 – The program fills a field I don’t need
To handle this issue, follow the instructions given in the first use case in order to determine the name of the problematic field, afterwards use the Wrong mode.
Tweaking
There is a file called DPCarrier.ini in Password Carrier’s folder, editing it allows you to extend the functionality of the application. The file consists of sections, keys and values.
[FillTokens]
UserName_Exact=memnumber
In the above example:
The line UserName_ExactNameField=memnumber is the instruction that tells Password Carrier that if a field is called ‘memnumber’, it should be processed, and interpreted as a UserName field (this applies to Case#1). If you’ve had the same problem with other sites, and discovered that other fields you need are ‘serialUserID’, and ‘socialNumber’, then these values can be added to the key: UserName_ExactNameField=memnumber,serialUserID,socialNumber. As you can see, multiple values are comma-separated.
Take a look at UserName_ExactNameField, it consists of two parts:
Valid field names are:
- Password
- UserName
- AddressLine1
- AddressLine2
- City
- Company
- Country
- Fax
- FirstName
- LastName
- FullName
- JobTitle
- Phone
- State
- TaxIDNumber
- ZipCode
The valid handling modes are:
- ExactNameField – the field will be filled if its name matches the specified word
- Possible – the field is filled if the specified word is found nearby and if it is not included in Wrong
- Super – the field is filled if the specified word is found nearby
- Wrong – the field is not filled if the specified word is found nearby
You can combine these field names and modes by yourself, adapting Password Carrier to your needs. Here is an example of a customized DPCarrier.ini

Future versions of the program will provide an easier way to perform these customizations.
Sometimes the standard behaviour of the Windows OS annoys the end user - this story is about NumLock and the fact that Windows sets it to an "off" state.
The easy way to make sure NumLock is automatically turned on when you logon is to
Next time you log on with your user - the state of NumLock will be set to the state it had when you logged off.
Now, that does work, but there is still another problem - when a user is not yet logged on, NumLock is off. The explanation is simple - since nobody is logged on yet, Windows does not know which user profile to use (this is the beauty of a multi-user OS).
To deal with this, follow these simple instructions:
An alternative is to create a .REG file with this contents, then merge it into the registry
Windows Registry Editor Version 5.00
[HKEY_USERS\.DEFAULT\Control Panel\Keyboard]
"InitialKeyboardIndicators"="2"
After writing the previous story about keyloggers (free keylogger protection), another experiment was conducted; its results must be taken into account, since they make the previous conclusions complete, allowing you to see the real big picture.
Not every on-screen keyboard will protect you from keyloggers; the one that comes with Windows (osk.exe) is definitely not one of them.
Windows manages applications by sending them messages - codes that are interpreted by each program in their own way. There are different types of messages, for instance "minimize window", "close window", and so on. Among these messages, you can find keyboard-related ones, such as "a key was pressed", "a key was released". Whenever a key on the keyboard is pressed, Windows will notify the running programs about it, afterwards each program uses this information as it deems appropriate.
The on-screen keyboard works by 'artificially' sending these messages, i.e. the "key was pressed" event is not triggered by the keyboard, it is simulated instead. All the applications receive the same messages, without realizing that they are of a different origin - that's why the on-screen keyboard can be used without the risk of 'breaking' another program's functionality.
So far it is clear that the on-screen keyboard works just like the real one, meaning that the keylogging mechanisms that worked with real keyboards, will also work with the virtual ones.
Programming stuff - you can skip this paragraph
In order to catch all the key-presses, you should set up a system-wide hook, that watches WM_KEYDOWN and WM_SYSKEYDOWN messages. This way your program will be notified when normal, as well special (Ctrl, Alt, etc) buttons are pressed.
Conclusion: the standard on-screen keyboard will not offer you the protection you need. If you are forced to use a workstation you cannot trust, see the "Mouse::highlight & overwrite + arrow keys" technique.
Another important detail that must be mentioned - a virtual machine will not protect you either.
In the recent past, VMWare released a free tool called VMWare Player, which can be used with preset images of systems that are known to be 100% safe. What happens is that you do your web-surfing (and other activities you wish to keep private) in an isolated machine, that cannot be affected by external threats.
This approach is known as sandboxing - everything happens within a sandbox, nothing can get out of it, thus even if something goes terribly wrong in the sandbox, it will not have an impact on the external medium. This works the other way around too - what happens outside will not influence the processes that exist inside.
Since the virtual machine is known to be 100% safe - there is no spyware on it, no keyloggers, no viruses and so on; but what if the host system on which the virtual OS is running is infested with malicious tools?
Well, it turns out that a keylogger that runs on the host OS will succeed in catching all the key-press messages before these are sent to VMWare, meaning that a password you type in the sandbox is actually typed outside of it, and then sent 'inside', thus you are not safe.
What are the conclusions that have to be drawn?
Recent comments