MD2, MD4, MD5, MD2_Init, MD2_Update, MD2_Final, MD4_Init, MD4_Update,
MD4_Final, MD5_Init, MD5_Update, MD5_Final – MD2, MD4, and MD5 hash
unsigned char *MD2(const unsigned char *d, unsigned long n,
unsigned char *md);
void MD2_Init(MD2_CTX *c);
void MD2_Update(MD2_CTX *c, const unsigned char *data,
unsigned long len);
void MD2_Final(unsigned char *md, MD2_CTX *c);
unsigned char *MD4(const unsigned char *d, unsigned long n,
unsigned char *md);
void MD4_Init(MD4_CTX *c);
void MD4_Update(MD4_CTX *c, const void *data,
unsigned long len);
void MD4_Final(unsigned char *md, MD4_CTX *c);
unsigned char *MD5(const unsigned char *d, unsigned long n,
unsigned char *md);
void MD5_Init(MD5_CTX *c);
void MD5_Update(MD5_CTX *c, const void *data,
unsigned long len);
void MD5_Final(unsigned char *md, MD5_CTX *c);
MD2, MD4, and MD5 are cryptographic hash functions with a 128 bit out-
MD2(), MD4(), and MD5() compute the MD2, MD4, and MD5 message digest of
the n bytes at d and place it in md (which must have space for
MD2_DIGEST_LENGTH == MD4_DIGEST_LENGTH == MD5_DIGEST_LENGTH == 16 bytes
of output). If md is NULL, the digest is placed in a static array.
The following functions may be used if the message is not completely
stored in memory:
MD2_Init() initializes a MD2_CTX structure.
MD2_Update() can be called repeatedly with chunks of the message to be
hashed (len bytes at data).
MD2_Final() places the message digest in md, which must have space for
MD2_DIGEST_LENGTH == 16 bytes of output, and erases the MD2_CTX.
MD4_Init(), MD4_Update(), MD4_Final(), MD5_Init(), MD5_Update(), and
MD5_Final() are analogous using an MD4_CTX and MD5_CTX structure.
Applications should use the higher level functions EVP_DigestInit(3)
etc. instead of calling the hash functions directly.
MD2, MD4, and MD5 are recommended only for compatibility with existing
applications. In new applications, SHA-1 or RIPEMD-160 should be pre-
MD2(), MD4(), and MD5() return pointers to the hash value.
MD2_Init(), MD2_Update(), MD2_Final(), MD4_Init(), MD4_Update(),
MD4_Final(), MD5_Init(), MD5_Update(), and MD5_Final() do not return
RFC 1319, RFC 1320, RFC 1321
Wassenaar Arrangement / COCOM
1. Export/ import controls
COCOM (Coordinating Committee for Multilateral Export Controls) was an international organization for the mutual control of the export of strategic products and technical data from country members to proscribed destinations. It maintained, among others, the International Industrial List and the International Munitions List. In 1991, COCOM decided to allow export of mass-market cryptographic software (including public domain software). Most member countries of COCOM followed its regulations, but the United States maintained separate regulations.
Its 17 members were Australia, Belgium, Canada, Denmark, France, Germany, Greece, Italy, Japan, Luxemburg, The Netherlands, Norway, Portugal, Spain, Turkey, United Kingdom, and the United States. Cooperating members included Austria, Finland, Hungary, Ireland, New Zealand, Poland, Singapore, Slovakia, South Korea, Sweden, Switzerland, and Taiwan.
The main goal of the COCOM regulations was to prevent cryptography from being exported to „dangerous“ countries – usually, the countries thought to maintain friendly ties with terrorist organizations, such as Libya, Iraq, Iran, and North Korea. Exporting to other countries is usually allowed, although states often require a license to be granted.
COCOM was dissolved in March 1994. Pending the signing of a new treaty, most members of COCOM agreed in principle to maintain the status quo, and cryptography remained on export control lists.
The Wassenaar Arrangement controls the export of weapons and of dual-use goods, that is, goods that can be used both for a military and for a civil purpose; cryptography is such a dual-use good.
In 1995, 28 countries decided to establish a follow-up to COCOM, the Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies. The negotiations on the Arrangement were finished in July 1996, and the agreement was signed by 31 countries (Argentina, Australia, Austria, Belgium, Canada, the Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, the Netherlands, New Zealand, Norway, Poland, Portugal, the Republic of Korea, Romania, the Russian Federation, the Slovak Republic, Spain, Sweden, Switzerland, Turkey, the United Kingdom and the United States). Later, Bulgaria and Ukraine also became a participating state to the Arrangement.
The initial provisions were largely the same as old COCOM regulations. The General Software Note (applicable until the December 1998 revision) excepted mass-market and public-domain crypto software from the controls. Australia, France, New Zealand, Russia, and the US deviated from the GSN and controlled the export of mass-market and public-domain crypto software. Export via the Internet did not seem to be covered by the regulations.
There is a personal-use exemption, allowing export of products „accompanying their user for the user’s personal use“ (e.g., on a laptop).
In September 1998, Wassenaar negotiations in Vienna did not lead to changes in the crypto controls, although it was apparently considered to restrict the GSN (see an article in German) and possibly also to ease controls for key-recovery crypto. (Compare an article in Swedish of March 1998.)
The Wassenaar Arrangement was revised in December 1998. Negotiations were held on 2 and 3 December 1998 in Vienna, which resulted in restrictions on the General Software Note and in some relexations:
free for export are: all symmetric crypto products of up to 56 bits, all asymmetric crypto products of up to 512 bits, and all subgroup-based crypto products (including elliptic curve) of up to 112 bits;
mass-market symmetric crypto software and hardware of up to 64 bits are free for export (the 64-bit limit was deleted on 1 December 2000, see below);
the export of products that use encryption to protect intellectual property (such as DVDs) is relaxed;
export of all other crypto still requires a license.
There was no change in the provisions on public-domain crypto, so that all public-domain crypto software is still free for export. Nothing was said about electronic exports (e.g., via the Internet), which consequently remain unclear.
In its meeting of 30 November-1 December 2000, the Wassenaar states lifted the 64-bit limit for export controls on mass-market crypto software and hardware (in the Cryptography Note, clause d. (the 64-bit limit) was deleted in its reference to category 5A2, as well as the related Validity Note, see the summary). The public statement of the meeting mentioned that „Participating States recognised that it is important to continue deepening Wassenaar Arrangement understanding of how and how much to control“ intangible transfers.
The Wassenaar provisions are not directly applicable: each member state has to implement them in national legislation for them to have effect. (In the entries below, I have included mention of the pre-December 1998 regulations, which will stay into effect until the government enacts new legislation to implement the Wassenaar changes.)
See the Wassenaar List (crypto is in category 5 part 2). See further the Wassenaar Arrangement page (includes contact information for various national export control authorities), a Wassenaar FAQ (by US BIS), Greg Broiles‘ page on the Wassenaar Arrangement, which includes links to John Young’s pages on the Wassenaar Arrangement and comments on the December 1998 changes, and the GILC Wassenaar page. See also Chapter 3 of Simo-Pekka Parviainen’s thesis on Cryptographic Software Export Controls in the EU. Cf. an April 1996 article on the Wassenaar Arrangement.
OECD (Organisation for Economic Co-operation and Development)
The OECD released its Recommendation of the Council concerning Guidelines for Cryptography Policy on 27 March 1997. The guidelines are non-binding recommendations to Member governments, meaning that they will not be part of international law. The Guidelines provide principles which states should take into account and balance in developing a national crypto policy.
The principles are:
1) Trust in cryptographic methods
2) Choice of cryptographic methods
3) Market driven development of cryptographic methods
4) Standards for cryptographic methods
5) Protection of privacy and personal data
6) Lawful access
8) International co-operation
The principles should be seen as „interdependent and should be implemented as a whole so as to balance the various interests at stake. No principle should be implemented in isolation from the rest.“
Some have welcomed the OECD principles as a victory for privacy over US-pushed key recovery, while others object to certain points as being too inflexible or too vague. Although the guidelines do not endorse key recovery, they do not prohibit it either. In fact, the guidelines are vague enough to allow a broad range of interpretation, and states will be able to choose a privacy-oriented or a law-enforcement-driven policy line as they see fit. While the guidelines recommend states to cooperate to coordinate their crypto policies, one may be skeptical about the chances of governments coming to an agreement; after all, within the OECD, states have not been able to agree, and they have left the task of finding a balance between, roughly speaking, information security/ privacy and law-enforcement/ national security to individual states.
The process of discussing and drafting policy guidelines started with an Ad-hoc Meeting of Experts on Cryptography Policy on 18-19 December 1995, organized by the OECD Committee for Information, Computer and Communications Policy (ICCP). They proposed to make a study upon current Member Countries encryption policies, market for encryption, key escrow encryption, and to develop a cryptography policy guideline based on the following principles, among others: provides security with confidence, voluntary use, international perspective, recognise national responsibilities, legally effective. The Group of Experts on Security, Privacy and Intellectual Property Protection in the Global Information Infrastructure held subsequent meetings on 7-8 February 1996 in Canberra, on 8 May 1996 in Washington, DC, on 26-28 June in Paris, and on 26-27 September 1996, again in Paris. At the June 1996 meeting, according to one report, no agreement was established; the OECD was said to be split into two parties, one with countries favouring mandatory key escrow (notably the US, UK, and France), and one with countries opposing this approach (mainly Japan and the Scandinavian countries). See a 1 October 1996 press release.
One can compare the final version to an earlier draft of the Guidelines that was discussed at the December 1996 meeting (with rather optimistic personal comments by Robin Whittle). (Text between [square brackets] remained to be decided upon.) In January 1997, the OECD Group of Experts on Security. Privacy, and Intellectual Property Protection in the GII concluded the guidelines. The Guidelines were finally turned into a Council of the OECD resolution in March 1997.
Identify a scam
How do I identify a scam message ?
The first 3 necessity for a person is food, shelter and clothing. But now internet is the 4th important necessity in people’s life. The usage of internet is widely used for seeking numbers to all kind of information. But the biggest disadvantage is that you might get caught by scam mails. The scam mailsare sent by the scam companies which are listed on the internet. Try avoiding this website which can be harmful for your computers. To avoid this kind of scam messages download a fee version of anti-scam software from the internet. These stop the scam mail to enter your inbox.
The scam companies can send you a message which has an interesting subject like how to avoid cancer? Or let say about earning money in 15 days. The most usual scams found are the Nigerian. These letters contains generally of transferring money. For example a person claimed to be a widower and asked to transfer money to your bank account. It is better if you don’t give them any personal information. You will never know when you will be bankrupt. These types of letters are otherwise known as 419 scams. How will you find out if the person is a scammer or not? Here are some points which will help you in identifying the scammer.
– Scammer never uses his original name or any other personal identification.
– They always write in capital letter and write to you in formal method like referring you with Mr. or miss in each letter.
– There are always a friendless words like my dear or greeting to you in the letter.
– The body of the letter is mostly filled with financial term like lottery, funds etc.
– You can identify the scammer from their e-mail address.
– They register the e-mail address in a formal name for example firstname.lastname@example.org. This shows that they are fake address.
Some of the popular messages are listed below :
Gain lot of money by working from your place. There is no such company who allows you to work from your place. Another type of message is you have won a price from so and so company which you have never heard of. It is highly dangerous if you give your account data to a stranger. Never trust an unknown person who might offer you a job with higher salary. There are many companies who literally steal the money from you via internet. It is safer if you don’t open an unknown scam messages. There is a possibility of hacking your computer through these scam messages. So to stay on a safer side you can download free trial or buy the original anti-scam software which can block all the scam messages.
whois – Internet domain name and network number directory service
whois [-adgprR] [-h host] name …
Whois looks up records in the databases maintained by several Network In-
formation Centers (NICs).
The options are as follows:
-a Use the American Registry for Internet Numbers (ARIN) database.
It contains network numbers used in those parts of the world cov-
ered neither by APNIC nor by RIPE.
-d Use the US Department of Defense database. It contains points of
contact for subdomains of .MIL.
-g Use the US non-military federal government database, which con-
tains points of contact for subdomains of .GOV.
Use the specified host instead of the default NIC (whois.inter-
nic.net). Either a host name or an IP address may be specified.
-p Use the Asia/Pacific Network Information Center (APNIC) database.
It contains network numbers used in East Asia, Australia, New
Zealand, and the Pacific islands.
-r Use the R’eseaux IP Europ’eens (RIPE) database. It contains net-
work numbers and domain contact information for Europe.
-R Use the Russia Network Information Center (RIPN) database. It
contains network numbers and domain contact information for sub-
domains of .RU.
The operands specified to whois are concatenated together (separated by
white-space) and presented to the whois server.
The default action, unless directed otherwise with a special name, is to
do a very broad search, looking for matches to name in all types of
records and most fields (name, nicknames, hostname, net address, etc.) in
the database. For more information as to what name operands have special
meaning, and how to guide the search, use the special name „help“.
Ken Harrenstien, and Vic White, NICNAME/WHOIS, 1 March 1982, RFC 812.
The whois command appeared in 4.3BSD.
xinetd – the extended Internet services daemon
xinetd performs the same function as inetd: it starts programs that
provide Internet services. Instead of having such servers started at
system initialization time, and be dormant until a connection request
arrives, xinetd is the only daemon process started and it listens on
all service ports for the services listed in its configuration file.
When a request comes in, xinetd starts the appropriate server. Because
of the way it operates, xinetd (as well as inetd) is also referred to
as a super-server.
The services listed in xinetd’s configuration file can be separated
into two groups. Services in the first group are called multi-threaded
and they require the forking of a new server process for each new con-
nection request. The new server then handles that connection. For
such services, xinetd keeps listening for new requests so that it can
spawn new servers. On the other hand, the second group includes ser-
vices for which the service daemon is responsible for handling all new
connection requests. Such services are called single-threaded and
xinetd will stop handling new requests for them until the server dies.
Services in this group are usually datagram-based.
So far, the only reason for the existence of a super-server was to con-
serve system resources by avoiding to fork a lot of processes which
might be dormant for most of their lifetime. While fulfilling this
function, xinetd takes advantage of the idea of a super-server to pro-
vide features such as access control and logging. Furthermore, xinetd
is not limited to services listed in /etc/services. Therefore, anybody
can use xinetd to start special-purpose servers.
-d Enables debug mode. This produces a lot of debugging output, and
it makes it possible to use a debugger on xinetd.
This option enables syslog logging of xinetd-produced messages
using the specified syslog facility. The following facility
names are supported: daemon, auth, user, local[0-7] (check sys-
log.conf(5) for their meanings). This option is ineffective in
debug mode since all relevant messages are sent to the terminal.
xinetd-produced messages will be placed in the specified file.
Messages are always appended to the file. If the file does not
exist, it will be created. This option is ineffective in debug
mode since all relevant messages are sent to the terminal.
Determines the file that xinetd uses for configuration. The
default is /etc/xinetd.conf.
The process ID is written to the file. This option is ineffec-
tive in debug mode.
Tells xinetd to stay in the foreground rather than detaching
itself, to support being run from init or daemontools. This
option automatically sets -stayalive (see below).
Tells xinetd to stay running even if no services are specified.
This option places a limit on the number of concurrently running
processes that can be started by xinetd. Its purpose is to pre-
vent process table overflows.
This option places a limit on the number of concurrently running
servers for remote userid acquisition.
This option causes xinetd to print out its version information.
This option causes xinetd to read /etc/inetd.conf in addition to
the standard xinetd config files. /etc/inetd.conf is read after
the standard xinetd config files.
This option instructs xinetd to perform periodic consistency
checks on its internal state every interval seconds.
The syslog and filelog options are mutually exclusive. If none is
specified, the default is syslog using the daemon facility. You should
not confuse xinetd messages with messages related to service logging.
The latter are logged only if this is specified via the configuration
xinetd performs certain actions when it receives certain signals. The
actions associated with the specific signals can be redefined by edit-
ing config.h and recompiling.
SIGHUP causes a hard reconfiguration, which means that xinetd
re-reads the configuration file and terminates the
servers for services that are no longer available.
Access control is performed again on running servers by
checking the remote location, access times and server
instances. If the number of server instances is lowered,
some arbitrarily picked servers will be killed to sat-
isfy the limit; this will happen after any servers are
terminated because of failing the remote location or
access time checks. Also, if the INTERCEPT flag was
clear and is set, any running servers for that service
will be terminated; the purpose of this is to ensure
that after a hard reconfiguration there will be no run-
ning servers that can accept packets from addresses that
do not meet the access control criteria.
SIGQUIT causes program termination.
SIGTERM terminates all running servers before terminating
SIGUSR1 causes an internal state dump (the default dump file is
/var/run/xinetd.dump; to change the filename, edit con-
fig.h and recompile).
SIGIOT causes an internal consistency check to verify that the
data structures used by the program have not been cor-
rupted. When the check is completed xinetd will gener-
ate a message that says if the check was successful or
On reconfiguration the log files are closed and reopened. This allows
removal of old log files.
/etc/xinetd.conf default configuration file
/var/run/xinetd.dump default dump file
Panos Tsirigotis, CS Dept, University of Colorado, Boulder Rob Braun
zlib – compression/decompression library
[see zlib.h for full description]
The zlib library is a general purpose data compression
library. The code is thread safe. It provides in-memory
compression and decompression functions, including
integrity checks of the uncompressed data. This version
of the library supports only one compression method
(deflation) but other algorithms will be added later and
will have the same stream interface.
Compression can be done in a single step if the buffers
are large enough (for example if an input file is
mmap’ed), or can be done by repeated calls of the compres-
sion function. In the latter case, the application must
provide more input and/or consume the output (providing
more output space) before each call.
The library also supports reading and writing files in
gzip (.gz) format with an interface similar to that of
The library does not install any signal handler. The
decoder checks the consistency of the compressed data, so
the library should never crash even in case of corrupted
All functions of the compression library are documented in
the file zlib.h. The distribution source includes exam-
ples of use of the library the files example.c and
A Java implementation of zlib is available in the Java
Development Kit 1.1
A Perl interface to zlib, written by Paul Marquess (pmar-
email@example.com) is available at CPAN (Comprehensive
Perl Archive Network) sites, such as:
A Python interface to zlib written by A.M. Kuchling
is available from the Python Software
Association sites, such as:
Questions about zlib should be sent to:
firstname.lastname@example.org or, if this fails, to the
author addresses given below. The zlib home page
The data format used by the zlib library is described by
RFC (Request for Comments) 1950 to 1952 in the files:
ftp://ds.internic.net/rfc/rfc1950.txt (zlib format)
rfc1951.txt (deflate format)
rfc1952.txt (gzip format)
These documents are also available in other formats from:
Version 1.1.3 Copyright (C) 1995-1998 Jean-loup Gailly
(email@example.com) and Mark Adler (firstname.lastname@example.org-
This software is provided „as-is,“ without any express or
implied warranty. In no event will the authors be held
liable for any damages arising from the use of this soft-
ware. See the distribution directory with respect to
requirements governing redistribution. The deflate format
used by zlib was defined by Phil Katz. The deflate and
zlib specifications were written by L. Peter Deutsch.
Thanks to all the people who reported problems and sug-
gested various improvements in zlib; who are too numerous
to cite here.
UNIX manual page by R. P. C. Rodgers, U.S. National
Library of Medicine (email@example.com).
HMAC, HMAC_Init, HMAC_Update, HMAC_Final, HMAC_cleanup – HMAC message
unsigned char *HMAC(const EVP_MD *evp_md, const void *key,
int key_len, const unsigned char *d, int n,
unsigned char *md, unsigned int *md_len);
void HMAC_CTX_init(HMAC_CTX *ctx);
void HMAC_Init(HMAC_CTX *ctx, const void *key, int key_len,
const EVP_MD *md);
void HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int key_len,
const EVP_MD *md);
void HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, int len);
void HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len);
void HMAC_CTX_cleanup(HMAC_CTX *ctx);
void HMAC_cleanup(HMAC_CTX *ctx);
HMAC is a MAC (message authentication code), i.e. a keyed hash function
used for message authentication, which is based on a hash function.
HMAC() computes the message authentication code of the n bytes at d
using the hash function evp_md and the key key which is key_len bytes
It places the result in md (which must have space for the output of the
hash function, which is no more than EVP_MAX_MD_SIZE bytes). If md is
NULL, the digest is placed in a static array. The size of the output
is placed in md_len, unless it is NULL.
evp_md can be EVP_sha1(), EVP_ripemd160() etc. key and evp_md may be
NULL if a key and hash function have been set in a previous call to
HMAC_Init() for that HMAC_CTX.
HMAC_CTX_init() initialises a HMAC_CTX before first use. It must be
HMAC_CTX_cleanup() erases the key and other data from the HMAC_CTX and
releases any associated resources. It must be called when an HMAC_CTX
is no longer required.
HMAC_cleanup() is an alias for HMAC_CTX_cleanup() included for back
compatibility with 0.9.6b, it is deprecated.
The following functions may be used if the message is not completely
stored in memory:
HMAC_Init() initializes a HMAC_CTX structure to use the hash function
evp_md and the key key which is key_len bytes long. It is deprecated
and only included for backward compatibility with OpenSSL 0.9.6b.
HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the
function evp_md and key key. Either can be NULL, in which case the
existing one will be reused. HMAC_CTX_init() must have been called
before the first use of an HMAC_CTX in this function. N.B. HHMMAACC_IInniitt(())
had this undocumented behaviour in previous versions of OpenSSL – fail-
ure to switch to HHMMAACC_IInniitt_eexx(()) in programs that expect it will cause
them to stop working.
HMAC_Update() can be called repeatedly with chunks of the message to be
authenticated (len bytes at data).
HMAC_Final() places the message authentication code in md, which must
have space for the hash function output.
HMAC() returns a pointer to the message authentication code.
HMAC_CTX_init(), HMAC_Init_ex(), HMAC_Update(), HMAC_Final() and
HMAC_CTX_cleanup() do not return values.
EVP_MD_CTX_init, EVP_MD_CTX_create, EVP_DigestInit_ex, EVP_DigestUp-
date, EVP_DigestFinal_ex, EVP_MD_CTX_cleanup, EVP_MD_CTX_destroy,
EVP_MAX_MD_SIZE, EVP_MD_CTX_copy_ex EVP_MD_CTX_copy, EVP_MD_type,
EVP_MD_pkey_type, EVP_MD_size, EVP_MD_block_size, EVP_MD_CTX_md,
EVP_MD_CTX_size, EVP_MD_CTX_block_size, EVP_MD_CTX_type, EVP_md_null,
EVP_md2, EVP_md5, EVP_sha, EVP_sha1, EVP_dss, EVP_dss1, EVP_mdc2,
EVP_ripemd160, EVP_get_digestbyname, EVP_get_digestbynid,
EVP_get_digestbyobj – EVP digest routines
void EVP_MD_CTX_init(EVP_MD_CTX *ctx);
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl);
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
int EVP_DigestFinal_ex(EVP_MD_CTX *ctx, unsigned char *md,
unsigned int *s);
int EVP_MD_CTX_cleanup(EVP_MD_CTX *ctx);
void EVP_MD_CTX_destroy(EVP_MD_CTX *ctx);
int EVP_MD_CTX_copy_ex(EVP_MD_CTX *out,const EVP_MD_CTX *in);
int EVP_DigestInit(EVP_MD_CTX *ctx, const EVP_MD *type);
int EVP_DigestFinal(EVP_MD_CTX *ctx, unsigned char *md,
unsigned int *s);
int EVP_MD_CTX_copy(EVP_MD_CTX *out,EVP_MD_CTX *in);
#define EVP_MAX_MD_SIZE (16+20) /* The SSLv3 md5+sha1 type */
#define EVP_MD_type(e) ((e)->type)
#define EVP_MD_pkey_type(e) ((e)->pkey_type)
#define EVP_MD_size(e) ((e)->md_size)
#define EVP_MD_block_size(e) ((e)->block_size)
#define EVP_MD_CTX_md(e) (e)->digest)
#define EVP_MD_CTX_size(e) EVP_MD_size((e)->digest)
#define EVP_MD_CTX_block_size(e) EVP_MD_block_size((e)->digest)
#define EVP_MD_CTX_type(e) EVP_MD_type((e)->digest)
const EVP_MD *EVP_md_null(void);
const EVP_MD *EVP_md2(void);
const EVP_MD *EVP_md5(void);
const EVP_MD *EVP_sha(void);
const EVP_MD *EVP_sha1(void);
const EVP_MD *EVP_dss(void);
const EVP_MD *EVP_dss1(void);
const EVP_MD *EVP_mdc2(void);
const EVP_MD *EVP_ripemd160(void);
const EVP_MD *EVP_get_digestbyname(const char *name);
#define EVP_get_digestbynid(a) EVP_get_digestbyname(OBJ_nid2sn(a))
#define EVP_get_digestbyobj(a) EVP_get_digestbynid(OBJ_obj2nid(a))
The EVP digest routines are a high level interface to message digests.
EVP_MD_CTX_init() initializes digest contet ctx.
EVP_MD_CTX_create() allocates, initializes and returns a digest contet.
EVP_DigestInit_ex() sets up digest context ctx to use a digest type
from ENGINE impl. ctx must be initialized before calling this function.
type will typically be supplied by a functionsuch as EVP_sha1(). If
impl is NULL then the default implementation of digest type is used.
EVP_DigestUpdate() hashes cnt bytes of data at d into the digest con-
text ctx. This function can be called several times on the same ctx to
hash additional data.
EVP_DigestFinal_ex() retrieves the digest value from ctx and places it
in md. If the s parameter is not NULL then the number of bytes of data
written (i.e. the length of the digest) will be written to the integer
at s, at most EVP_MAX_MD_SIZE bytes will be written. After calling
EVP_DigestFinal_ex() no additional calls to EVP_DigestUpdate() can be
made, but EVP_DigestInit_ex() can be called to initialize a new digest
EVP_MD_CTX_cleanup() cleans up digest context ctx, it should be called
after a digest context is no longer needed.
EVP_MD_CTX_destroy() cleans up digest context ctx and frees up the
space allocated to it, it should be called only on a context created
EVP_MD_CTX_copy_ex() can be used to copy the message digest state from
in to out. This is useful if large amounts of data are to be hashed
which only differ in the last few bytes. out must be initialized before
calling this function.
EVP_DigestInit() behaves in the same way as EVP_DigestInit_ex() except
the passed context ctx does not have to be initialized, and it always
uses the default digest implementation.
EVP_DigestFinal() is similar to EVP_DigestFinal_ex() except the digest
contet ctx is automatically cleaned up.
EVP_MD_CTX_copy() is similar to EVP_MD_CTX_copy_ex() except the desti-
nation out does not have to be initialized.
EVP_MD_size() and EVP_MD_CTX_size() return the size of the message
digest when passed an EVP_MD or an EVP_MD_CTX structure, i.e. the size
of the hash.
EVP_MD_block_size() and EVP_MD_CTX_block_size() return the block size
of the message digest when passed an EVP_MD or an EVP_MD_CTX structure.
EVP_MD_type() and EVP_MD_CTX_type() return the NID of the OBJECT IDEN-
TIFIER representing the given message digest when passed an EVP_MD
structure. For example EVP_MD_type(EVP_sha1()) returns NID_sha1. This
function is normally used when setting ASN1 OIDs.
EVP_MD_CTX_md() returns the EVP_MD structure corresponding to the
EVP_MD_pkey_type() returns the NID of the public key signing algorithm
associated with this digest. For example EVP_sha1() is associated with
RSA so this will return NID_sha1WithRSAEncryption. This „link“ between
digests and signature algorithms may not be retained in future versions
EVP_md2(), EVP_md5(), EVP_sha(), EVP_sha1(), EVP_mdc2() and
EVP_ripemd160() return EVP_MD structures for the MD2, MD5, SHA, SHA1,
MDC2 and RIPEMD160 digest algorithms respectively. The associated sig-
nature algorithm is RSA in each case.
EVP_dss() and EVP_dss1() return EVP_MD structures for SHA and SHA1
digest algorithms but using DSS (DSA) for the signature algorithm.
EVP_md_null() is a „null“ message digest that does nothing: i.e. the
hash it returns is of zero length.
EVP_get_digestbyname(), EVP_get_digestbynid() and EVP_get_digestbyobj()
return an EVP_MD structure when passed a digest name, a digest NID or
an ASN1_OBJECT structure respectively. The digest table must be ini-
tialized using, for example, OpenSSL_add_all_digests() for these func-
tions to work.
EVP_DigestInit_ex(), EVP_DigestUpdate() and EVP_DigestFinal_ex() return
1 for success and 0 for failure.
EVP_MD_CTX_copy_ex() returns 1 if successful or 0 for failure.
EVP_MD_type(), EVP_MD_pkey_type() and EVP_MD_type() return the NID of
the corresponding OBJECT IDENTIFIER or NID_undef if none exists.
EVP_MD_size(), EVP_MD_block_size(), EVP_MD_CTX_size(e), EVP_MD_size(),
EVP_MD_CTX_block_size() and EVP_MD_block_size() return the digest or
block size in bytes.
EVP_md_null(), EVP_md2(), EVP_md5(), EVP_sha(), EVP_sha1(), EVP_dss(),
EVP_dss1(), EVP_mdc2() and EVP_ripemd160() return pointers to the cor-
responding EVP_MD structures.
EVP_get_digestbyname(), EVP_get_digestbynid() and EVP_get_digestbyobj()
return either an EVP_MD structure or NULL if an error occurs.
The EVP interface to message digests should almost always be used in
preference to the low level interfaces. This is because the code then
becomes transparent to the digest used and much more flexible.
SHA1 is the digest of choice for new applications. The other digest
algorithms are still in common use.
For most applications the impl parameter to EVP_DigestInit_ex() will be
set to NULL to use the default digest implementation.
The functions EVP_DigestInit(), EVP_DigestFinal() and EVP_MD_CTX_copy()
are obsolete but are retained to maintain compatibility with existing
code. New applications should use EVP_DigestInit_ex(), EVP_DigestFi-
nal_ex() and EVP_MD_CTX_copy_ex() because they can efficiently reuse a
digest context instead of initializing and cleaning it up on each call
and allow non default implementations of digests to be specified.
In OpenSSL 0.9.7 and later if digest contexts are not cleaned up after
use memory leaks will occur.
This example digests the data „Test Message\n“ and „Hello World\n“,
using the digest name passed on the command line.
#include (stdio .h)
main(int argc, char *argv)
const EVP_MD *md;
char mess1 = „Test Message\n“;
char mess2 = „Hello World\n“;
unsigned char md_value[EVP_MAX_MD_SIZE];
int md_len, i;
printf(„Usage: mdtest digestname\n“);
md = EVP_get_digestbyname(argv);
printf(„Unknown message digest %s\n“, argv);
EVP_DigestInit_ex(&mdctx, md, NULL);
EVP_DigestUpdate(&mdctx, mess1, strlen(mess1));
EVP_DigestUpdate(&mdctx, mess2, strlen(mess2));
EVP_DigestFinal_ex(&mdctx, md_value, &md_len);
printf(„Digest is: „);
for(i = 0; i < md_len; i++) printf("%02x", md_value[i]); printf("\n"); } BUGS The link between digests and signing algorithms results in a situation where EVP_sha1() must be used with RSA and EVP_dss1() must be used with DSS even though they are identical digests. EOF