145 reputation
7
bio website
location France
age
visits member for 1 year, 6 months
seen Dec 14 at 19:16

Dec
6
accepted Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
Dec
5
comment Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
Ok clear. I will check more in detail Botan documentation and internal prng operation. I just add for info that in my application criticity of key generator makes that it might be implemented on a standalone Linux computer. So no more network access but inversely low activity and so low entropy available within the kernel through /dev/random device and to be compensated by a companion hardware entropy source as Intel drng for instance.
Dec
5
comment Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
I understand your warning about lack of backtracking resistance. In the concrete case of Botan library I noted that the complete prng was : entropy source => Botan random pool => x9.31 prng => random output. So with x9.31 seed key and date/time vector issued from Botan proper random pool output. So in that case i understand the threat assumed both knowkedge of overall combined prng state plus botan proper random pool prng not based on a one way function. Is it correct ? I precise that prng is to be used for keys generation so prng state value disclosing is a major threat.
Dec
5
comment Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
thanks for that great detailed , precise & pedagogic answer which provides rationale for confidence in NIST recommended extension of ANSSI X9.31 Appendix 2.4 PRNG with AES-256.
Dec
5
comment Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
@fgrieu- Thanks for clarification. My post was not sufficiently precise : effectively I implicitely referred to the PRNG as defined in Appendix 2.4 of ANSI X9.31-1998 standard . And so my trouble is that NIST agreed it in FIPS-140-2 (Annex C dated from 2012) while recommending use of 3-keys triple DES or AES, while NIST SP800-131A doc dated from January 2011, indicates that X9-31 -1998 PRNG is disallowed from 2015. So it seems to me that finally as you indicate, use of such X9.31 -1998 Appendix 2.4 PRNG with using AES-256 might not be concerned and so disallowed by NIST SP800-131A doc.
Dec
3
asked Will X9.31 remain a secure & acceptable deterministic random generator beyond 2015?
Jul
2
awarded  Curious
Jul
6
comment Security for IV in AES-GCM mode
you are right as iv is internally used by ghash function (gcm/gmac specifity). In my application the complete security header (key number, iv , anti replay counter ...) is de facto included in AD data but as you indicate it was not mandatory for the iv (redundant protection).thanks for the correction.
Jul
6
comment Security for IV in AES-GCM mode
Complementary comment following previous implementation of gcm-aes : iv has as indicated to be appended in clear form with the ciphertext but in addition it must be part of the clear AD data sequence included in mac computation so to prevent at 100% from iv modification. lastly gcm cannot really be compared with hmac which only performs mac based authentication and not encryption
Jul
3
accepted Is it possible to insert a key derivation function when using EAX?
Jul
3
comment Is it possible to insert a key derivation function when using EAX?
@ Ilmari Karonen: Perfectly clear; as indicated answer & explanations given by Archie in previous post were also quite clear, and in fact I realize that I incorrectly understood EAX2 rather as a reference construction aimed to define EAX and demonstrate its security proof, than a candidate AEAD composition. So now the choice appears clearly between trusted EAX or (Key derivation plus) trusted EAX2 . Thanks to all.
Jul
2
comment Is it possible to insert a key derivation function when using EAX?
i agree of course . solution is either a generic ctr then cmac composition with key dérivation or reuse of gcm which only raised a warning in previous application to the concerned reqt because of partial key derivation (K and H used from input K). still thanks for your precise explanations.
Jul
2
comment Is it possible to insert a key derivation function when using EAX?
the source is the french équivalent of nist fips-140-2 that is applicable to my application covering various reqts about crryptographic fonctions and keys handling for solutions that will be then subject to Common Criteria security évaluation.
Jul
2
comment Is it possible to insert a key derivation function when using EAX?
i understand and i really don't aim to tinker with internal design of any trusted mode it's not my rôle. i have to design a solution using EAX which will have to pass Common Criteria evaluation and one of my applicable security requirement indicates explicitely use or separate keys for authentication and for encryption. I can of course use gcm mode with derived ghash key but i am interested with eax and embedded robust omac for authentication.
Jul
2
asked Is it possible to insert a key derivation function when using EAX?
Jul
1
accepted Are stream ciphers no longer considered by NIST?
Jul
1
comment Are stream ciphers no longer considered by NIST?
thanks for answer & post update with missed URL links. I think you're right and nist might not consider a major interest for stream ciphers. this is not a minor concern according to nist rôle.
Jun
30
comment Are stream ciphers no longer considered by NIST?
thanks for estream derived portfolio while i only mentionned stream ciphers standardized by ISO. it is strange for me that no stream cipher appears approved by nist for PRG or for encryption
Jun
30
asked Are stream ciphers no longer considered by NIST?
Jun
28
awarded  Commentator