Main Page

From Personal Data Security: Encryption to Fight Cybercrime and Identity Theft
Jump to: navigation, search
PDS Logo-64.png
Personal Data Security (PDS),
Software to Fight Identity Theft and Cybercrime


Getting Started

Before you use PDS

Before you use PDS, please read this !

The 2.x Documentation

Here are links to the 2.x Documentation, including the Users Guide.

Download and Use Secure and Highly Secure Ciphers

On the PDS Home Page you will find an overview of PDS. On the website you will also find a link to get PDS. Should you wish to use PDS with the secure and highly secure ciphers, you will need to purchase a PDS cipher license. To help you select which PDS certificate would be best, you will want to review the feature matrix.

In Case You Just Missed It - and More


What is PDS ?

PDS is a data security product that provides:

1) A GUI that allows you to easily implement highly secure data encryption without having to be an encrytion or security guru.

2) A multi-window editor and read-only viewer for your encrypted PDS notes. The typical use of this is as a free form passphrase manager.

3) The ability to archive your existing files into an encrypted state. This option supports encrypting a file or recursively encrypting a directory.

4) Interoperability among the major Operating Systems, to include not only running on each Operating System, but also being able to encrypt on one Operating System and decrypt on another.

5) A USB drive installation, which allows encryption without needing to install software on the Operating System.

The goals of PDS are security, reliability, simplicity and flexibility. Some of the problems it solves are:

  • What do you do with all your Authentication Credentials: PDS provides the ability to create Notes into which you can save pages and pages of information. You can organize your data by categories, with each Note keeping track of different groups of passphrases. For example, all of your banking information could be kept in one Note, utilities in another, and so on. There's no limitation to how many Notes you can create. AND THEY ARE EASY TO CREATE! Click the "New Note" icon, type in a name for the Note, and then type in the passphrase for your Secret Key. There you have it, a shiny new secure Note for your information. If you want, you can use the same Key (and thus the same passphrase) for all of your Notes, or you can create several Keys to protect your Notes.
  • Write existing Documents to an encrypted state: Encrypt any existing document - plain text files, business ("Office") documents, PDFs, ZIP files, media files - whatever you want, as big as you want. Write them to disk, or if you want, write them to tape; PDS supports both! You don't need to generate more keys; you use the same Secret Key for these encrypted files as you have used for the Notes. But like the Notes, you can also use different keys for different files. You don't need to worry about which keys go with which files; PDS handles all that for you. You can even double (or 3x, 4x, etc.) encrypt your files, each time with a different key; PDS handles that just fine.
  • Recursively Archive Directories to Disk or Tape: Happen to have several files you want to encrypt? Or maybe, a directory tree of files? PDS can help here also, as it will recursively encrypt a directory of files for you, using the same option of Secret Keys as presented above. You even have the ability to compress the resulting encrypted information, ranging from 0=none to 9=maximal compression. When you decrypt the directory, you can chose whether 1) the files should be extracted, or 2) a ZIP file should be created. As with the files, big as you want, using either disk or tape.

Is PDS right for you ?

We all have confidential data, and we all have more online accounts than we'd like. Each account has a username and passphrase, and we know that these authentication credentials for each account should all be unique. Everyone has a solution to deal with this, and some solutions are better than others; PDS is but one of those solutions. Here are some questions to see if PDS may be right for you?

  • Do you store your authentication credentials on a unprotected computer, thumb drive, or worse, on a piece of paper?
  • Would you like to access your data on different machines running different Operating Systems, with complete interoperability between Mac, Linux and Windows?
  • Would you like *secure* access to your data from a Java-enabled "public" computer, without having administrator access and without having to install an application?
  • Could you use an application with the ability to 1) encrypt several large (terabyte) files simultaneously, or 2) recursively encrypt *all* the files in a directory tree; in either case, writing the encrypted bits to disk *or* tape using a very small memory footprint?
  • Would you like one passphrase to secure *ALL* of your encrypted data?
  • Do you demand very high quality encryption?

If you answered "yes" to one or more of these questions, PDS may be a good solution for you.

What if my hard drive is already encrypted ?

Great! Please continue using that product to encrypt your disks or filesystems. However, as that type of encryption only protects your information from physical theft, you need an additional layer of encryption when you are using your system as encryption of your filesystem does not guard against malicious software (malware) that makes it onto your system. By using PDS you add an additional layer of encryption that protects your files from both theft and malware.

Why was PDS developed in Java ?

One reason that PDS was developed in Java is the Java framework, and how upgrading Java acts as an upgrade to PDS. To explain, know first that PDS 2 is compiled using Java 6. This results in a Java application that can run using Java 6, or newer JREs as well. When PDS is executed, the code in both PDS as well as the JRE are executed. And, when you upgrade your JRE, PDS then runs using an improved JVM, gaining the security improvements, performance improvements, and bug fixes that come with the newer JRE. How long can this go on? Well, given the nature of Java, apps that were compiled for Java 1.1 still run on Java 8 today. So, PDS compiled for Java 6 should still run on Java 16 in the future - with all the improvements that Java 16 provides. Practically speaking, this means that your data will remain available to you in the future, without having to keep a legacy machine around just to access your archived data.

Another positive aspect is that Java allows the PDS binary to be a single release that is not tied to a specific operating system type or operating system release. In this way, every platform gets the same features with a lot less work; which leaves more time for testing. Whether it be OS X, Windows or Linux, in all their releases now and in the future, PDS doesn't care - it just needs a suitable Java Virtual Machine.

I have heard that Java is insecure

Though Java desktop applications are not very common, the use of Java for business applications brings in lots (and lots!) of revenue. To help sustain the growth of Java, in ~2006 Sun Microsystems began to open-source Java via the OpenJDK project. With that a community of Java developers was created. The wider exposure and increase in skilled people working on Java code made a significant impact in improving the code base and expanding the available Java implementations. By version 7 the OpenJDK project became the reference implementation for Java. Selected security fixes were also back ported to Java 6, and today Java 8 continues the trend of strengthening security. For those interested, the OpenJDK vulnerabilities, the Oracle vulnerabilities and IBM vulnerabilities are all available for scrutiny.

So why do people believe that Java is insecure? Probably because there is a long and frequent history of Java vulnerability reports. But dig into those reports and you will most often find that the vulnerabilities are within a subset of Java - either the Java plug-in or the Java Network Launch Protocol (JNLP). The plug-in allows web browsers to run Applets, and JNLP allows starting Desktop applications via the browser (Web Start). Please know that PDS does not use either the plug-in or JNLP. Though the plug-in is expected to be deprecated in JRE 9, it appears it will be with us for a while longer. Until removed from the JRE the plug-in and web start can be disabled, or you can chose to install a JRE that does not contain these components. For instructions on how to disable these components and secure your system, please see the PDS installation video. To install a JRE without these web components, please see the PDS download page for a reference to the Oracle "server" JREs. If you are on Linux you may also choose to install the openjdk-8-jre (and not the icedtea-8-plugin) from the OpenJDK project.

Another reason some think Java is insecure is because of JavaScript, which like the Java plug-in also runs within the web browser. JavaScript too has been in news quite a bit as many a problem has been caused by unscrupulous JavaScript code. Though the name JavaScript appears to imply a link to Java, JavaScript is not related to Java; instead it is a scripting language from Netscape. As with the Java plug-in and JNLP, PDS does not use JavaScript.

Given the longstanding concerns with the Java plug-in, JNLP and JavaScript, and with actual security vulnerabilities (especially in earlier versions) within other components of Java, it's no wonder that many are convinced that Java is insecure. Realistically every software product seems to have security flaws, but the critical aspect of a vulnerability is in the assessment of the possible impacts. As just one example, if a certain Java vulnerability can only be demonstrated on a web server, and the impact is that the web server is unavailable to clients, that should not be a factor against developing PDS using Java.

Other aspects of choosing a language include the complexity of the language in implementing features without bugs or security issues, especially when porting the application to other operating systems. As the Java development model abstracts the unique (and often complex) implementation details of each operating system, it provides a consistent and often simpler programming model that reduces the likelihood of programming errors that could lead to security (or other) flaws. Java also makes it very easy to reverse engineer the bytecode, thus simplifying the ability for consumers to read each and every line of the code in a Java application. In the case of PDS, the EULA allows for reverse engineering with the goal of demonstrating that there is no unscrupulous code hidden within.

Thus, PDS as well as all the Java components (JDK, JRE, JCE, etc.) of the OpenJDK project are all open to public inspection.

How secure is PDS ?


  • PDS uses the Java Cryptographic Extension (JCE) framework (~ a dozen files), which are open to static analysis via the OpenJDK (open source Java) community releases. Using Java as the code base allows the same binary to be deployed on OS X, Windows and Linux Operating Systems, resulting in no "better" security in one of the supported Operating Systems. Another of Java's advantages to security is that it is much less cryptic than earlier generation languages, making the implementation of cryptographic functionalities less prone to human error.
  • The End User License Agreement (EULA) of PDS explicitly grants the ability to reverse engineer the PDS Java Bytecode for the purposes listed in the EULA. PDS needs to be trusted, and for that to be possible there should be no security holes, back doors, or networking code of any type, thus helping to ensure that your confidential data will remain confidential to you and/or your organization.

Details of the implementation are included in this summary of PDS's security:

  • PDS uses symmetric keys and block ciphers.
    • Symmetric (Secret) Keys:
      • PDS supports the AES, TDEA and DES algorithms. AES is recommended and DES is insecure. As for TDEA, earlier NIST indicated that it should be secure until about 2030, but more recently NIST has suggested that TDEA be deprecated and people move away from it as soon as possible.
        • AES:
          • AES with a 128 bit key is ideal for PDS. It is both secure and usable with all Java releases.
          • The older Java releases from Oracle contain a Java Cryptographic Environment (JCE) that supports AES key sizes "up to" 128 bits. As of the latest release of Java 8, the JCE is unlimited by default.
            • Oracle refers to this as "Strong" encryption.
            • The JCE within a JRE can be upgraded to "Unlimited Strength" encryption by replacing the default policy files with policy files that support stronger ciphers. To upgrade the JCE, please download and install the appropriate policy files: Java 8, Java 7, and Java 6.
          • The OpenJDK releases of Java provide, by default, a JCE that supports "Unlimited Strength" encryption.
          • When the unlimited strength JCE is enabled, PDS functionality will also include the ability to:
            • Create 192 and 256 bit AES keys.
            • Create and use symmetric ciphers that support the use of 192 and 256 bit AES keys.
        • Triple Data Encryption Algorithm (TDEA), commonly known as Triple-DES (aka. 3DES, DES3, TDES, DESede):
          • TDEA extends the life of DES by chaining DES operations together in an encrypt-decrypt-encrypt chain. Hence, you'll often see TDEA referred to as the "DESede" cipher in PDS (per Java).
          • There are different ways to implement TDEA; Types 1, 2 and 3. PDS only uses Type 1, which uses 3 different Keys. Type 1 is the most secure of the three types of TDEA.
        • DES:
          • DES is an insecure algorithm that is supported by PDS for educational and evaluation purposes.
          • A DES key is 64 bits in size, including its 8 parity bits; thus, the effective DES key size is 56 bits.
    • Block Ciphers:
      • Block cipher encryption done by PDS uses cipher-block chaining (CBC).
        • With CBC, each encrypted block feeds entropy into the encryption of the next block, thus randomizing the chain of blocks. To decrypt the ciphertext, one must start at the first block and then solve for all the rest. No finding the key to one block and XOR'ing the remaining blocks to get the entire message. Also, no splitting up the ciphertext into 100 pieces and sending each piece to a separate machine to hack a set of blocks.
      • Block cipher encryption done by PDS uses an Initialization Vector (IV)
        • While using CBC to encrypt files is helpful, each use of the key would leak information, and over time it would devolve to ECB encryption.
        • For this reason, NIST standards call for an IV to be added to the block cipher when encrypting the initial block.
          • This IV should be unique for each "first block", and it should be generated randomly.
            • In PDS 2, a unique IV is generated for each new encryption operation.
        • Block cipher encryption works on data of a fixed size - the size of the block of the algorithm.
          • AES uses 128-bit block sizes, while DES (and thus TDEA) uses 64-bit block sizes.
        • More often than not, the bytes to be encrypted do not terminate exactly at the end of a block.
        • For that reason, padding is used to fill in the remaining bits in the final block.
          • PDS uses PKCS-5 padding with all the ciphers.
Strength of Your Credentials vs. Time to "Brute-Force" Guess Your Credentials
Number of Characters Used Number of Possible Characters
62 (A-Za-z0-9) 83 (A-Za-z0-9 ++)
Permutations Max Guess Time* Permutations Max Guess Time*
6 4.43E+10 0 Seconds 2.72E+011 0 Seconds
7 2.48E+12 2 Seconds 2.09E+013 21 Seconds
8 1.36E+14 2 Minutes 1.59E+015 27 Minutes
9 7.36E+15 123 Minutes 1.19E+017 33 Hours
10 3.90E+17 108 Hours 8.83E+018 102 Days
11 2.03E+19 1 Year 6.44E+020 20 Years
12 1.03E+21 33 Years 4.64E+022 1471 Years
13 5.17E+22 1641 Years 3.29E+024 104446 Years
14 2.54E+24 80386 Years 2.31E+026 7 Million Years
15 1.22E+26 4 Million Years 1.59E+028 504 Million Years
20 2.24E+34 710251 Billion Years 1.99E+037 631046 Trillion Years
* Based on one trillion guesses per second.
  • PDS relies upon your use of secure authentication credentials.
    • The best ciphers in the world can be defeated by a brute force attack on a weak set of credentials.
    • You have probably heard or read about breaching the encrypted information on a Android or iPhone.
      • Both can be breached, but Android appears to be vulnerable using generic hacking knowledge and tools, whereas iPhone requires access to specific aspects of the Apple hardware.
    • PDS uses well known software (a Java KeyStore) to hold the encryption Keys, and the Keys are protected only by a single passphrase.
      • This means that there is well-known software that can run brute force attacks on a Java KeyStore.
      • A freely available software program ran at ~200K attempts per second on a $200 Chromebook.
      • A generic supercomputer, or a much smaller purpose built GPU cluster, can do quite a bit more.
    • The number of password combinations increases based on 1) the possible, and 2) the actual number of, characters in the credentials.
      • The table to the right attempts to demonstrate the value of larger and more complex credentials.
      • As you should see, using characters from the set of 83 provides significantly longer times than the set of 62.
    • So, it really is best to use long, complex passphrases instead of passwords. It's simple math:
      • (# of passphrase permutations) == (# of possible symbols in passphrase)(length of passphrase)
    • And what is a passphrase? A phrase, often consisting of random words strung together.
    • PDS has been tested for Key (and KeyStore) passphrases up to 128 characters.
    • So use one super passphrase to protect the Key that encrypts all your PDS Notes.
      • Your PDS Notes will then contain all the other passphrases that you no longer have to remember.
  • Security
    • Speak with an expert about the security of an encryption scheme and they will tell you about randomness.
      • Recall the CBC and IV points above.
    • Every language provides different tools for randomization.
      • Each has advantages and disadvantages.
        • Typically it's a balance between randomness and CPU utilization, with the implementer to decide.
    • Below is some information about how PDS security differs from other types of encryption:
      • SecureRandom (a Java class) is used to generate the aforementioned IV.
      • SecretKeyFactory (another Java class) is used to generate your symmetric Keys.
      • Your Key in then stored in a Java KeyStore.
        • To create your Key, a large salt (also created by SecureRandom) is added to the Key passphrase you provide.
        • The salt + passphrase is then hashed many times using PBKDF2/HMAC/SHA1 to create your Key.
          • SHA1 collisions are problematic for digital signatures.
          • Using SHA1 for properly implemented key derivation functions is approved by NIST.
        • The use of these techniques (salts, multiple hashing iterations) are attempts to slow down dictionary and brute force attacks against stolen credentials.
          • With many possible fingerprints for each password, there are more combinations to compare.
      • As PDS Keys are stored in a KeyStore, PDS Keys do not leave a visable fingerprint that can be used in a typical attack.
        • Instead, KeyStore-specific tools must be used, similarly using word lists and then brute force.
    • So, as demonstrated in the table and text above, your password (or better yet, your passphrase - up to 128 characters in PDS) is your most important line of defense.

Does PDS have security issues ?

Yes. First there are the known security issues. Then there are the unknown security issues.

The first known issue is with the expected interaction with PDS. As we all know, it is much easier to cut/copy/paste than typing something out. And when it comes to correctly typing a long, random password, it's not feasible to do that - so we cut/copy/paste. In doing so with, for example, a password, the password would be copied into the system clipboard. The clipboard is a singular place where information can be shared. Thus, a rogue process running on the system could read from the clipboard, and if a password were in when it was read, the password would be compromised. As PDS was not designed for state secrets, PDS has a simple keystroke (or click sequence) to clear the clipboard to help mitigate the case with a rogue process reading from the clipboard.

The remaining of the known issues relate to an attacker being able to read from RAM. Protecting applications against this, especially when the attacker is an administrator (or has the privileges of an administrator) may be impossible on any commodity operating system.

With that in mind, the known concerns are:

  • Passwords for encryption Keys: Most of the encryption scenarios follow this pattern: 1) a unencrypted character array is initialized with the password to access a Key, 2) the password is immediately (in human time, not computer time) used to obtain the encryption Key, 3) the contents of the password array are "immediately" overwritten, 4) the encryption key is used to encrypt/decrypt, and 5) the encryption key is freed. In the scenarios where a Note remains open for edit, the encryption Key is freed but the password remains in an array in case the Key needs to be retrieved again. The password is not overwritten until after the Note is closed. The net effect is that the referenced password is unencrypted in RAM for a very long period of time.
  • Garbage Collection: When the Java garbage collector runs it may move a referenced password array without scrubbing the freed memory. This means that passwords may remain somewhere in memory, unreferenced, until that memory is overwritten.
  • Passwords for Notes opened for editing: Similar to the first scenario, PDS Notes use Java Documents to hold your information. While the Documents remain in RAM, the contents of those Notes may be read from RAM.
  • JVM Heap Dump: Should you configure and trigger a JVM heap dump, the objects (most notably the Keys and Notes) would be written to persistent storage.

Given that this application is for Personal Security and not National Security, it is believed the known security issues should be acceptable for most people.

How do I get PDS ?

The home for PDS is - it is the primary location for PDS releases. Links to other sources may be found there as well.

Current information and instructions are provided on the PDS main page as well as on this Wiki. The software distribution also includes a README.txt file.

Regardless of how you get your copy of PDS, you should verify the authenticity of the application you have received. Instructions to verify the fingerprints are included within this Wiki.

Why can't I save my PDS license ?

First, thank you for purchasing a PDS license. If you have received an email indicating that the PDS license is attached, but you are not able to download the license, some mail clients (Thunderdbird, Evolution, etc.) are unable to display the attachment properly when using HTML as the default display format. As a workaround, it seems that (temporarily) changing the mail client to display Text format resolves the problem and allows the PDS license to be downloaded. For Evolution (3.2), a process that works is 1) Edit->Preferences->Mail Preferences->HTML Messages->Show plain text if present, and 2) enable "Show suppressed HTML parts as attachments". Hopefully these steps will not differ much from Thunderbird and other versions of Evolution.

What if I have a question ?

If you've reviewed the PDS website, Quick Start Guide (also within PDS), Release Notes and README (within PDS) and you still have a question, please email the appropriate contact below:

Question: (GPG Key)


Report a Bug:

Security Topic:

(C) PDS Software Solutions LLC, 2016
By using this website, you signify that you agree to be bound by the express terms of use.
We value your privacy.
Personal tools