Re: gauging interest in forming an USA chapter of IISP
Ali, Sorry for the misunderstanding. I'm not soliciting for new members. If there happens to be anyone on this list who is an IISP member and lives in the USA and would be interested in forming a chapter on this side of the Atlantic then I'd like to work with them to establish it. That's all. - Alex At 11:05 AM 12/13/2007 -0800, Ali, Saqib wrote: How will this be any different from being a member of ISC2 or ISACA? Why do we need to be a member of yet another organization? saqib http://www.quantumcrypto.de/dante/ On Dec 12, 2007 12:21 PM, Alex Alten [EMAIL PROTECTED] wrote: Would anyone on this list be interested in forming a USA chapter of the Institute of Information Security Professionals (IISP, www.instisp.org)? I'm finding it rather difficult to attend events, etc., that are only in London. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Flaws in OpenSSL FIPS Object Module
On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote: | It is, of course, the height of irony that the bug was introduced in | the very process, and for the very purpose, of attaining FIPS | compliance! | | But also to be expected, because the feature in question is | unnatural: the software needs a testable PRNG to pass the compliance | tests, and this means adding code to the PRNG to make it more | predictable under test conditions. Agreed. In fact, this fits with an observation I've made in many contexts in the past: Any time you introduce a new mode of operation, you are potentially introducing a new failure mode corresponding to it as well. In fact, I was in the middle of a FIPS-140 certification at level 2 a number of years ago when the Known Answer Test for the X9.17 block cipher based PRNG was introduced. One unanticipated side effect of this test was to make it impossible to actually use a clock or free running counter as the counter in the PRNG, since the KAT expected the simplistic increment counter by 1 every time a block is extracted behavior chosen by most implementers. Of course, that mode is _less_ secure (because the internal state is more predictable) than the other, but given the choice between validate PRNG using special mode, run it using normal mode or validate PRNG using special mode, run it using special mode I know I'd pretty much always take the latter. In fact, the test lab we were using told us they were quite skeptical about the former as well. Fortunately, the requirement for the PRNG KAT was delayed long enough to let us get our code out the door without having to actually choose either of the unpalatble ways. But it does highlight a certain tension in the process: they want to know that algorithms have predictable (correct) results, but RNGs are supposed to have unpredicatable (correct) results. So any PRNG that is testable as part of the certification process pretty much _has to_ have two modes, and bugs like this may be more likely to occur in normal operation. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More on in-memory zeroisation
On Tue, 11 Dec 2007, Leichter, Jerry wrote: You can almost, but not quite, get the desired effect for memory zero- ization with volatile. I thought that this was guaranteed to work: volatile char buf[SIZE]; /* ... do stuff with buf ... */ memset(buf, 0, sizeof(buf)); --apb (Alan Barrett) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More on in-memory zeroisation
On Wed, Dec 12, 2007 at 05:27:38PM -0500, Thierry Moreau wrote:
As a consequence of alleged consensus above, my understanding of the C
standard would prevail and (memset)(?,0,?) would refer to an external
linkage function, which would guarantee (to the sterngth of the above
consensus) resetting an arbitrary memory area for secret intermediate
result protection.
GCC on x86-64 (-O2) compiles this function to the same machine code
regardless of the value of ZEROIZE:
#include string.h
int sensitive(int key)
{
char buf[16];
int result = 0;
size_t j;
for(j = 0; j != sizeof(buf); j++)
buf[j] = key + j;
for(j = 0; j != sizeof(buf); j++)
result += buf[j];
#if ZEROIZE
(memset)(buf, 0, sizeof(buf));
#endif
return result;
}
Even if (memset) must refer to a function with external linkage (an
analysis I find dubious), there is nothing stopping the compiler from
doing IPA/whole program optimization - especially with a very basic
function like memset (in the code above, if buf is declared volatile,
GCC does do the memset: but it does it by moving immediate zero values
directly to the memory locations, not by actually jumping to any
external function).
Regards,
Jack
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gauging interest in forming an USA chapter of IISP
How will this be any different from being a member of ISC2 or ISACA? Why do we need to be a member of yet another organization? saqib http://www.quantumcrypto.de/dante/ On Dec 12, 2007 12:21 PM, Alex Alten [EMAIL PROTECTED] wrote: Would anyone on this list be interested in forming a USA chapter of the Institute of Information Security Professionals (IISP, www.instisp.org)? I'm finding it rather difficult to attend events, etc., that are only in London. - Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PunchScan voting protocol
On 12/12/07, John Denker [EMAIL PROTECTED] wrote: Several important steps in the process must be carried out in secret, and if there is any leakage, there is unbounded potential for vote-buying and voter coercion. I've done quite a bit of work with this protocol. The protocol assumes the existence of an Election Authority. The Authority has the master keys required to generate certain data sets, and these keys give the Authority the ability to associate ballot numbers with votes. Note that this doesn't necessarily give the Authority the ability to associate people with votes. There are no per-ballot keys, so there is no partial exposure risk. It's all-or-nothing. 1) It would be nice to see some serious cryptological protection of election processes and results. 2b) In particular I don't think PunchScan really solves the whole problem. What is the whole problem? Please provide an attack model. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
James A. Donald [EMAIL PROTECTED] writes: At every block boundary, keyboard transmits a special signal in the clear that signifies block boundary. Any time that no key has been pressed for a while, then when a key is finally pressed, keyboard transmits a bunch of no- ops sufficient to ensure that the recipient has recently received an entire block, followed by a complete description of current keyboard state, so that ... the battery runs down in a fraction of the time that it does for any other keyboard on the market. Would it be possible to use load modulation (e.g. ISO 14443, for which transponders are readily available) to get around this, where the power for the communication is supplied by the PC? That way you could have a protocol that's as chatty as you like without your keyboard ending up as an advertising device to make your competitors' products look good. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: More on in-memory zeroisation
I've been through the code. As far as I can see, there's nothing in
expand_builtin_memset_args that treats any value differently, so there can't be
anything special about memset(x, 0, y). Also as far as I can tell, gcc doesn't
optimise out calls to memset, not even thoroughly dead ones: for example -
/artimi/software/firmware $ cat memstst.c
#include string.h
int foo (void);
int main (int argc, const char **argv)
{
int var[100];
memset (var, 0, sizeof var);
foo ();
return 0;
}
int foo (void)
{
int var[100];
memset (var, 0, sizeof var);
return 0;
}
/artimi/software/firmware $ gcc -O2 memstst.c -o mt
/artimi/software/firmware $ gcc -O2 memstst.c -S -o memstst.s
/artimi/software/firmware $ grep memset memstst.s
call_memset
call_memset
.def_memset;.scl3; .type 32; .endef
/artimi/software/firmware $
This is not entirely unexpected; memset, even when expanded inline as a
builtin, still has libcall behaviour.
cheers,
DaveK
--
Can't think of a witty .sigline today
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More on in-memory zeroisation
On Thu, 13 Dec 2007 21:11, [EMAIL PROTECTED] said:
volatile char buf[SIZE];
/* ... do stuff with buf ... */
memset(buf, 0, sizeof(buf));
This has the little disadvantage that you need to check the attributes
of BUF first and that you can't immediately see what the memset is used
for. For a long time we use the macros below to document the intention
and to make sure that the compiler does not do any harm:
/* To avoid that a compiler optimizes certain memset calls away, these
macros may be used instead. */
#define wipememory2(_ptr,_set,_len) do { \
volatile char *_vptr=(volatile char *)(_ptr); \
size_t _vlen=(_len); \
while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
} while(0)
#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
