PROTAGON File Crypters (PFC) documentation by EddyHawk
---
What
---
A collection of win32-based file encrypters.

They are coded by EddyHawk (me).

I choose '1 program for 1 cipher', '1 input to 1 output',
 'command-line driven' scheme to ease the implementation.

They are freewares, sharing similar interface & codes.

---
Why?
---
I want to code my own file crypters as easy/small/safe/fast as I can.

I don't want to be restricted to code for just 1 cipher, or
 to code multiple ciphers in single program.

Most decent single-file crypters are outdated.

Non-outdated ones are mostly using AES cipher only.

---
Why Should I Use This?
---
Has non-AES ciphers.

Not outdated, probably safer than other file encrypters.

Fast AEVD (Authenticated Encryption & Verified Decryption).

Components and parameters are optimized to fit the cipher theme/requirements.

Fully functional freeware.

Straightforward. Easy to use (in 'command-line driven' sense).

Ready executable. Stand-alone executable. Small executable.

No (un)installation required. No dependency. No littering.
 DOESN'T require any of these 'craps' to run properly:
  MSVC/MSVB runtime, JRE ME/SE, .Net/Mono, Cygwin/Mingw, Python, Ruby, etc.

---
What Crypter is available in PFC, And What Cipher Each Used
---
Block ciphers:
AESir   : AES
Anub    : Anubis(t)
Fisces  : Twofish
Serpen  : Serpent
Shacat  : Shacal-2

eSTREAM finalists:
HC16    : HC-128
Sosem   : Sosemanuk
Salsax  : (XSalsa20/r)

Stream ciphers:
HC32    : HC-256
Phel    : Phelix
Arcfopa : RC4+A
ISAC    : ISAAC

My modifications:
Chax    : XChacha/r
Chixa   : XChicha/r
Rocfort : Rocfort

My own 'cipher':
Fenric  : Fenris

---
Which One To Use
---
That depends on your preference for the cipher used:
Follow-the-crowd: AESir
Contest winners: AESir, Shacat, Sosem, HC16, (Salsax/12)
Conservative: Serpen, Salsax/20
Orthodox: AESir, Anub, Fisces, Serpen, ISAC
Performance: Phel, HC16, Sosem, (Chax/Chixa/Salsax)/8, Fenric
Cache-timing immune: Shacat, Salsax, Chax, Chixa, Fenric
Novelty: Arcfopa, Rocfort, Chax, Chixa, Fenric

What do you recommend?
Fisces, Anub, Serpen
Salsax, Sosem, Phel, Chax,
and yeah, Chixa, & Fenric :) 

---
Min Required
---
386?

Win95?
 But only tested on WinXP SP(2/3) & Win7 Ulti SP1 64bit. Not yet tested
 on Win(Vista/8/10).
 Update: 5th release doesn't run on Win7 64bit, but 6th + do.

Uses
 ~1.?Mb mem on WinXP SP2,
 ~3.6Mb mem on WinXP SP3,
 ~2.9Mb mem on Win7 64bit,
 eventhough the real usage should be < 100kb mem.
 Weird, huh? Ask M$!
 Note: crypters w/ mem-hard KDF need additional 4 or 8 Mb mem.

Utilities (that should be obtained elsewhere):
 file-comparing program, file-shredding program, file compressor or archiver,
 password manager, human-password generator

---
Features
---
Checks for & rejects equality of input_file with output_file :)

Supports long input/output file name like LongishFileName.txt by using
 "LongishFileName.txt" (double quote) without me have to do a thing
 (the benefit of using win32 compiler :)

Supports files > 2.1Gb (on FAT) or > 4.2Gb (on NTFS), eventhough it doesn't use
 64bit integer :)
 PFCs will only complain that it 'Can't Close WriteFile' for such files,
 but that's all (no actual error or anything)

File buffer, 16kb large, to speed up the operation.
Special 'xorbuf' for most PFCs using stream cipher, for further speed-up.

Passphrase display hider, not even its length is shown.
 '?' char means that passphrase buffer are currently empty.
 '/' or '-' or '\' or '|' mean that passphrase buffer contains 1+ char.
 Re-type for confirmation, but only during encryption.
 Message about passphrase minimal length, only during encryption.

1-255 chars passphrase, case-sensitive.
 Passphrase length is included as the 1st char (thus 2-256 chars passphrase)

Passphrase random salt, combination of:
 long-term data: initial messages of the PFC
 short-term data: 256bit random value produced by Fenris PRNG with random
  sample/input/seed taken from the continuously incremented 32bit value between
  user keypresses while he/she types/edit the passphrase, plus two samples
  taken from randomize which is called from different times;
  of course the keypress chars aren't included (that's the passphrase!)
 processed w/ hash function once & the resulting digest is truncated into
  128bit before it's written as 1st prefix of the ciphertext.

PbKDF2-HMAC
 Optimized, so it now runs ~2x faster (or half delay at same iterations),
 benefiting the users.
PbKDF2-HMAC-SHA512 w/ 9000 iterations with  512bit output
PbKDF2-HMAC-Whirlpool w/ 9000 iterations with 512bit output
 The 512bit output is splitted into 3 parts: encryption key, middle data,
 and IV/nonce. Their size are dependent on cipher's requirements, say
 128bit key, 256bit data, 128bit IV; or 192bit key, 192bit data, 128bit IV.
 The 512bit output is also input for authentication mode.
 HMAC uses the whole 512bit output as its authentication key, but
 built-in MAC only uses the middle data as its authentication header
 (not written to ciphertext)
 One benefit of this approach is that IV isn't written to ciphertext.
Double PbKDF2-HMAC-SHA512 w/ 9000/1 iterations with 512/8192bit output
PbKDF2-HMAC-SHA256 w/ 48000 iterations with 256bit output
Double PbKDF2-HMAC-SHA256 w/ 48000/1 iterations with 256/3x256bit output
ScryptA 65536-1-1
EPHS-DAZH512-Chicha/2 4Mb memory, 6 iterations

Uses max key size supported by the cipher, if possible.

Simple progress indicator.

128bit truncated MAC/authentication tag, written as 2nd prefix of
 the ciphertext.

Headerless ciphertext (no identifier, magic bytes)
Random-sized random data addition (except Phel), written as 3rd prefix of
 the ciphertext.
 This makes harder to determine the starting point of plaintext in
 the ciphertext, and early encryptions will be applied to random data
 instead on the known header or pattern of common files.

Fast Verify.
 test whether you remember passphrase correctly without decrypting
  the corresponding ciphertext & also verify the integrity of salt,
  ciphertext, & tag, while avoiding it to be a shortcut way for adversaries
  (except Phel, in which its built-in MAC requires it to decrypt
  the ciphertext, but only in memory)

Clears used memory before exit.
Clears each used memory right after being used the last.
 Should minimizes data lying around in memory under fault cryptanalysis.

---
Unsupported Features
---
(Back/For)ward compatibility.

Preserves the file original name, its time/date, & its attributes.

Data compression.

TAR-like archiving.

Parallelism, native 64bit.

File wiping.
 Auto file wiping.
 Write-through cache.

Lock memory page to prevent data being written to OS' swapfile.

In-memory encryption.

Anti keylogger (if possible).

Options to show the passphrase, to accept pasted passphrase.
 However, if you use a Password Manager with Auto-Type feature
 (simulating keystrokes), it works with PFC. But the PM I tried actually
 add 'Tab' char in front of the passphrase when auto-type it, so you should
 check the output of such feature beforehand (say to a text editor since PFC
 doesn't show the passphrase). And it's preferred for decrypt/verify only
 since during encryption PFC will get less sampling from your typing
 (not from your passphrase) to generate the random data required.

---
How To Use
---
Before you encrypt any important file, first you need to ensure that the PFC
 works perfectly by testing it a few times on unimportant files.
 Don't use it if the PFC doesn't work as it should be.
 This also apply to any kind of compression/encryption software, not just PFC.

After you encrypt any important file, and after you really remember
 the passphrase you've used for that encrypted important file and
 after you ensure that the encrypted file is decryptable correctly into
 that important file (by launch a file-compare program to compare the original
 file with the decrypted file, not by comparing their filenames), then
 you should strong-delete (wipe) that file & all of its copies, leaving only
 that encrypted version. Otherwise there's no point of encrypting it.
 If you want to make backup, make it from the encrypted file.
 If you feel that you will probably forget your passphrase and more concerned
 about restoring your file back, you can write the passphrase down or store it
 to your wallet/purse or to a Password Manager program.
 This also apply to any kind of encryption software, not just PFC.

You may also need to put the PFC location in PATH=, perhaps also backing up
 a copy and store it together with the encrypted file, and make sure that you
 won't forget to use the same dated PFC when decrypting the encrypted file
 in the future ('date' here means the date reported by the PFC when you launch
 it, not the program exe date).

Launch the PFC from Windows' Start/Run..., DOS Prompt, or from file manager
 like Total Commander.

To encrypt a file:
 <program name> <to-be-encrypted filename> <encrypted filename>
 Example:
 "fisces document.txt crypted.txt" (without the quotes)

To verify an encrypted file:
 <program name> <encrypted filename> </v>
 Example:
 "fisces crypted.txt /v"

To decrypt an encrypted file:
 <program name> <encrypted filename> <decrypted filename> <d>
 Example:
 "fisces crypted.txt decrypt.txt d"
 (Extra parameter(s) after both filenames = tells PFC to perform decryption
  instead of encryption, so you can replace 'd' with other char if you want)
 "fisces crypted.txt decrypt.txt r"
 "fisces crypted.txt decrypt.txt de"

All PFCs are operatable in the same way.

The PFC will report what mode it is under:
 '[MODE: Encrypt]' or '[MODE: Decrypt]' or '[MODE: Verify]
 and also report the input & output filenames you've specified:
 '[FILE: <>]  (input file)
   TO
  [FILE: <>]' (output file, shown on Encrypt/Decrypt mode, not on Verify mode)

In all of these three operations, you will be asked to type a passphrase.
Under encryption, that means you are asked to compose a new passphrase
 while under verify/decryption, you are asked to supply the passphrase for
 the encrypted file you've specified in order to check/undo the encryption.
You won't see the passphrase while you type it. Instead, you will be shown
 one of these chars: '?','/','|','\', and '-'.
'?' means that you haven't type any passphrase or you just remove the entire
 typed passphrase by holding BACKSPACE key.
Other chars mean that you already types one or more chars as passphrase.
BACKSPACE key will remove an existing char you typed.
Not all possible chars can be used as passphrase, for example control chars
 like #0, #8 (BACKSPACE), #13 (ENTER), #27 (ESC), etc.
Press ENTER key when you complete the passphrase typing.
Under encryption, you will asked to retype the passphrase you've just entered.
 Why? You may intend to use a certain passphrase but unintendedly typed
 the wrong char(s), making it different passphrase instead.
 Here, retype helps to catch such error.
 The PFC will abort if those passphrases aren't matched.

Once you press ENTER key, the PFC will perform the operation and shows
 a simple progress indicator before it finally saying 'Done!'
 Under encryption/decryption, a new file should have been generated
 to where you specify it.

Now, check what MAC Verify says after any verification/decryption.
If it says OK then everything should be okay, obviously.
But if it says FAIL! during verification &/ decryption, then:
-you typed the passphrase incorrectly, or
-you typed the passphrase correctly but not for that encrypted file, or
-you typed the passphrase correctly for the correct encrypted file,
 but the encrypted file is erroneous, perhaps due to disk error, or
-the specified encrypted file is manipulated by evil doer(s), or
-this program has unexpected error(s) or bug(s).
In any case, don't trust the encrypted file nor its decrypted file.
But it probably just a passphrase typing mistake. Please try again.

Finally, press a key to close the program (window).

---
History
---
1st release [Apr 2011]
 uses newest WE's sources at that time [2009], GUI-like, uses Fenris as PRNG,
 clears mem right after last use, comprises some crypters, separate package
 for each crypter
2nd release [May 2011]
 various minor fixes, comprises most crypters, separate package for
 each crypter
3rd release [Jun/Oct 2011]
 improved Fenris' accu, IOcheck for every IO, rand-sized rand-dat for most
 crypters except Phel, comprises all crypters, unified package
4th release [14 Nov 2012]
 much faster (de)crypting/verify due to safe? combo of MD4 + 512bit HMAC
  (SHA512/Whirlpool) to all crypters,
 all crypters w/ block cipher uses CFB128 mode,
 Serpen uses 16kb file buffer (mainly for Fast Verify),
 Salsax, Chax, Chafx, Sosem: uses full buffer when Fast Verify
5th release [14 Nov 2012]
 change 'Paranoid' name to 'Pharagon',
 new crypter: Chix (improved? ChaCha), removal of transposition for odd number
 of rounds, & new BASM32 core for Chax & Chix (faster crypt),
 many changes to Fenris (thus changes Fenric), modify Fenris' accu,
 all crypters doubling PRNG output as hash input to the salt,
 remove Chafx completely (not faster than Chax)
6th release [2013]
 change 'Pharagon' name to 'PROTAGON'
 modify Fenris' accu (again)
 new single-buffer xorbuf for Salsax/Chax/Chix/Sosem for improved speed
 new optimized BASM32 core for Serpent
 new crypter: ISAC (uses ISAAC CPRNG)
 new BASM32 core for MD4: faster (de)crypting/verify for all PFCs but Phel
7th release [2015]
 faster BASM32 core for MD4
 Serpen now allows 8,16,24,32 rounds
 Chix: Chichi is modified to achieve near ideal chi-square on 2 rounds
  previous Chix isn't faulty, though
 new crypters: Arcfopa (uses RC4+A), Chixa (uses XChicha)
 Chixa: slight optimize to double-round, uses my DAZZ-128 basm32 instead of
  MD4 basm32
 Chax: slight optimize to double-round
 removes Arcfop
8th release [2016?]
 minor fixes to Chax & Chixa
 remove Chix
 all affected crypters:
  upgrade to WE's latest sources (but not all)
  optimized PbKDF2-HMAC: 2x faster (tested at 8192 iterations w/ SHA512)
 Chixa, Fenric, Rocfort now use DAZZ-128 & EPHS-SHA512-Chicha/2 4Mb-6i
 new crypters: Chixaa, Fenrica, Rocforta (use ScryptA instead of EPHS)
 AESir & Anub get 9000 PbKDF2 iterations
 SHA256 & SHA512 speed-up, allowing crypters using pbkdf2-hmac-sha512 &
  pbkdf2-hmac-sha256 to pack more iterations at the same latency
  (9000 & 49000 respectively) 
 new crypter: Shacat which uses Shacal-2 & SHA256 (double PbKDF2-HMAC
  48,000/1 iterations), HC16a which uses PbKDF2-DAZH256 150,000 iterations
 modified: ISAC now uses double PbKDF2-HMAC-SHA512 9000/1 iterations
  w/ 1,024b output, HC16 now uses SHA256 (PbKDF2-HMAC 48,000 iterations)
 DAZZ-128 is renamed into DAZH-128
 modified Chicha core algo, affects Chixa(a), DAZH-128, & EPHS-based crypters
 affected crypters use MD4 finalize now
 Chixa now uses DAZH-512 & no HMAC
 Phel now has fixed-size random-data addition (64 bytes)
---
FAQ
---
You usually choose 256bit cipher key. Do I have to type 32 chars as
 the passphrase, then?
 Of course not. The passphrase length is 1-255 chars, but the passphrase is
 turned by PbKDF2 as fixed 256bit key. Thus whether you type < 32 chars
 or > 32 chars, the key used is still 256bit key, which is usually the maximum
 length accepted by the cipher.
 However, the passphrase actually processed by PbKDF2 is a Pascal short string.
 Thus if you type 8 chars, the actual passphrase length will be 9 chars where
 the first char is the passphrase length.

But how if I managed to get say 40 chars as passphrase? Then your PbKDF2
 will instead reduce its strength!
 Very unlikely. You won't be able to remember passphrase that long without
 write it down somewhere. You'll be very annoyed yourself if you have to type
 40 chars everytime you want to encrypt/decrypt. Your 40 chars is certainly
 having much less than 40 bytes of entropy.

If users aren't expected to be able to provide decent entropy (say 128bit
entropy) from their passphrases, then why you insist on using 256bit key?
 Because with hashed passphrase, the attackers' knowledge/prediction of
 the actual entropy can't help them speed up the attacks.
 When dictionary attacks fail, they must resort to brute-force attack which is
 ignoring entropy estimation and which is hampered by larger key length.
 So insisting on larger key is actually a thicker line of defense in this case.

Then what is the minimum safe passphrase length?
 1-4 chars (a word) is clearly not safe. 10 chars is perhaps the minimum.
 The longer & more complex, the better. Be novel, unique, original, & creative
 when creating/composing it. It must be memorizable to you only, but hard
 to guess by everyone else (including your boss, friends, (grand)parents,
 spouse, children, especially adversaries, etc.)
 Preferably, use a safe Password Manager having built-in, customizable
 password-generator to generate long passphrases & to store them for you.
 Whenever applicable, compose or generate different passphrase for different
 file to be (re)encrypted.
 PLEASE don't use 'password', 'password1', '123', 'abc', 'abcabc', etc.
 as your passphrase because those are surely the first ones to be checked
 by attacker(s).

Why you choose all block ciphers in PFC to use CFB mode?
Why not CTR, CBC, OFB, etc.?
 CFB seems to be the least problematic mode.
 Visual error check is possible with CFB due to its error propagation.

Why use your new, not yet freely available, not publicly tested, PRNG?
 Some file crypters don't even use any PRNG nor tell what PRNG they use,
 Using other PRNGs in PFC won't make it safer anyway,
 CPRNGs from WE sources simply use cipher and thus enforcing entropy =
  cipher's total key & iv size, which often aren't attainable at startup,
 Other 'famous' CPRNGs (ex: CSPRNG, Yarrow, Fortuna) have no Pascal
  implementation, will refuse to work in PFC due to unrealistic startup
  entropy expectation (eg: demand too much inputs at startup while there
  aren't anymore, won't generate any output until entropy requirement
  is deemed enough eventhough no more entropy is possible at a given time
  when outputs are demanded), or be tied too closely to hardware/OS/low-level
  functions, or take too much code/resources to be included in PFC, or needed
  to be run too long in PFC before its outputs can have any crypto quality.
  So far I only know 2 crypt progs using them (1 using CSPRNG, 1 using
  Yarrow-like),
 No other PRNG is suitable for PFC requirements: includable to small progs,
  quick but fixed time startup, capable of accumulating large enough entropy,
  works with variable inputs at variable times to prevent unusability
  (the last is the reason why I don't call it CPRNG).
 But for crypto-worried users, only 256bit data & random-sized junk data
  are generated from the PRNG, the data is only used as salt & it is still
  hashed once beforehand with the 512bit hash function being used.
  Random-sized junk data is also encrypted just like the plaintext, so those
  2 PRNG outputs are never seen in the clear.

Why use Whirpool/SHA-512 instead of say SHA-256 for PbKDF2?
 SHA256 is 256bit hash, which doesn't seem enough for generate 256bit key
 & 128bit nonce, while otherwise PbKDF2 allows shorter derivation key with
 larger digest. Longer derivation key is actually supported by PbKDF2, but
 it's not safe without additional handling.

The specified iterations for PbKDF2 with 512bit hash func is overwhelming!
 Commonly used value, 1000 iterations, is no longer slow enough to stall
  hardware brute-force/dictionary/rainbow-table attacks, especially since
  we now know that we will eventually resort to use weak, short, never changed
  passphrases.
 8192 iterations of unoptimized PbKDF2-HMAC only takes ~0.7 second on
  Intel Atom N270 @1.6Ghz, and 9000 iterations of optimized PbKDF2-HMAC
  takes ~0.3 second on Intel Celeron 1007U @0.8Ghz,
  which are the cpus for 2 low-budget netbooks.
 Thus I specifying 9000 iterations.

MD4 is severely broken. Why use it?
 Because it's the fastest ever. By using it, the slower performance of
 authenticated encryption and verified decryption are minimized.
 And MD4 here works only as 'CRC-128' and its hash is never seen in the clear.
 It's also tightly intertwined with HMAC-Whirlpool/SHA512/SHA256 in case
 attackers attempting MAC forgeries of PFC by using MD4 breaks.
 We can use MD5 instead of MD4 but it won't fare much better in this hybrid
 (MD5 is also broken) yet surely slower than MD4.

Are you sure such hybrid (MD4 with Whirlpool or SHA512) is safe?
 Quite sure :)
 MD4's preimage & 2nd preimage resistances, which are more relevant
 in this usage, are still 2^70.4 (w/ large pre-computation)
 & 2^64 (w/ pre-compute), of expected 2^127 & 2^127.

Where are the source codes?
 PFC aren't open source. Besides, most crypto codes used here aren't mine
 to be open-sourced.

Then how can I be sure that PFC aren't malicious software?
 With the same trust you are given to any program you downloaded like
 non-open-source but freeware antiviruses or anti malwares. You don't have
 access to their source codes, but you trust & use them instantly, right?
 If you don't trust PFC to use it without source code, you can choose to
 not use it. And remember that there are also other file encrypters
 (from other authors) without released source code (for example,
 the source code for their GUI version).

I want another cipher/hash function in PFC!
 Most crypto algos in PFC are taken/adapted from WE sources. Thus if WE's
 don't have certain cipher/hash, you won't get it too from PFC. And I choose
 to skip some ciphers/hashes from WE's because they:
 -are not interesting for me, can't fulfill the theme I want,
 -are outdated (say, 64bit block ciphers), unsafe, got severe timing attacks,
 -are obviously slow with their safety unknown,
 -can't be safely implemented in PFC.
Please be more specific about your exclusions!
 Blowfish, XTEA, Skipjack: < 128bit block ciphers
 Camellia: severe cache-timing attacks reported, not absolutely? free use,
  not fast
 SEED: 128bit key only, not fast, no cryptanalysis
 SHA-3 (Keccak) 512: slower(!) than SHA-512 in SW, SHA-2 still safe as of 2015
 Blake-512, Skein-512, BLAKE2b: WE doesn't implement them
 PHC winner(s): if WE implements (one of) them
 Poly-1305: WE implements it, but it's not recommended for message > 1Gb

Uh, my AntiVirus app claims that your PFCs are (infected w/) malware...
 If you download them from my/trusted sites, then your AntiVirus is wrong
 (false positives). Original PFCs are not (infected w/) malware, no matter
 what some AntiVirus may say. Get a better AntiVirus :)

PFC sucks. Can you recommend other file crypters?
 How unfriendly :( But you may take a look at my EHIL/crypter.txt.

Strong cryptography is unallowed in my country. Can I use PFC then?
 Unallowed? These days? Perhaps you can try the experimental ones.

---
Caution
---
This program is always in the alpha status.
 It means that the program is only tested by the author (me).
 To be safe, try to encrypt and decrypt a few test files to ensure whether
 it run properly on your cpu(s) and it can really give the data back.

No fix/update guarantee for freeware.
 (Known) bugs may not (be able) or won't be fixed, reported or not. 
 New features may not (be able) or won't be added.
 This program may no longer be developed any time in the future.

No compatibility is maintained between versions of this program!
 Always use the same program reporting the same date for encrypt and decrypt.
 Using the same program but having different dates may / may not work.
 If you download the same but newer dated PFC, you need to retest it again
 and keep the older dated PFC to decrypt the matching older encrypted file(s).
 Older versions may not be maintained at all.

No warranty, As-Is
 I won't be responsible & responsable if you lose (some/any/every)-thing
 from using this program, or even when the program fail to do what it
 is supposed to do due to unexpected bugs, implementation mistakes, etc.
 Use it at your own risk.

Contribution/Donation is strongly encouraged.
 But duh, I haven't set up any PayPal/Bitcoin account :(

Regarding this program, all fame & blame goes to EddyHawk, not the other
 parties mentioned in this doc.

You can't copy&paste your passphrase to this program, you need to type it
 manually. So beware of keyloggers!

Never forget your passphrase, ever, if you want your file encrypted with
that passphrase to decrypt back into correct unencrypted file.
 I can't help you with forgotten passphrase.
 The passphrase isn't stored in the encrypted file or in anywhere else.
 There is no (trap/back)door put into the program or into the encrypted file
 it created.

PFCs don't overwrites/delete the input file afterwards since it's a quite
dangerous thing to do.
 Confidentiality is important but legitimate restorability is even more.
 Get and use a decent file-shredding program for that purpose, after
 the encryption is successful and the decryptability is confirmed by you.

Encrypted file size will always be enlarged by 33 + 0-255 bytes
 than its unencrypted counterpart, while decrypted file size will always
 be decreased by 33 + 0-255 bytes than the encrypted counterpart
 (except Phel, encrypt increases it by 96 bytes, decrypt decreases it).
 Thus, don't decrypt an unencrypted file.

PFCs labelled as 'experimental' ('not for serious use') should be treated
 as it is.

I don't claim that you will gain security by using this program.
 Security involves much more things than just encrypting a file with
 a passphrase, no matter how strong the encryption & the passphrase.
 An encryption software is just a tool which may be able to help you
 achieving it. But some security 'experts' want you to believe much
 further than just that. Instead of just 'strong encryption may gain
 confidentiality', they foolishly extend that into 'using just the strong
 encryption absolutely gain security'. Why do these people impose security
 into encryption? Since when security equals to encryption?
 Now thanks to those people, almost nobody write/update his/her
 file encrypter anymore, not even the good ones, because everybody
 now unrealistically want 'security' from 'secrecy' tools and then abandon
 all of them since those are said not 'secure'.

---
More Info
---
More/detailed/technical infos can be found in other doc accompanying each PFC
 that have the same name (eg., read fisces.txt if Fisces interests you).

End.