Re: RNG using AES CTR as encryption algorithm
On Tue, Sep 1, 2009 at 11:28 PM, priya yelgar wrote: I have implemented RNG using AES algorithm in CTR mode. To test my implementation I needed some test vectors. How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. Please can any one tell me where to look for the test vectors to test RNG using AES CTR. The first thing that jumps out at me is that you're looking for a nebulous Randon Number Generator based on AES CTR mode (defined by SP 800-38A), and this is cast in the context of NIST's CSRC website (http://csrc.nist.gov/). Referencing NIST implies that you're looking for some kind Algorithm Certificate or FIPS 140-2 certification for a cryptographic module. If this is true, then you cannot just use 'AES CTR' to generate FIPS-approved random numbers. Instead, you need to use one of the approved RNG methods listed in FIPS 140-2 Annex C Approved Random Number Generators. This includes several RNGs, including AES and 3DES variants based on ANSI X9.31, and SP 800-90. The closest thing to AES CTR is the CTR_DRBG defined in SP 800-90, which uses AES CTR for the random number generation, but also handles important things like distilling the initial entropy pool and periodic re-keying. Even if you're not intending to get FIPS 140-2 certification, I still highly recommend finding a good standard describing a 'recipe' for generating pseudo-random numbers, and follow the requirements for that. 'RNG using AES in CTR mode' is much different than 'Encryption using AES in CTR mode', and needs to be carefully handled accordingly. It's really easy to get things wrong outside of the AES CTR portion of the problem. You need to worry about justifying a particular entropy content of your true random source, which is then distilled down to create your key and nonce for the AES CTR portion of the RNG. This is not a task that is taken lightly. My personal recommendation is to go with the CTR_DRBG as defined in SP 800-90. You can easily find open source implementations of this algorithm, so I'm not even sure if you need to spend time implementing it. To test it, I recommend going through the process of getting an algorithm certificate from NIST. Cheers! Matt Ball, Chair, IEEE P1619 Security in Storage Working Group Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021 Work: 303-272-7580, Cell: 303-717-2717 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: AES-GMAC as a hash
On Thu, Aug 27, 2009 at 8:45 AM, Darren J Moffat wrote: Ignoring performance for now what is the consensus on the suitabilty of using AES-GMAC not as MAC but as a hash ? Would it be safe ? The key input to AES-GMAC would be something well known to the data and/or software. The only reason I'm asking is assuming it can be made to perform on some classes of machine better than or close to SHA256 if it would be worth considering as an available alternate now until SHA-3 is choosen. In the 2005 Security in Storage Workshop (see http://ieeeia.org/sisw/2005/), David McGrew proposed using GMAC to protect large dynamic data sets, such a random access memory (RAM) (see http://ieeeia.org/sisw/2005/PreProceedings/10.pdf). The general idea is to use the linear characteristics of GMAC to dynamically update the MAC when updating a memory address. If your use-case is similar to this approach, then it would be possible to securely use GMAC. However, there are many caveats when using GMAC, so it's vitally important to understand all the constraints. Cheers, Matt Ball, Chair, IEEE P1619 Security in Storage Working Group Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021 Work: 303-272-7580, Cell: 303-717-2717 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Warning! New cryptographic modes!
On Mon, May 11, 2009 at 2:54 PM, Jerry Leichter leich...@lrw.com wrote: On May 11, 2009, at 2:16 PM, Roland Dowdeswell wrote: On 1241996128 seconds since the Beginning of the UNIX epoch Jerry Leichter wrote: I'm not convinced that a stream cipher is appropriate here because if you change the data then you'll reveal the plaintext. Well, XOR of old a new plaintext. But point taken. Sounds like this might actually be an argument for a stream cipher with a more sophisticated combiner than XOR. (Every time I've suggested that, the response has been That doesn't actually add any strength, so why bother- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Parallel Skein Hash Construction based on the Subset Sum Problem?
On Wed, Oct 29, 2008 at 9:23 AM, Stephan Somogyi wrote: The Skein team has announced its submission to the NIST hash competition: http://www.schneier.com/skein.html Now that we've all had a chance to read the Skein algorithm, I've got a question for the list: Would it be possible to construct an efficient parallel version of Skein with output size N by creating intermediate results of size 2N, adding them as integers, and then hashing this sum of intermediate results as the final result? (That is, would such a construction be faster than the Skein tree hashing?) I suspect that this construction would be secure according to the computational difficulty of solving the Subset Sum problem (known to be NP-complete), but haven't rigorously confirmed this. Skein is able to efficiently create larger outputs, so such a construction like this would be easier with Skein than with, say SHA-512. For example, with Skein-256, you could hash each 256-bit (or larger, depending on leaf size choice) message chunk into a 512-bit, or 768-bit intermediate value. This value would then be added to all other similar hash results (mod 2^512 or 2^768), and this result would be hashed one more time for the final result. It's necessary to make the intermediate results at least 2x the final hash size because the best known solution to the subset sum problem is solvable in 2^(N/2) operations. There's also the issue of tying the complexity of an addition operation to the complexity of computing a single hash result (e.g., 1 N-bit Hash might equal 100 N-bit modular adds). For this reason, using 3x the final hash size for intermediates would be more conservative. General Comments on Skein: Overall, I'm very happy with the results of Skein, and the three-fish project. When Ron Rivest described his Halloween hashing function during Crypto 2008, I liked its simplicity (only simple operators), but disliked that it was slower than SHA-256 and SHA-512. Skein has both delivered on security (so we think) and is faster and simpler than existing NIST hashing functions and block ciphers. In my opinion, SHA-2 and AES have already pegged the meter on practical security (of course, this may one day be false...), but there hasn't been enough emphasis on efficiency, cost, and parallelism. By using 64-bit addition as one of Skein's basic operations, the resistance against Shamir's Cube attack increases, although the hardware complexity increases quite a bit over Ron Rivest group's choice of operators that have no carry. I suspect that (as with the AES competition), that all of the contestants of the final round with be secure, and the winner will be the one that is most efficient, and to some extend, most flexible (although too much flexibility causes implementation issues when non-cryptographers have to write code to support all the options, and the designers have to be smart enough to pick the correct configuration). With more submissions like this, I expect we will be poised for an exciting NIST hash competition! Cheers, -Matt Matt Ball, IEEE P1619.x SISWG Chair Cell: 303-717-2717 http://www.linkedin.com/in/matthewvball http://www.mavaball.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NIST has posted public comments on XTS-AES
Hi Folks, NIST has completed the 90-day public review of the proposal from IEEE 1619 to add XTS-AES as an Approved Mode of Operation under FIPS 140. XTS-AES provides a narrow-block tweakable block cipher based on the XEX construction proposed by Phillip Rogaway. See the following link for comments, under the section Comments On The Proposal To Approve XTS-AES: http://csrc.nist.gov/groups/ST/toolkit/BCM/comments.html NIST received comments from the following individuals: * Moses Liskov, Kazuhiko Minematsu: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/XTS_comments-Liskov_Minematsu.pdf * Seagate Technology: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/XTS_comments-Seagate.pdf * Matt Ball: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/XTS_comments-Ball.pdf * Collected comments: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf - Boaz Shahar - David Clunie - Rich Shroeppel - Phillip Rogaway - Vijay Bharadwaj, Neils Ferguson Based on these comments, NIST will decide whether or not to approve XTS for FIPS 140-2/140-3. -- Thanks! -Matt Matt Ball, IEEE P1619.x SISWG Chair Cell: 303-717-2717 http://www.linkedin.com/in/matthewvball http://www.mavaball.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Period for public comments on XTS (as standardized by IEEE std 1619-2007) ends Sept 3, 2008
Hi Folks, Please remember that the 90-day public comment period for XTS ends Sept 3, which is coming up very quickly. If you have any comments you would like to submit to NIST concerning XTS-AES (as specified in IEEE Std 1619-2007), please send an e-mail to [EMAIL PROTECTED] The excerpt of IEEE 1619-2007 that specifies XTS-AES will be removed after the public review period ends. If you would like to get a free copy of the XTS specification, this will be your last chance! See http://grouper.ieee.org/groups/1619tmp/1619-2007-NIST-Submission.pdf [Original solicitation from NIST:] Request for Public Comment on XTS (See http://csrc.nist.gov/groups/ST/documents/Request-for-Public-Comment-on_XTS.pdf) The P1619 Task Group of the Security in Storage Working Group (SISWG) of the Institute of Electrical and Electronics Engineers, Inc. (IEEE) has submitted the XTS-AES algorithm (XTS, for short) to NIST as an encryption mode of operation of the Advanced Encryption Standard (AES) block cipher. Although XTS does not provide authentication in order to avoid expansion of the data, it is designed to provide some protection against malicious manipulation of the encrypted data. Subject to the 90-day period of public comment that is described below, NIST proposes to approve XTS for government use under the auspices of FIPS Pub. 140-2. XTS is specified in IEEE Std 1619-2007. IEEE has agreed to make a relevant extract from this standard available for free during the period of public comment. NIST proposes to approve the specification by reference to IEEE Std 1619-2007, while reserving the right to specify additional requirements/restrictions on XTS for government use. After the period of public comment, the standard would be available for purchase from IEEE for $85 to IEEE members and affiliates, and $105 to non-members. The chair of the SISWG informed NIST that he is unaware of any patent claims on XTS, but that NeoScale Systems, subsequently acquired by nCipher, submitted a Letter of Assurance of Essential Patents to the IEEE, without elaborating on what aspect of IEEE 1619 was patented. The period of public comment for this proposal is from June 5, 2008 to September 3, 2008. The extract of IEEE Std 1619-2007 is available for free during this period at http://grouper.ieee.org/groups/1619tmp/1619-2007-NIST-Submission.pdf. Comments may be submitted to [EMAIL PROTECTED] NIST particularly invites comments on the following topics: * The XTS algorithm itself; * The depth of support in the storage industry for which it was designed; * The appeal of XTS for wider applications; * The proposal for the approved specification to be available only by purchase from IEEE; * Concerns of intellectual property rights. Thanks! -Matt - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: security questions
On Wed, Aug 6, 2008 at 9:23 AM, Peter Saint-Andre wrote: Wells Fargo is requiring their online banking customers to provide answers to security questions such as these: *** What is name of the hospital in which your first child was born? ... What was your most memorable gift as a child? *** It strikes me that the answers to many of these questions might be public information or subject to social engineering attacks... Peter Of course, this problem isn't limited to Wells Fargo: I think pretty much all banks do it. I've given this some thought, and am writing a program called maiden (short for mother's maiden name) for cryptographically answering these questions. The basic idea is that you take either a pass phrase or strong secret, combine it with the question, compute the SHA hash, and use this to create a word that looks semi-pronounceable as the answer to the question. Right now, I don't answer any of these questions with any guessable information -- it's all the result of a cryptographic operation on the question and a hidden secret. Cheers, -Matt -- Thanks! Matt Ball, IEEE P1619.x SISWG Chair M.V. Ball Technical Consulting, Inc. Phone: 303-469-2469, Cell: 303-717-2717 http://www.mvballtech.com http://www.linkedin.com/in/matthewvball - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Looking through a modulo operation
On Mon, Jul 21, 2008 at 8:33 AM, Matt Ball [EMAIL PROTECTED] wrote:
If someone uses the __random32 function as defined in the 2.6.26
Linux kernel, and leaks to you the result of taking successive outputs
modulo 28233 (= 9 * 3137), can you determine the probable 96-bit
internal state with fewer than 1000 outputs and with modest processing
power (e.g., a laptop computer running less than a day)?
Another attacking avenue is the 32-bit initial seed. If the
implementation re-seeds frequently, or leaks to you the first outputs
after initialization, then you only have to brute-force the 32-bit
seed space, times the number of samples since reseeding.
Here is the function that performs the initial seeding, based on a 32-bit seed:
static void __set_random32(struct rnd_state *state, unsigned long s)
{
if (s == 0)
s = 1; /* default seed is 1 */
#define LCG(n) (69069 * n)
state-s1 = LCG(s);
state-s2 = LCG(state-s1);
state-s3 = LCG(state-s2);
/* warm it up */
__random32(state);
__random32(state);
__random32(state);
__random32(state);
__random32(state);
__random32(state);
}
For those who want to get cleaver, I suspect there is an optimization
for running __random32 six times.
--
Thanks!
Matt Ball, IEEE P1619.x SISWG Chair
M.V. Ball Technical Consulting, Inc.
Phone: 303-469-2469, Cell: 303-717-2717
http://www.mvballtech.com
http://www.linkedin.com/in/matthewvball
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The 2008 IEEE Key Management Summit is Currently Seeking Panelists
The 2008 IEEE Key Management Summit (KMS) is currently seeking six panelists to act as the voice of customers who have purchased or plan to purchase a cryptographic key management solution. The panels will be moderated by leading analysts Jon Oltsik of the Enterprise Strategy Group, and Ramon Krikken of the Burton Group. If you are interested in participating or know of someone who might be interested, please send an e-mail to [EMAIL PROTECTED] Examples of industries we would like to hear from: - Financial -- banks, credit card processing, credit unions, mutual fund managers, etc - Health Care -- key management for HIPAA compliance, etc - Government -- handling sensitive but unclassified information See more details at http://www.keymanagementsummit.com/2008/ About KMS 2008: The IEEE Key Management Summit brings together the top companies that develop cryptographic key management for storage devices with the standards organizations that make interoperability possible and the customers that rely on key management to secure their encrypted data. With recent legislation, such as California's SB 1386 or Sarbanes-Oxley, companies now have to publicly disclose when they lose unencrypted personal data. To meet this new need for encryption, many companies have developed solutions that encrypt data on hard disks and tape cartridges. The problem is that these data storage vendors need a solution for managing the cryptographic keys that protect the encrypted data. This summit aims to provide clarity to the key management by showing how existing products and standards organizations address the problem of interoperability and security. KMS 2008 is co-located with the IEEE Mass Storage and Systems Technologies conference http://storageconference.org/2008/ (MSST) in Baltimore, Maryland on September 23-24, 2008. Thanks! Matt Ball, Chair, KMS 2008 Phone: 303-469-2469, Cell: 303-717-2717 http://www.linkedin.com/in/matthewvball - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
