DOCSLIB.ORG

Security Policy: HID Global Cryptographic Module

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Security Policy: HID Global Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy: HID Global Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy HID Global Cryptographic Module Software Version 1.0 Document Version 1.3 September 21, 2018 Prepared For: Prepared By: HID Global Corporation SafeLogic Inc. 611 Center Ridge Drive 530 Lytton Ave, Suite 200 Austin, TX 78753 Palo Alto, CA 94301 www.hidglobal.com www.safelogic.com Document Version 1.3 © HID Global Page 1 of 33 FIPS 140-2 Non-Proprietary Security Policy: HID Global Cryptographic Module Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for the HID Global Cryptographic Module. Document Version 1.3 © HID Global Page 2 of 33 FIPS 140-2 Non-Proprietary Security Policy: HID Global Cryptographic Module Table of Contents 1 Introduction .............................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document .................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .......................................................................................................................................................... 5 2 HID Global Cryptographic Module .............................................................................................................. 6 2.1 Cryptographic Module Specification ............................................................................................................ 6 2.1.1 Validation Level Detail ............................................................................................................................. 6 2.1.2 Modes of Operation ................................................................................................................................. 6 2.1.3 Module Configuration .............................................................................................................................. 7 2.1.4 Approved Cryptographic Algorithms ....................................................................................................... 9 2.1.5 Non-Approved Cryptographic Algorithms ............................................................................................. 14 2.1.6 Non-Approved Mode of Operation ....................................................................................................... 14 2.2 Critical Security Parameters and Public Keys ............................................................................................. 16 2.2.1 Critical Security Parameters ................................................................................................................... 16 2.2.2 Public Keys ............................................................................................................................................. 18 2.3 Module Interfaces ...................................................................................................................................... 19 2.4 Roles, Services, and Authentication ........................................................................................................... 20 2.4.1 Assumption of Roles .............................................................................................................................. 20 2.4.2 Services .................................................................................................................................................. 20 2.5 Physical Security ......................................................................................................................................... 25 2.6 Operational Environment ........................................................................................................................... 25 2.6.1 Use of External RNG ............................................................................................................................... 25 2.7 Self-Tests .................................................................................................................................................... 26 2.7.1 Power-Up Self-Tests ............................................................................................................................... 26 2.7.2 Conditional Self-Tests ............................................................................................................................ 27 2.8 Mitigation of Other Attacks ....................................................................................................................... 28 3 Security Rules and Guidance ..................................................................................................................... 29 3.1 Basic Enforcement ...................................................................................................................................... 29 3.1.1 Additional Enforcement with a Java SecurityManager .......................................................................... 29 3.1.2 Basic Guidance ....................................................................................................................................... 29 3.1.3 Enforcement and Guidance for GCM IVs ............................................................................................... 30 3.1.4 Enforcement and Guidance for use of the Approved PBKDF ................................................................ 30 3.1.5 Software Installation .............................................................................................................................. 30 4 References and Acronyms ......................................................................................................................... 31 4.1 References .................................................................................................................................................. 31 4.2 Acronyms .................................................................................................................................................... 32 Document Version 1.3 © HID Global Page 3 of 33 FIPS 140-2 Non-Proprietary Security Policy: HID Global Cryptographic Module List of Tables Table 1 – Validation Level by FIPS 140-2 Section ........................................................................................................... 6 Table 2 – Available Java Permissions ............................................................................................................................. 8 Table 3 – FIPS-Approved Algorithm Certificates .......................................................................................................... 12 Table 4 – Approved Cryptographic Functions Tested with Vendor Affirmation .......................................................... 13 Table 5 – Non-Approved but Allowed Cryptographic Algorithms ............................................................................... 14 Table 6 – Non-Approved Cryptographic Functions for use in non-FIPS mode only..................................................... 15 Table 7 – Critical Security Parameters ......................................................................................................................... 17 Table 8 – Public Keys ................................................................................................................................................... 18 Table 9 – Logical Interface / Physical Interface Mapping ............................................................................................ 20 Table 10 – Description of Roles ................................................................................................................................... 20 Table 11 – Module Services, Roles, and Descriptions.................................................................................................. 22 Table 12 – CSP Access Rights within Services .............................................................................................................. 24 Table 13 – Power-Up Self-Tests ................................................................................................................................... 27 Table 14 – Conditional Self-Tests ................................................................................................................................. 27 Table 15 – References ................................................................................................................................................. 32 Table 16 – Acronyms and Terms.................................................................................................................................. 33 List of Figures Figure 1 – Module Boundary and Interfaces Diagram ................................................................................................. 19 Document Version 1.3 © HID Global Page 4 of 33 FIPS 140-2 Non-Proprietary Security Policy: HID Global Cryptographic Module 1 Introduction 1.1 About FIPS 140 Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic
Load more

Recommended publications
  • Nshield CONNECT Hsms
    Product Sheet /EN nSHIELD CONNECT nSHIELD CONNECT HSMs Certified appliances that deliver cryptographic key services across networks nShield Connect HSMs are FIPS-certified nSHIELD CONNECT appliances that deliver cryptographic services to applications across the network. • Maximizes performance and availability with high cryptographic transaction These tamper-resistant platforms perform rates and flexible scaling such functions as encryption, digital signing and key generation and protection • Supports a wide variety of applications over an extensive range of applications, including certificate authorities, code including certificate authorities, code signing and more signing, custom software and more. The nShield Connect series includes • nShield CodeSafe protects your nShield Connect+ and the new, high- applications within nShield’s secure performance nShield Connect XC. execution environment HIGHLY FLEXIBLE ARCHITECTURE • nShield Remote Administration helps nCipher unique Security World architecture you cut costs and reduce travel lets you combine nShield HSM models to build a mixed estate that delivers flexible scalability and seamless failover and load balancing. nSHIELD CONNECT PROCESS MORE DATA FASTER – now also available from Nexus! nShield Connect HSMs support high transaction rates, making them ideal for enterprise, retail, IoT and other environments where throughput is critical. Available Models and Performance nShield Connect Models 500+ XC Base 1500+ 6000+ XC Mid XC High PROTECT YOUR PROPRIETARY RSA Signing Performance (tps) for NIST Recommended Key Lengths APPLICATIONS 2048 bit 150 430 450 3,000 3,500 8,600 4096 bit 80 100 190 500 850 2,025 The CodeSafe option provides a secure ECC Prime Curve Signing Performance (tps) for NIST Recommended Key Lengths environment for running sensitive 256 bit 540 680 1,260 2,400 5,500 14,400 Client Licenses applications within nShield boundaries.
    [Show full text]
  • Report on the AES Candidates
    Rep ort on the AES Candidates 1 2 1 3 Olivier Baudron , Henri Gilb ert , Louis Granb oulan , Helena Handschuh , 4 1 5 1 Antoine Joux , Phong Nguyen ,Fabrice Noilhan ,David Pointcheval , 1 1 1 1 Thomas Pornin , Guillaume Poupard , Jacques Stern , and Serge Vaudenay 1 Ecole Normale Sup erieure { CNRS 2 France Telecom 3 Gemplus { ENST 4 SCSSI 5 Universit e d'Orsay { LRI Contact e-mail: [email protected] Abstract This do cument rep orts the activities of the AES working group organized at the Ecole Normale Sup erieure. Several candidates are evaluated. In particular we outline some weaknesses in the designs of some candidates. We mainly discuss selection criteria b etween the can- didates, and make case-by-case comments. We nally recommend the selection of Mars, RC6, Serp ent, ... and DFC. As the rep ort is b eing nalized, we also added some new preliminary cryptanalysis on RC6 and Crypton in the App endix which are not considered in the main b o dy of the rep ort. Designing the encryption standard of the rst twentyyears of the twenty rst century is a challenging task: we need to predict p ossible future technologies, and wehavetotake unknown future attacks in account. Following the AES pro cess initiated by NIST, we organized an op en working group at the Ecole Normale Sup erieure. This group met two hours a week to review the AES candidates. The present do cument rep orts its results. Another task of this group was to up date the DFC candidate submitted by CNRS [16, 17] and to answer questions which had b een omitted in previous 1 rep orts on DFC.
    [Show full text]
  • Security Policy: Informacast Java Crypto Library
    FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library FIPS 140-2 Non-Proprietary Security Policy InformaCast Java Crypto Library Software Version 3.0 Document Version 1.2 June 26, 2017 Prepared For: Prepared By: Singlewire Software SafeLogic Inc. 1002 Deming Way 530 Lytton Ave, Suite 200 Madison, WI 53717 Palo Alto, CA 94301 www.singlewire.com www.safelogic.com Document Version 1.2 © Singlewire Software Page 1 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for InformaCast Java Crypto Library. Document Version 1.2 © Singlewire Software Page 2 of 35 FIPS 140-2 Non-Proprietary Security Policy: InformaCast Java Crypto Library Table of Contents 1 Introduction .................................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document.................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .........................................................................................................................................................
    [Show full text]
  • Bicliques for Preimages: Attacks on Skein-512 and the SHA-2 Family
    Bicliques for Preimages: Attacks on Skein-512 and the SHA-2 family Dmitry Khovratovich1 and Christian Rechberger2 and Alexandra Savelieva3 1Microsoft Research Redmond, USA 2DTU MAT, Denmark 3National Research University Higher School of Economics, Russia Abstract. We present the new concept of biclique as a tool for preimage attacks, which employs many powerful techniques from differential cryptanalysis of block ciphers and hash functions. The new tool has proved to be widely applicable by inspiring many authors to publish new re- sults of the full versions of AES, KASUMI, IDEA, and Square. In this paper, we demonstrate how our concept results in the first cryptanalysis of the Skein hash function, and describe an attack on the SHA-2 hash function with more rounds than before. Keywords: SHA-2, SHA-256, SHA-512, Skein, SHA-3, hash function, meet-in-the-middle attack, splice-and-cut, preimage attack, initial structure, biclique. 1 Introduction The last years saw an exciting progress in preimage attacks on hash functions. In contrast to collision search [29, 26], where differential cryptanalysis has been in use since 90s, there had been no similarly powerful tool for preimages. The situation changed dramatically in 2008, when the so-called splice-and-cut framework has been applied to MD4 and MD5 [2, 24], and later to SHA-0/1/2 [1, 3], Tiger [10], and other primitives. Despite amazing results on MD5, the applications to SHA-x primitives seemed to be limited by the internal properties of the message schedule procedures. The only promising element, the so-called initial structure tool, remained very informal and complicated.
    [Show full text]
  • Advanced Meet-In-The-Middle Preimage Attacks: First Results on Full Tiger, and Improved Results on MD4 and SHA-2
    Advanced Meet-in-the-Middle Preimage Attacks: First Results on Full Tiger, and Improved Results on MD4 and SHA-2 Jian Guo1, San Ling1, Christian Rechberger2, and Huaxiong Wang1 1 Division of Mathematical Sciences, School of Physical and Mathematical Sciences, Nanyang Technological University, Singapore 2 Dept. of Electrical Engineering ESAT/COSIC, K.U.Leuven, and Interdisciplinary Institute for BroadBand Technology (IBBT), Kasteelpark Arenberg 10, B–3001 Heverlee, Belgium. [email protected] Abstract. We revisit narrow-pipe designs that are in practical use, and their security against preimage attacks. Our results are the best known preimage attacks on Tiger, MD4, and reduced SHA-2, with the result on Tiger being the first cryptanalytic shortcut attack on the full hash function. Our attacks runs in time 2188.8 for finding preimages, and 2188.2 for second-preimages. Both have memory requirement of order 28, which is much less than in any other recent preimage attacks on reduced Tiger. Using pre-computation techniques, the time complexity for finding a new preimage or second-preimage for MD4 can now be as low as 278.4 and 269.4 MD4 computations, respectively. The second-preimage attack works for all messages longer than 2 blocks. To obtain these results, we extend the meet-in-the-middle framework recently developed by Aoki and Sasaki in a series of papers. In addition to various algorithm-specific techniques, we use a number of conceptually new ideas that are applicable to a larger class of constructions. Among them are (1) incorporating multi-target scenarios into the MITM framework, leading to faster preimages from pseudo-preimages, (2) a simple precomputation technique that allows for finding new preimages at the cost of a single pseudo-preimage, and (3) probabilistic initial structures, to reduce the attack time complexity.
    [Show full text]
  • Miss in the Middle Attacks on IDEA and Khufu
    Miss in the Middle Attacks on IDEA and Khufu Eli Biham? Alex Biryukov?? Adi Shamir??? Abstract. In a recent paper we developed a new cryptanalytic techni- que based on impossible differentials, and used it to attack the Skipjack encryption algorithm reduced from 32 to 31 rounds. In this paper we describe the application of this technique to the block ciphers IDEA and Khufu. In both cases the new attacks cover more rounds than the best currently known attacks. This demonstrates the power of the new cryptanalytic technique, shows that it is applicable to a larger class of cryptosystems, and develops new technical tools for applying it in new situations. 1 Introduction In [5,17] a new cryptanalytic technique based on impossible differentials was proposed, and its application to Skipjack [28] and DEAL [17] was described. In this paper we apply this technique to the IDEA and Khufu cryptosystems. Our new attacks are much more efficient and cover more rounds than the best previously known attacks on these ciphers. The main idea behind these new attacks is a bit counter-intuitive. Unlike tra- ditional differential and linear cryptanalysis which predict and detect statistical events of highest possible probability, our new approach is to search for events that never happen. Such impossible events are then used to distinguish the ci- pher from a random permutation, or to perform key elimination (a candidate key is obviously wrong if it leads to an impossible event). The fact that impossible events can be useful in cryptanalysis is an old idea (for example, some of the attacks on Enigma were based on the observation that letters can not be encrypted to themselves).
    [Show full text]
  • Cryptographic Hash Workshop (2005)
    SHA-160: A Truncation Mode for SHA256 (and most other hashes) John Kelsey, NIST Halloween Hash Bash 2005 1 What’s a Truncation Mode? • Rule for chopping bits off a hash output • We have a big hash fn we trust, Like SHA256 • We need a smaller hash output Like 160 bits • We need to specify how this is done – Interoperability and security reasons 2 Why Do We Need One? • Need drop in replacement for SHA1 (MD5?) • Have unBroken hashes of wrong size – ECDSA/DSA key sizes – File and protocol formats • OBvious approach: Truncate SHA256/SHA512 • This has Been done Before: Snefru, Tiger, SHA384, SHA224 3 Our Proposal in a Nutshell H(X,M) = hash M from initial value X • Start with different IV for each truncation length n: n has fixed-length representation T IV n = H(IV xor 0xccc…c,n) • Run bigger hash normally T T H n(m) = truncate(H(IV n, m),n) • Generic: Any n, many big hashes – (Rivest comment to SHA224) 4 Intuition: Why should this be okay? • If hash “good”, seems like truncation should be good, too. – Fits our intuition about hash functions – Easy proof in Random Oracle Model – Prior art suggests other people agree • So, is intuition correct here? 5 Security Considerations • Issue #1: Related hash outputs T – H n(X) ! H(X’) • Issue #2: Can we safely truncate? – No reduction proof – “Near collisions” 6 Issue #1: Related Outputs T Why we need IV n!IV T What if IV n =IV? Then we get collision before truncation: T H 160(M) = ABCDE T H 192(M) = ABCDEF 7 Does This Matter? A Common KDF • KDF(S,P,n): – T = “” – for j = 1 to n: T = T || hash(S||P||j) • Two people use different truncations: – Result: Two closely related keys “AAAABBBBCCCCDDDD” “AAABBBCCCDDD” • Very unintuitive property! – Related key attack? Protocol problem? 8 Broader Issue: Related Outputs T T H n(m) = truncate(H(IV n, m),n) T • What if H n(m) ! H(m’)? – Broader property: can’t prove it won’t happen – Narrow property: collision before truncation 9 Does Our Scheme Prevent This? We prevent collision before truncation: T • Can’t choose M’ -> IV n (preimage) • Can’t cause intermediate collision (DM constr.
    [Show full text]
  • Comparative Analysis of Advanced Encryption Standard, Blowfish and Rivest Cipher 4 Algorithms
    www.ijird.com November, 2014 Vol 3 Issue 11 ISSN 2278 – 0211 (Online) Comparative Analysis of Advanced Encryption Standard, Blowfish and Rivest Cipher 4 Algorithms Adolf Fenyi Researcher, Kwame Nkrumah University of Science and Technology, Knust, Ghana Joseph G. Davis Lecturer, Kwame Nkrumah University of Science and Technology, Knust, Ghana Dr. Kwabena Riverson Head of Programme CSIR Institute of Industrial Research Accra, Ghana Abstract: Cryptography is one of the main categories of computer security that converts information from its normal form into an unreadable form. The two main characteristics that identify and differentiate one encryption algorithm from another are its ability to secure the protected data against attacks and its speed and efficiency in doing so.Cryptography is required to transmit confidential information over the network. It is also demanding in wide range of applications which includes mobile and networking applications. Cryptographic algorithms play a vital role in providing the data security against malicious attacks. But on the other hand, they consume significant amount of computing resources like CPU time, memory, encryption time etc. Normally, symmetric key algorithms are preferred over asymmetric key algorithms as they are very fast in nature. Symmetric algorithms are classified as block cipher and stream ciphers algorithms. In this research project, I comparedthe AES and Blowfish algorithms with different modes of operation (ECB, CBC, and CFB) and RC4 algorithm (stream cipher) in terms encryption time, decryption time, memory utilization and throughput at different settings likevariable key size and variable data packet size.A stimulation program is developed using PHP and JavaScript scripting languages. The program encrypts and decrypts different file sizes ranging from 1MB to 50MB.
    [Show full text]
  • Tiger Hash Attribute Encryption for Secured Cloud Service Provisioning
    Middle-East Journal of Scientific Research 25 (1): 181-191, 2017 ISSN 1990-9233 © IDOSI Publications, 2017 DOI: 10.5829/idosi.mejsr.2017.181.191 Tiger Hash Attribute Encryption for Secured Cloud Service Provisioning 12P. Muthusamy and V. Murali Bhaskaran 1Department of Computer Science & Engg, Anna University, Chennai - 600 025, Tamil Nadu, India 2Principal, Dhirajlal Gandhi College of Technology, Salem - 636 309, Tamil Nadu, India Abstract: Cloud Computing facilitates organization to share various operation services in a high secure manner. In cloud based communication, the confidentiality of the systemis the major concern. Hence, the secured message communication is to prevent unauthorized access of confidential information. Several encryption approacheshave been developed for cloud service provisioning. But, cloud users still have major security and confidentiality about their outsourced data due to unauthorized access within the service providers. In order to improve the confidentiality in cloud service provisioning, Tiger Cryptographic Hash Function based Attribute Encryption and Decryption (TCHF-AED) technique is introduced. Tiger is a cryptographic hash function for achieving higher confidentiality rate in cloud service provisioning. Initially, the attribute cloud request is sent from the users to cloud server. Next, Tiger Cryptographic Hash Function is used to achieve cloud data confidentiality based on output of hash value.TheAttribute Encryption is performed for converting actual message into cipher textand the hash value of each encrypted message is calculated. The encrypted message with hash value is stored in cloud server. Whenever the cloud user accesses the data from cloud server, the hash value is recomputed to achieve the correctness of the message. If the correctness is achieved the decryption is performed to attain the confidentiality.
    [Show full text]
  • AES, Blowfish and Twofish for Security of Wireless Networks
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 07 Issue: 06 | June 2020 www.irjet.net p-ISSN: 2395-0072 Comparison of Encryption Algorithms: AES, Blowfish and Twofish for Security of Wireless Networks Archisman Ghosh Department of Computer Science & Engineering, National Institute of Technology, Durgapur, West Bengal, India --------------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - Encryption is the process of encoding data to A secure WiFi system uses algorithms such as DES, RSA, prevent unauthorized access. Cyber security is the need of AES, Blowfish and Twofish to secure the communication the hour which ensures transfer of data across the internet over seemingly unsecured Internet channels. In addition, with confidentiality and integrity, and provides protection the existing cryptographic algorithm is based on an against malicious attacks. In this research paper, encryption model designed by Horst Feistel of IBM [4]. comparison between the encryption algorithms, viz. AES (Advanced Encryption Standard), Blowfish, and Twofish is In this paper, a comparative study of the cryptographic done in terms of time of encryption and decryption, and algorithms: AES, Blowfish and Twofish has been done and their throughput, and the results are analysed indicating the the results have been analysed in order to find the superiority of Twofish over AES and Blowfish as a viable algorithm most suitable for encrypting data in wireless algorithm for data encryption in wireless networks. networks. Keywords: Cryptography, Network security, AES, 2. Overview of the algorithms Blowfish, Twofish, Secure communication. 2.1 AES 1. Introduction The Advanced Encryption Standard (AES) is a Owing to the advancement in internet accessibility and cryptographic algorithm for encryption of electronic data networking, most of the security sensitive stuff like established by the U.S.
    [Show full text]
  • Performance Analysis of Cryptographic Hash Functions Suitable for Use in Blockchain
    I. J. Computer Network and Information Security, 2021, 2, 1-15 Published Online April 2021 in MECS (http://www.mecs-press.org/) DOI: 10.5815/ijcnis.2021.02.01 Performance Analysis of Cryptographic Hash Functions Suitable for Use in Blockchain Alexandr Kuznetsov1 , Inna Oleshko2, Vladyslav Tymchenko3, Konstantin Lisitsky4, Mariia Rodinko5 and Andrii Kolhatin6 1,3,4,5,6 V. N. Karazin Kharkiv National University, Svobody sq., 4, Kharkiv, 61022, Ukraine E-mail: [email protected], [email protected], [email protected], [email protected], [email protected] 2 Kharkiv National University of Radio Electronics, Nauky Ave. 14, Kharkiv, 61166, Ukraine E-mail: [email protected] Received: 30 June 2020; Accepted: 21 October 2020; Published: 08 April 2021 Abstract: A blockchain, or in other words a chain of transaction blocks, is a distributed database that maintains an ordered chain of blocks that reliably connect the information contained in them. Copies of chain blocks are usually stored on multiple computers and synchronized in accordance with the rules of building a chain of blocks, which provides secure and change-resistant storage of information. To build linked lists of blocks hashing is used. Hashing is a special cryptographic primitive that provides one-way, resistance to collisions and search for prototypes computation of hash value (hash or message digest). In this paper a comparative analysis of the performance of hashing algorithms that can be used in modern decentralized blockchain networks are conducted. Specifically, the hash performance on different desktop systems, the number of cycles per byte (Cycles/byte), the amount of hashed message per second (MB/s) and the hash rate (KHash/s) are investigated.
    [Show full text]
  • A New Stream Cipher HC-256
    A New Stream Cipher HC-256 Hongjun Wu Institute for Infocomm Research 21 Heng Mui Keng Terrace, Singapore 119613 [email protected] Abstract. Stream cipher HC-256 is proposed in this paper. It generates keystream from a 256-bit secret key and a 256-bit initialization vector. HC-256 consists of two secret tables, each one with 1024 32-bit elements. The two tables are used as S-Box alternatively. At each step one element of a table is updated and one 32-bit output is generated. The encryption speed of the C implementation of HC-256 is about 1.9 bit per clock cycle (4.2 clock cycle per byte) on the Intel Pentium 4 processor. 1 Introduction Stream ciphers are used for shared-key encryption. The modern software efficient stream ciphers can run 4-to-5 times faster than block ciphers. However, very few efficient and secure stream ciphers have been published. Even the most widely used stream cipher RC4 [25] has several weaknesses [14, 16, 22, 9, 10, 17, 21]. In the recent NESSIE project all the six stream cipher submissions cannot meet the stringent security requirements [23]. In this paper we aim to design a very simple, secure, software-efficient and freely-available stream cipher. HC-256 is the stream cipher we proposed in this paper. It consists of two secret tables, each one with 1024 32-bit elements. At each step we update one element of a table with non-linear feedback function. Every 2048 steps all the elements of the two tables are updated.
    [Show full text]