AxCrypt File Encryption Software for Windows Quick Installation Guide Version 1.6.3

January 2008

Copyright 2005-2008 Svante Seleborg, Axantum Software AB
This guide describes how to install and quickly get started using AxCrypt to encrypt, decrypt, edit, store and send documents privately and securely. The following topics are covered: 1. 2. 3. 4. 5. Additional information Requirements and limitations Installation procedure How to use Information on security
1. Additional information This quick guide only contains the basic information necessary to get started with AxCrypt. Please refer to the following resources for further information:
http://axcrypt.sourceforge.net
Full Documentation Privacy Policy FAQ Command Line Usage Introduction to encryption White Paper About AES White Paper Public Key Based Licensing Information about other encryption software About the maker of AxCrypt Source code Beta versions Forums Mailing list

http://www.axantum.com

http://sourceforge.net/projects/axcrypt
2. Requirements and Limitations AxCrypt requires very little and is compatible with all current versions of Windows. Resource Memory (RAM) Hard disk space Temporary disk space Processor Operating System User permissions Installation permissions Maximum file size Value About 5 Mega bytes of virtual memory when active. 2 Mega byte Up to about 1.5 x the size of a file being encrypted. Pentium Windows 98, ME, NT 4 sp 4, 2000, XP Home, XP Professional, 2003, Vista Any user can run AxCrypt Administrator in NT, 2000, XP, 2003 and Vista. About Mega byte on Windows 98 and ME. Only limited by disk space on NTFS. Only limited by disk space. To recompile AxCrypt from downloaded source code you need Visual Studio 2005 or later.
Maximum number of encrypted files Development environment
3. Installation Procedure This section will explain how to install AxCrypt, step by step. Important! You must be able to log on as a system Administrator to install AxCrypt on Windows NT 4, 2000, XP, 2003 or Vista.
Get the latest version To install AxCrypt you need the installation program, please find and download the most recent release on http://axcrypt.sourceforge.net before continuing. When you download, you may chose to either store the file on your computer, and run it later or you may run it directly from the download site. If you run it directly, skip directly to Verify Digital Signature below. Run the installer The installer is typically named AxCrypt-Setup.exe, but it may also be named after the version, for example AxCrypt-1.6.3.exe. Double-click the program to run it. Verify Digital Signature (Windows XP Service Pack 2 or later) Windows XP Service Pack 2 or later supports automatic verification of digital signatures of executables downloaded from the Internet such as the AxCrypt installer. The digital signature gives you some assurance, if properly verified, that the software is not infected with a virus or contains other hostile code. AxCrypt is digitally signed by Axantum Software AB so you can ensure its authenticity.
You should see a dialog similar to the following:
If you do not see a dialog at all this is not a problem only if you see a dialog like above, but which cannot be verified or contains unexpected names should you be wary. Chose Language AxCrypt supports a number of languages for its dialogs and commands. Please select a language when prompted:
Click OK when you have selected a language. The rest of the installation will proceed using that language, as will AxCrypt menus and dialogs.
Accept the license agreement AxCrypt is licensed under the GNU General Public License. This is an open source license which essentially gives you the right to free use and distribution of AxCrypt as long as you do not charge money for the software, and that you make any changes available in source code form as well.

Click I Agree. Sign up for notifications of updates As a user of AxCrypt you may sign up for free notifications of updates. There are three levels available: Notifications are sent for every new version.

8(19)

Only send notifications of critical security fixes. Do not send any notifications (not recommended).
Please do not supply an invalid e-mail address! If you do not wish to supply one, just leave the field blank.
Enter you valid e-mail, or blank the field Select your notification level Click Next Chose Where to Install (Advanced Users Only) You have the option to change the location where AxCrypt is installed.
There is no normally no need to change this, just leave this as it is unless you know why you want to change it.
Click Next Choose a Start Menu folder (Advanced Users Only) You now have the option to change the default location of the Start Menu items.

10(19)

There is usually no need to do this, only do so if you know why you need to.

Click Install

11(19)
The program is installed AxCrypt will now be installed, and you will see the progress. The installation will typically take between 5 and 20 seconds.
Accept the Internet Connection If you elected to be notified of updates, AxCrypt will now connect with an Axantum server and send the information. Even if you elected to decline notifications, wed like to know a few basic facts about the installation and also just knowing that its being used is often the only reward we get, so please accept.

12(19)

No personal information is sent, the section on privacy policy on the AxCrypt web site, http://axcrypt.sourceforge.net details what is sent. The actual string sent is also shown in the dialog.

Click Yes or No.

13(19)
Installation is complete The installation is complete. Please read the next chapter on how to use AxCrypt.
Click Next 4. How to use AxCrypt can be used from the command line, from other programs and interactively as a part of Windows Explorer which is the usage this guide describes. Please see the product home page for details on other usage. Windows Explorer displays your desktop and is the part of Windows normally used to navigate among all your files and documents, where you double-click to open for example.

14(19)

Context menu In Windows Explorer you double-click to open a document, but you may also right-click to see a menu of choices appropriate for the particular document. This right-click menu is called the context menu. This is where youll find most of the functionality of AxCrypt.

15(19)

Encrypt To encrypt a file, right-click it and select Encrypt. Youll be asked to provide a pass phrase and optionally a key-file.

Using a key-file will ensure that the full strength of AxCrypt is applied, but is beyond the scope of this short guide. Enter a pass phrase, i.e. a sequence of secret strings. This is the secret that will protect your data from viewing by others and undetected tampering. Please note that encryption does not protect you from data loss. Regular backup copying is the only method that will do this. Enter your pass phrase a second time for verification. Its vital that you ensure that you actually type what you think you type, and that you remember this pass phrase. Click OK There are NO BACKDOORS into AxCrypt. If you forget your pass phrase your documents are likely to be irretrievably lost. Write it down, or print it, and keep it in a safe place.

16(19)

Open an encrypted document The encrypted document will have the.axx extension, and be shown with the AxCrypt icon. To conveniently decrypt the file, just double-click it to open it in its own application, and when done have it re-encrypted if modified. Decrypt an encrypted document To permanently decrypt a document, right-click it, select Decrypt and enter the pass phrase when prompted.
Click OK The file will be restored to its original name and contents. The pass phrase memory AxCrypt has the capability to remember any number of pass phrases for decryption, and a default pass phrase for new encryption. This memory is only as long as your logon session.
17(19) If you use the pass phrase memory, you should be using a password protected screen saver, and not leave your system unattended. To enable this feature, use the provided checkbox options on the pass phrase dialog. The dialogs above show these checkboxes at the bottom. All options in AxCrypt are sticky this means that the default is the same as your last choice. Shredding documents Did you know that documents that you delete can be very easily recovered by any number of third party tools commonly available on the Internet? One of them is even built into recent versions of Windows the recycling bin. With AxCrypt you can elect to delete files and documents in a more permanent way. Select the files you want to shred, and select the Shred option on the right-click menu. You will always be asked to confirm this, since this operation cannot be undone.
Click OK or Cancel as the case may be. If you clicked OK your data will now be overwritten with random data before being permanently deleted. Advanced use AxCrypt supports a number of a advanced uses which will only be mentioned briefly here:

18(19)

You can rename encrypted files to anonymous names the original names will still be restored on decryption. You can create self-decrypting files that you can ship to users who do not have AxCrypt installed. There is an install-free decrypt-only viewer, AxDecrypt, which you and others can use to decrypt without installing the full program. You can create and use key-files which are files with randomly generated strong keys ensuring that your information security is not subject to weaknesses in your chosen pass phrase. These may (and should) be stored on removable media such as USB-drives.

5. Information on security Encryption alone can never ensure security. It often is a vital tool, but as all tools must be used carefully. A single tool will seldom solve all security needs. This section tries to point out some additional aspects to consider when using any file encryption product such as AxCrypt for information security here taken to mean confidentiality and integrity. Security provided by AxCrypt The following is true of a file encrypted with AxCrypt: If you are using a key-file, your information is protected by the full 128-bit strength of AES currently considered unfeasible to break. If you are using a pass phrase only, AxCrypt will protect your information within the limits of that pass phrase. If its too short, security suffers. Anything shorter than 10 characters is short. Full 128-bit strength requires a meaningless sequence of at least 22 characters.
If you are interested in more information about the security of the encryption algorithm AES128 and AxCrypt, please read the white paper About AES available on the AxCrypt web http://www.axantum.com. Insecurity by other means AES-128, and thus presumably AxCrypt, is currently viewed as unfeasible to break, and youre using key-files. Are you secure? Not necessarily. As always, the most effective way past a barrier is around it. This applies to encryption as well. A brief list of some ways around AxCrypt follows:

19(19)

When youre editing and viewing documents on a computer, applications and the operating systems may leave full or partial copies of the document in temporary locations or the so-called paging file. This is true of Word and Excel for example. You computer may have a keystroke logger installed either physically or via software, thus revealing your pass phrase. You may be confronted with legal, economic or physical threats to reveal the pass phrase.
These are just some ways around AxCrypt; the remedies to these various situations vary according to the situation.

Version 0.3

Axantum Strong Software Licensing
Svante Seleborg Axantum Software AB

svante@axonadata.se

Abstract
This specifies the functionality and technical details of the Axantum Strong Software Licensing feature. The technical background and usage of respective programs are described. The licensing software is implemented in the AxCrypt file encryption software, available as an open source application as well as licensed by various OEM vendors. Although AxCrypt is free and will remain so, both itself and the software licensing part described here, is available under commercial terms from Axantum Software, and AxCrypt with this software licensing scheme is intended to also serve as a strong technology demonstration for interested OEM parties. Axantum Strong Software Licensing offers two relatively unusual features, still hard to find implemented in free or commercial software today, in 2004:
Self-signed code and configuration using strong elliptic curve cryptology conformant to international standards. Compact short signature technology using relatively strong elliptic curve cryptology enabling keyboard entry of a true digital signature. This is one of the first available implementations of shortened ECDSA signatures based on published research and built on top of international standards.
It allows the same binary compiled program executable files to be used both in a licensed and a non-licensed mode. As a benefit to the user, the scheme also provides strong digital signatures over essential program files, ensuring self-validation resulting in safe and uncontaminated execution. Non-validated, externally signed, XML is used for configuration. While circumvention can always be achieved by skilful patching of the executable, this will by definition also lead to loosing the program validation feature, thus a patch does not retain full program functionality. The license-to-use is a relatively strong digital signature typically over a user-identifying string issued such as an e-mail address, issued by the software manufacturer. Forging of program-code and configuration validation signatures is not computationally feasible. Forging of license-to-use signatures is computationally hard, though possibly feasible in the future as Moores law does its work. The license-to-use signature is short and compact enough so its reasonable to manually enter with the keyboard, although cut-and-paste is recommended.

1. Introduction

Software Licensing is a variation of Digital Rights Management, i.e. the art of retaining control of works distributed digitally the challenge being that faithful copies of digital works are trivially made and distributed. Retaining control over distributed works in the digital world is in this context equal to restricting the possibilities of unlimited copying, usage and distribution in one way or another. AxCrypt contains a software licensing and digital signature verification feature, which has the following design goals:
Copying as such is not restricted, i.e. the software is not tied to a single machine or media although that may be implemented as well within the scheme. The risk of widespread copying, distribution and the therefore unlicensed usage is reduced by requiring a digitally signed license-to-use, which positively identifies the licensee. Thus if copies are distributed, the source may be traced. The solution is cryptographically strong; it is not an obfuscating scheme.

Copyright Svante Seleborg, 2004, All rights reserved.

2. How does it work?

The software consists of a number of executable files, specified in the configuration XML-file, for AxCrypt, typically AxCrypt.exe, AxCrypt.dll, AxCryptM.dll and Notify.exe. The configuration XML-file, typically named Config.xml, contains all static program configuration information that is not stored in the registry. This includes signatures for the component programs, visible names etc. This is never modified after distribution, as it is digitally signed in an external file, the Signature XML. The Signature XML-file, typically named Sigs.xml contains signatures and other dynamic information. This file is not signed. AxCrypt is hard-coded to find the Signature XML in the same directory as the executable, and is typically named Sigs.xml. The name is hard-coded in the executable. If it does not find it, startup fails. Sigs.xml refers to the configuration XMLfile. If it is not found, startup fails. 2.1. Signature XML - Sigs.xml Sigs.xml typically contains: <Signatures> <Config> <Signature File="Config.xml" > HexString </Signature> </Config> <Licenses> <Signature Terms="Full" Licensee="User Name etc"> Base34String </Signature> </Licenses> </Signatures> Upon startup, AxCrypt attempts to locate the Signature XML file, by way of a hard-coded name like Sigs.xml, in the same directory holding the executable. The main purpose of Sigs.xml is to hold the signature of the Configuration XML. This makes for easy and unambiguous signing and verification. The Signature XML may also hold system-wide blanket license signatures issued with the distribution. User-entered, volatile licenses may be stored in any medium appropriate for the environment, typically the registry for Windows or if appropriate by modifying the Signature XML, this requires upgrade procedures to merge XML though. Startup proceeds by parsing the Signature XML, and locating the <Config> tag. It starts by checking the specified signature against the file found. If it does not match, start up fails. The public key is hard-coded inside the AxCrypt executable. The private key is the property of Axantum. As a consequence only Axantum Software can produce valid Configuration XML-files; vendors or other parties cannot unless a patch or a recompile inserts a different public key inside the executable.
Program upgrade is performed by replacing the appropriate executables, Signature XML and the Configuration XML If several license signatures are found, all are matched against each entry in the list of license types in the Configuration XML. 2.2. Configuration XML Config.xml
Config.xml does not change during the life of a version installation and typically contains:
<Configuration> <Self File="AxCrypt.exe" /> <Signature File="AxCrypt.exe"> HexString </Signature> <Signature File="AxCrypt.dll"> HexString </Signature> <Signature File="AxCryptM.dll"> HexString </Signature> <ShortName> AxCrypt </ShortName> <LongName> Axantum Encryption </LongName> <RegistryPath> Axantum Software\AxCrypt </RegistryPath> <Restrictions Days="20" Uses="25"> AxCrypt <Verifier> HexString </Verifier> <Terms Days="" /> <Terms Uses="" > Small </Terms> <Terms Days="" Uses="" > Full </Terms> </Restrictions> </Configuration>

As Config.xml is signed upon distribution it can never change, and must only contains things which are static from installation and onwards. If upgraded, it must be matched with a corresponding Signature XML thus as long as the embedded public key remains inviolate the configuration can not be modified for a given executable. This self-testing introduces an exceptional resiliency against manipulation and programming errors. If there is no <Restrictions> tag, no restrictions apply. The value of the <Restrictions> element identifies the restriction group. The internal working of license restrictions are in essence beyond the scope of this document, its up to the main program to enforce the restrictions until a
valid license-to-user is presented and entered into the Signature XML. The attributes of the <Restrictions> element list the default restrictions that are in place. The list of <Terms> is interpreted in order, as are the attributes. Each <Terms> element that does not have a valid license is ignored. If it has a valid license, its attributes are applied. Empty attributes remove the restriction. Only restrictions are listed never rights. The default is thus all rights, contrary and in reverse to many other rights systems. If a <Terms> element does not specify a given restriction attribute, that <Terms> element never has any effect on that restriction. It is up to the implementation to recognize and interpret various restriction attributes. Non-recognized restrictions are simply ignored. Typically for AxCrypt there will be support for a counter and possibly a day counter from installation after which further encryptions is not allowed, but apart from that the program continues to work. The free version, which of course should have no restrictions, is distributed with a license signature in the Signature XML granting full rights, and a <Restrictions> section in the Configuration XML. This is only useful for the free version, since the Configuration XML requires that the executable be named AxCrypt.exe, and that the registry settings are stored in the place for the free version. To enable independent developers to compile and run AxCrypt a Configuration XML / Signature XML pair is distributed which does not require any signed files at all. When using this Configuration, a warning dialog is shown which advises the developer to turn the whole signature feature off for independent development, since the signing tools are not distributed. This is also used for debugging purposes. Circumvention requires patching the program executable to either skip the tests for validity or insert a new public key and then sign everything with the corresponding private key.

2.3. What is required to break the system?
It is not computationally feasible to forge the configuration XML. The program has a hard-coded public key and it requires finding and validating the configuration XML before starting. It is at least computationally very hard to forge a license-to-use, probably it is also infeasible at the time of writing and for years to come. Obviously, if the same binary is used in different contexts the free version or varying vendors OEMversions, its possible to replace the configuration XML and signature XML with data obtained from the free version. But since the executable must also be renamed to the free version, the registry data moved etc what is thus achieved is an installation of the free version in an extremely round-about way. That is no problem, as its no secret there is a free version but that comes without any support, any distribution etc. For a fully commercial software, its no limitation at all since there will be no free signed configuration files available.
2.4. The licensing process as viewed by a user
A user purchases the program, and gets an installable on some media, including online download. Along with this, she receives a proof of purchase, or serial number, or any other token that may be presented at the vendors web site or via e-mail, phone, fax or phone or even in direct contact with the vendor. This mechanism is not part of the AxCrypt Software Licensing. The vendor, by any mechanism of her choice, then receives a string representing the user identity. Typically this will be the users e-mail, real name or similar. Validating this identity is not part of the licensing scheme. The user, in return, receives a communication in any form consisting of the identity string and a license. The identity string may look like this (only characters and letters are significant, and the case is not):
svante.seleborg@axondata.se SVANTESELEBORGAXONDATASE
Essentially patching the program is required to break the system from an executable point of view. Obviously, it is always possible to simply recompile the source since it is open for view and download, but the point is that it is not feasible to install a protected version and then patch it without loosing the self-validation feature. Possible, yes, but it requires a bit of work work that requires significantly more effort than simply downloading the free version.

Both above are identical. The purpose is to be flexible if the string is typed manually. The license takes the form of 36 significant characters, optionally grouped for easier legibility, and may look like this:
IE5EPX-5IEDU3-6XJWYB-AEB3E5-MZIC7A-N4FCC7
The possible characters include A-Z except O and 19, for a total of 34 different characters and the case is not significant. Note that letter O and digit zero are excluded to avoid confusion. The user, upon receiving these to strings, is prompted in the same communication to launch the license wizard, which is a simple program where the two strings are entered in two respective edit boxes, after which the user presses OK. If they are valid and correctly entered, the program now runs without any restrictions. If not, the user is prompted to try again.
2.5. What are the vendor tools?
technology OEMs one is generally enough. Thus the usage frequency alone makes the non-distribution of the tools reasonable. The tools are not documented or packaged in release quality either. They are for Axantum internal use only. The private key generator can generate two types of key-pairs:
The vendor receives one command line tool in a Windows and a FreeBSD/Linux version, along with a private key generated by Axantum Software. The private key generation program is not made available to external vendors, but private keys are generated upon request according to agreement (priv.key below, a small text-file of a few hundred bytes). The tool, AxSigLic (or axsiglic on FreeBSD/Linux) takes the following arguments:
axsiglic r priv.key [-t type] m userid-string
License-to-use key-pairs. The private key is used to sign user identifications to produce the short license-to-use signatures consisting of 36 characters as explained elsewhere. The public key will normally be distributed in signed XML to be used by applications to validate license-to-use signatures. Code validation key-pairs. The private key is used to sign code, configuration files and any other data where the signature is never typed by a human, but carried by higher bandwidth means such as files or the internet. The public key is typically either compiled statically into code, or placed in signed XML.

It is called on the command line as follows.
axkeygen [l | -s] [c|h]u "pub.ext [c| h]r "prv.ext"
The resulting license/signature in the above-mentioned 36-significant character format is produced on stdout, redirectable at will. The type/label is prepended to the licensee user-id-string and after canonicalization used as the message to sign. The canonicalization removes all non-alphanumeric characters and converts all to lowercase ASCII/Ansi 8-bit codes. The private key file is a raw hex encoding, as produced by AxKeyGen. The tool may be incorporated into scripts, web-pages, GUI-programs etc according to whatever the vendors need is.
2.6. What are the private tools?
-l long signature validation key-pairs. -s short signature license key-pairs. -c output is a C code fragment - h output is raw hex -u file name for the public key -r file name for the private key Default output is XML.
2.6.2. axsigxml Configuration signer
Using the private validation key, a XML file is parsed and the appropriate signatures for referenced files are generated etc. It takes as input an existing Configuration XML file, and produces as output a version with the appropriate signatures. Usage:
axsigxml [-r prv.xml] [-p searchpath] [-t tag:file]
To explain and document the full workings a description of the Axantum private tools follows. These are not distributed in either source or binary form to discourage generation of false private keys. Distribution and generation of false private keys is not a security issue as such, since it still requires recompilation for modification of the binaries to be of use.
2.6.1. axkeygen Key Pair Generator
-r private key to sign with. Made with axkeygen. -p folder to search for files in. May repeat. -t replace element with contents of file. It reads stdin, and produces to stdout. Elements named <Signature> with an attribute File are used to find files, generated signatures, and then output them as element data.
Private keys are generated very seldom; Axantum has one and will under normal circumstance never require another one. The same applies for vendors and
2.7. Technical details 2.7.1. Rights Manager
Uninstall removes all information, except the keycontainer it-self. This will let a subsequent reinstall continue from where it previous installation left off. To defeat, someone must write a program that enumerates the key containers and delete the one used here, whereupon the program of course reverts to new installation state at the next startup. If this becomes a problem, an arms race can be started where a key-pair is generated and stored there too, and used for various purposes to stop simple deletion from resetting the state.

2.7.2. Signature technology
Having established signed and secured configuration data and binary executable integrity, theres a need to actually manage the rights conferred by the license. Generally speaking its about limiting the functionality in run-time conditional on both static and dynamic checks. Static tests refer to simply limited license, for example simply restricting functionality. This is a limitation that is is statically tied to the license given a new, better, license needs to be issued for the functionality to be available. Dynamic tests refer typically to time or number of uses restricted functionality. I.e. after 30 days, limit the functionality or after 25 uses. These differ from the static kind in that they need to dynamically store and update data in a reasonably secure store that is at least not trivial to manipulate. For example, having a use counter in the registry falls to a trivial resetting attack. The challenge is that by definition nothing offline is truly secure, except, but one axiom in this whole context is that we regard the executable file as inviolatable as it is signed. If this is bypassed, there is nothing to stop simply modifying the executable to skip the limiting tests, or simulate a full valid license. The AxCrypt Rights Manager is a program API which takes as input an internal representation of an XML tree representing the Signature XML and one representing the Configuration XML. The license conditions are expressed as a number of restrictions that apply if the license is not valid. To store the state of use-counts etc, the following strategy is used. It is a low-bandwidth strategy, only a few bytes of information may be stored in this manner, but it should suffice. The main purpose is to ensure there are no pre-installed tools to easily delete the info. A key container is created with a pattern that is recognizeable, i.e. begins with AxCrypt for example. Directly following this, hexencoded, follows the usestate structure as defined by the implementation. When no matching key container is found, it is assumed that its a new install and default zero counters are created. The state is updated by creating a new key container and deleting the old.

(To be completed after implementation is complete) Elliptic curves over GF(p) are used. For the internal validation of the configuration file, one of the recommended 384-bit curves is used with a standard ECDSA signature algorithm. The signature over the user identication which produces the license-to-use, is done with one of the recommended 128-bit curves. The signature process is modified according to principles outlined in the references, by letting the parameter r in the signature be a truncated hash here set to 55 bits, making a total of 183 bits which is what fits into 36 base 34 positions. The choice of parameters here may change, and theres a perception that it is possible to add a work-factor increasing method to the hashing so as to increase the effective security offered by the admittedly short hash of 55 bits. Please note that in this application the birthday paradox weakness should not apply a brute force attempt to force a signature requires finding a message that hashes to the same hash as a given message, not just to find two which collide. A different possible tradeoff is to use a 112-bit curve with up to 71 bits of the hash. The current choice is made to protect the private key as well as possible. The weak hash should not affect the strength of the curve as such, only the ability to generate a single false signature. It is not entirely clear exactly what the complexity is to force this combination of parameters. Normally the scheme is regarded to give equivalent complexity as the regular scheme over the same curve with a hash of half the size of the curve, in this case 64 bits. 128-bit curves are also small, but currently beyond demonstrated abilities to force. In 2002 a 109-bit curve challenge was solved by utilizing a massive amount of computing power including 10,000 computers (mostly PCs) running 24 hours a day for 549 days.
2.8. Intellectual Property Rights
A reasonable amount of effort has been spent to determine if this implementation or its techniques are covered by any patents or other IPR. No such evidence
has been found. The techniques around Signcryption are probably protected, but that is not what this application is about. The reference is only used for the shortening of the ECDSA signature. All algorithmic code is from the Crypto++ library which is in the public domain, and no warnings about IPR are evident concerning this usage.

3. References

[1] Zheng, Y., ``Signcryption and Its Applications in Efficient Public Key Solutions'. [2] Zheng, Y., Digital Signcryption or How to Achieve Cost(Signature & Encryption) << Cost(Signature) + Cost (Encryption). [3] Zheng, Y., Imai, H., How to construct efficient signcryption schemes on elliptic curves, Information Processing Letters 68 (1998) 227-233. [4] Johnson, D., Menezes, A., Vanstone, S., The Elliptic Curve Digital Signature Algorithm (ECDSA), Certicom Research, Canada. [5] Menezes, A., Oorschot, P. van, Vanstone, S., Handbook of Applied Cryptography, CRC Press, 1996. [6] Dai, W., Crypto++ 5.2.1, http://www.eskimo.com/ ~weidai/cryptlib.html.