Technologie

MD5

MD5

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
functions

SYNOPSIS

#include (openssl/md2.h)

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);

#include (openssl/md4.h)

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);

#include (openssl/md5.h)

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);

DESCRIPTION

MD2, MD4, and MD5 are cryptographic hash functions with a 128 bit out-
put.

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.

NOTE

MD2, MD4, and MD5 are recommended only for compatibility with existing
applications. In new applications, SHA-1 or RIPEMD-160 should be pre-
ferred.

RETURN VALUES

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
values.

CONFORMING TO

RFC 1319, RFC 1320, RFC 1321

EOF

Share this post from Rbcafe :
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on LinkedInEmail this to someoneShare on RedditBuffer this page

Wassenaar

Wassenaar Arrangement / COCOM

1. Export/ import controls

COCOM

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.
Wassenaar Arrangement

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.

EOF

Share this post from Rbcafe :
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on LinkedInEmail this to someoneShare on RedditBuffer this page

OECD

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
7) Liability
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.

EOF

Share this post from Rbcafe :
Share on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on LinkedInEmail this to someoneShare on RedditBuffer this page
Seite 4 von 6123456
Rbcafe © 2004- | Rb Cafe 1.3 | Kontakt Rbcafe | Rbcafe auf Twitter | Rbcafe auf Facebook | Datenschutz