64 captures

08 Oct 2006 - 19 Dec 2024

Apr	JUL	Apr
	17
2011	2012	2014

success

fail

About this capture

COLLECTED BY

Organization: Internet Archive

The Internet Archive discovers and captures web pages through many different web crawls. At any given time several distinct crawls are running, some for months, and some every day or longer. View the web archive through the Wayback Machine.

Collection: Wikipedia Outlinks February 2012

Crawl of outlinks from wikipedia.org started February, 2012. These files are currently not publicly accessible.

TIMESTAMPS

The ECRYPT NoE plans to manage and co-ordinate a multi-year effort to identify new stream ciphers suitable for widespread adoption. To launch this initiative, algorithm designers are invited to submit new stream cipher proposals to the ECRYPT Stream Cipher project; more information and detailed submission requirements are provided below.

The ECRYPT NoE is not a standardisation body. Instead the ECRYPT NoE will centrally pool and manage information related to submitted stream cipher proposals. This resource will be available to developers, implementers, and researchers alike and consist of specifications, implementation information, and research results. Throughout the duration of the project, comments from industry and the results of work in the research community will be sought and compiled. At notable points during the process ECRYPT will prepare and publish updates on the progress of the submitted algorithms.

There will be two phases to the ECRYPT Stream Cipher project. The first phase will concentrate on accumulating information related to the submitted stream ciphers. At the end of the first phase, it is likely that a subset of the first phase ciphers will be advanced to the second phase. This will provide further focus to ongoing analysis within the cryptographic community. Since the goal of the project is to derive good stream ciphers, it is likely that potentially significant "tweaks" will be permitted in moving to the second phase.

ECRYPT is a Network of Excellence within the Information Societies Technology (IST) Programme of the European Commission.

1. PROFILE 1.
   
   • Stream ciphers for software applications with high throughput requirements.
2. PROFILE 2.
   
   • Stream ciphers for hardware applications with restricted resources such as limited storage, gate count, or power consumption.

Some have emphasized the importance of including an authentication method and so two further profiles are also proposed:

1. PROFILE 1A.
   
   • Stream ciphers satisfying PROFILE 1 with an associated authentication method.
2. PROFILE 2A.
   
   • Stream ciphers satisfying PROFILE 2 with an associated authentication method.

REMARK: Since the first publication of this call for primitives, a paper was published by Hong and Sarkar about time-memory-data tradeoffs on eprint. These issues are certainly an interesting topic of discussion for the upcoming ECRYPT workshops.

The ECRYPT NoE will not make any formal evaluation of the submissions. Rather the ECRYPT NoE will accumulate and package together results related to submissions. Thus, it is the input of the cryptographic community at large that will point to the most suitable stream cipher from the pool.

• Security is the most important criterion since it is essential to achieve confidence and build consensus.
• The performance of the primitive in the specified environment is important. For software, the range of environments may include 8-bit processors (as found in inexpensive smart cards), 32-bit processors (e.g., the Pentium family) to the modern 64-bit processors.  For hardware, both FPGAs and ASICs may be considered.
• We anticipate that different ciphers will perform best against different profiles; however, within any one profile, some flexibility of implementation is likely to be important, so that the range of environments in which it can be used is not unnecessarily restricted.
• Market requirements are related to the need for a primitive, its usability, and the possibility for world-wide use.

Security Criteria

• Any key-recovery attack (including time-memory-data tradeoff attacks) should be at least as difficult as exhaustive search.
• Also, distinguishing attacks are likely to be of interest to the cryptographic community. However the relative importance of high complexity distinguishing attacks may become an issue for wider discussion.
• Clarity of design is likely to be an important consideration. 

Implementation Criteria

• Software and hardware efficiency will be compared with similar submissions and existing primitives.
• Execution code and memory sizes will be assessed according to their relevance in different contexts. 
• Submitted primitives will be assessed against claimed performance, though it is clearly preferable for primitives to offer wide flexibility of use.

Licensing Requirements

• The submitter should state the position concerning intellectual property.  This statement should be updated when necessary.

Provisional Timetable

2004	November	Call for Cryptographic Primitives
2005	April 29	Submission deadline
2005	May 26-27	Stream cipher workshop
2006	February	End of first phase.
2006	July	Beginning of second phase.
2007	September	End of second phase.
2008	January	Final report of ECRYPT Stream Cipher project

For the ECRYPT NoE a stream cipher takes as input

• A message stream (M),
• A key (K),
• An initial value (IV),
• Optionally for PROFILES that provide authentication, some associated data (AD).

For the ECRYPT NoE a stream cipher gives as output

• A ciphertext stream (C),
• For PROFILES providing authentication, an authentication tag (AU),
• Optionally for PROFILES that provide authentication, authenticated but unencrypted associated data (AU-AD).

For stream ciphers without an authentication mechanism, the required parameter values are given below.

1. PROFILE 1.
   
   • A key length of 128 bits must be accommodated.
   • An IV length of at least one of 64 or 128 bits must be accommodated.  
2. PROFILE 2.
   
   • A key length of 80 bits must be accommodated.
   • An IV length of at least one of 32 or 64 bits must be accommodated.  

For stream ciphers with an authentication mechanism, the required parameter values are given below.

1. PROFILE 1A.
   
   • A key length of 128 bits must be accommodated.
   • An IV length of at least one of 64 or 128 bits must be accommodated.  
   • An authentication tag length of at least one of 32, 64, 96, or 128 bits must be accommodated.  
2. PROFILE 2A.
   
   • A key length of 80 bits must be accommodated.
   • An IV length of at least one of 32 or 64 bits must be accommodated.  
   • An authentication tag length of at least one of 32 or 64 bits must be accommodated.  

The following additional information might be useful.

• A stream cipher can be either synchronous or self-synchronising.
• While some IV sizes are specified as must-satisfy values, the ability to handle smaller IV spaces without hindering performance would be welcome.
• For any PROFILE it is likely that the stream cipher must be demonstrably superior to the AES in at least one significant aspect. Here we assume that the AES is used in some appropriate mode (e.g. counter mode).
• Time-memory trade-offs mean that the size of the stream cipher state should be appropriate for the claimed security level. For instance, the state size should be at least twice the key size.
• While attacks such as related-key attacks might not be directly addressed, they would be of considerable relevance to the ongoing assessment of the cipher.
• Issues such as side-channel analysis and secure implementation are likely to be a relevant consideration.
• In addition to theoretic estimations of the security of a cipher, full cost estimates of attacks might also be considered.

A. Cover sheet with the following information:

1. Name of submitted algorithm
2. Type of submitted algorithm, proposed security level, and proposed environment.
3. Principal submitter's name, telephone, fax, organization, postal address, e-mail address
4. Name(s) of auxiliary submitter(s)
5. Name of algorithm inventor(s)/developer(s)
6. Name of owner, if any, of the algorithm (normally expected to be the same as the submitter)
7. Signature of submitter
8. (optional) Backup point of contact (telephone, fax, postal address, e-mail)

B. Primitive specification and supporting documentation

1. A complete and unambiguous description of the primitive in the most suitable forms, such as a mathematical description, a textual description with diagrams, or pseudo-code.  The specification of a primitive using code is not permitted.  Input and output should be in the form of binary strings.  For asymmetric algorithms, a method for key generation and parameter selection needs to be specified.
2. A statement that there are no hidden weaknesses inserted by the designers.
3. A statement of the claimed security properties and expected security level, together with an analysis of the primitive with respect to standard cryptanalytic attacks.  Weak keys should also be considered.
4. A statement giving the strengths and advantages of the primitive.
5. A design rationale explaining design choices.
6. A statement of the estimated computational efficiency in software.  Estimates are required for different sub-operations like key setup, primitive setup, and encryption/decryption (as far as applicable).  The efficiency should be estimated both in cycles per byte and cycles per block, indicating the processor type and memory. If performance varies with the size of the inputs, then values for some typical sizes should be provided.  Optionally the designers may provide estimates for performance in hardware (area, speed, gate count, a description in VHDL).
7. A description of the basic techniques for implementers to avoid implementation weaknesses.

C. Implementations and test values

1. A reference implementation in portable C. The ECRYPT NoE specifies the following API.
2. A sufficient number of test vectors.
3. Optionally, an optimized implementation for some architectures, a JAVA implementation, an assembly language implementation.

D. Intellectual property statement

1. A statement that gives the position concerning intellectual property position and the royalty policy for the primitive.
2. This statement should include an undertaking to update the ECRYPT Stream Cipher project when necessary.

Requirements:

1. Items A, B, and D shall be supplied in paper form and in electronic form (Adobe PDF or PostScript).
2. Item C shall be supplied in electronic form only.
3. Item A, B, C and D shall be clearly labelled and supplied on one CD.  The CD shall contain an ASCII file labeled "README", that lists all files included on the CD and provides a brief description of the content of each file.
4. All submissions must be in English.
5. Designers cannot ask for their design to remain secret, as ECRYPT intends public evaluation of the designs.
6. Submissions should be sent to the following address:
   Prof. Bart Preneel
   ECRYPT NoE Project Coordinator
   K.U. Leuven
   Kasteelpark Arenberg 10
   B-3001 Leuven-Heverlee
   BELGIUM
7. Submissions should arrive on or before 29th April 2005. An acknowledgment of receipt will be sent by email and also regular mail if requested.