Re: PlayStation 3 predicts next US president

2007-12-13 Thread Ed Gerck

Allen wrote:

William Allen Simpson wrote:
[snip]


The whole point of a notary is to bind a document to a person.  That the
person submitted two or more different documents at different times is
readily observable.  After all, the notary has the document(s)!


No, the notary does not have the documents *after* they are notarized, 
nor do they keep copies. Having been a notary I know this personally. 


Thanks, Allen. Interestingly, digital signatures do provide what
notaries can't provide in this case. Even though a digital signature
binds a document to a key, there are known legal frameworks that can
be used to bind the key to a person.

Cheers,
Ed Gerck

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread Leichter, Jerry
|  The whole point of a notary is to bind a document to a person.  That
|  the person submitted two or more different documents at different
|  times is readily observable.  After all, the notary has the
|  document(s)!
| 
| No, the notary does not have the documents *after* they are notarized,
| nor do they keep copies. Having been a notary I know this
| personally. When I stopped being a notary all I had to submit to the
| state was my seal and my record books.
| 
| If I had to testify about a document I would only be attesting that
| the person who presented themselves adequately proved, under the
| prudent businessman's standard, that they were the person that they
| said they were and that I saw them sign the document in
| question. That's it. No copies at all. What would anyone have to
| testify about if a legal battle arose after the notary either died or
| stopped being a notary?
| 
| Think for a minute about the burden on a notary if they had to have a
| copy of every document they notarized. What a juicy target they would
| make for thieves and industrial spies. No patent paperwork would be
| safe, no sales contract, no will, or other document. Just think how
| the safe and burglar alarm companies would thrive. Now ask yourself
| how much it costs to notarize a document. Would that pay for the
| copying and storage. I don't know what the current fees are in
| California but 20 years ago they were limited to $6.00 per person per
| document and an extra buck for each additional copy done at the same
| time. My average was about $14.00 per session. My insurance was
| $50/year.  Nowhere near enough to cover my liability if I was to
This whole discussion has an air of unreality about it.

Historically, notary publics date from an era when most people couldn't
read or write, and hardly anyone could afford a lawyer.  How does
someone who can't read a document and can perhaps only scrawl an X
enter into a contract?  In the old days, he took the written contract
to a notary public, who would read it to him, explain it, make sure
he understood it, then stamp his scrawled X.  The notary's stamp
asserted exactly the kind of thing that we discuss on this list as
missing from digital signatures:  That the particular person whose
X was attached (and who would be fully identified by the notary)
understood and assented to the contents of the contract.

Today, we assume that everyone can read, and where a contract is at all
complex, that everyone will have access to a lawyer.  (Of course, this
assumption is often invalid, but that's another story.)  The requirement
for a notary public's stamp is a faded vestige.  For certain important
documents, we still require that a notary sign off, but what exactly
that proves any more is rather vague.  Yes, in theory it binds a
signature to a particular person, with that signature being on a
particular document.  That latter is why the notary's stamp is a
physical stamp through the paper - hard(er) to fake.  Of course, most of
the time, the stamp is only applied to the last page of a multi-page
contract, so proves only that that last page was in the notary's hands -
replacing the early pages is no big deal.  I think I've seen notaries
initial every page, but I've also seen notaries who don't.

In practice, whenever I've needed to have a document notarized, a quick
look at some basic ID is about all that was involved.  It's quite easy
to get fake ID past a notary.  Given the trivial fee paid to a notary -
I think the limit is $2 in Connecticut - asking the notary to actually
add much of value is clearly a non-starter.

The financial industry has actually created its own system - I forget
the name, some like a Gold Bond Certification - that it requires for
certain high-importance transactions (e.g., a document asserting you
own some stock for which you've lost the certificates).  I've never
actually needed to get this - it's appeared as a requirement for
some alternative kinds of transactions on forms I've had to fill out
over the years - so I don't know exactly how it works.  However, it's
completely independent of the traditional notary public system, and
is run through commercial banks.

Trying to justify anything based on the current role of notary
publics - at least as it exists in the US - is a waste of time.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Flaws in OpenSSL FIPS Object Module

2007-12-13 Thread Leichter, Jerry
|  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.  Thus, bulkhead doors on sidewalks are unlikely to open
under you because the only mode of operation they try to support has
the doors opening upward.  I would be very leary of stepping on such
a door if it could *ever* be opened downward.

| As the tests only test the predictable PRNG, it is easy to not notice
| failure to properly re-seed the non-test PRNG. One can't easily test
| failure to operate correctly under non-test conditions. And the
| additional complexity of the test harness makes such failure more
| likely.
| 
| The interaction of the test harness with the software under study
| needs close scrutiny (thorough and likely multiple independent code
| reviews).
There's a famous story - perhaps apocryphal - from the time IBM
introduced some of the first disk packs.  They did great for a while,
but then started experiencing head crashes at a rate much higher than
had ever been seen in the development labs.  The labs, of course,
suspected production problems - but packs they brought in worked just
as well as the ones they'd worked with earlier.

Finally, someone sitting there, staring at one of the test packs and
at a crashed disk from a customer had a moment of insight.  There was
one difference between the two packs:  The labs pulled samples
directly off the production line.  Customers got packs that had gone
through QA.  The last thing QA did was put a Passed sticker on the
top disk of the pack.

So ... take a pack with a sticker and spin it up.  This puts G forces
on the sticker.  The glue under the sticker slowly begins to migrate.
Eventually, some of it goes flying off into the enclosure.  If it
gets under a head ... crash.

| Similar bugs are just as likely in closed-source software and are less
| likely to be discovered.
Actually, now that this failure mode has been demonstrated, it would
be a good idea to test for it.  It's harder to do with just binaries,
but possible - look at the recent analyses of the randomization in
Vista ASLR.
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: More on in-memory zeroisation

2007-12-13 Thread Leichter, Jerry
|  Then the compiler can look at the implementation and prove that a
|  memset() to a dead variable can be elided
| 
| One alternative is to create zero-ing functions that wrap memset()
| calls with extra instructions that examine some of the memory, log a
| message and exit the application if the memory is not zero. This has
| two benefits: 1) It guarantees the compiler will leave the memset() in
| place and 2) guarantees the memset() worked. It does incur a few extra
| instructions though.
| 
| I guess it is possible that the compiler would somehow optimize the
| memset to only zero the elements subsequent code compares... Hmmm
| [Of course your application could be swapped out and just before the
| memset call writing your valuable secrets to the system swap file on
| disk... :-( ]
In practice, with an existing compiler you are not in a position to
change, these kinds of games are necessary.  If you're careful, you look
at the generated code to make sure it does what you expect.

But this is a very bad - and potentially very dangerous - approach.
You're relying on the stupidity of the compiler - and on the compiler
not become more intelligent over time.  Are you really prepared to
re-check the generated code every time the compiler is rev'ed?

There sometimes needs to be an explicit way to tell the compiler that
some operation *must* be done in some way, no matter what the compiler
thinks it knows.  There's ample precedent for this.  For example,
floating point arithmetic doesn't exactly follow the usual laws of
arithmetic (e.g., it's not associative, if you consider overflows), some
if you know what you are doing in construction an FP algorithm, you have
to have a way to tell the compiler Yes, I know you think you can
improve my code here, but just leave it alone, thank you very much.
And all programming languages that see numerical programming as within
their rubric provide standardized, documented ways to do just that.  C
have volatile so that you can tell the compiler that it may not elide
or move operations on a variable, even when those operations have no
effects visible in the C virtual machine.  (The qualifier was added
to support memory-mapped I/O, where there can be locations that look
like memory but have arbitrarily different semantics from normal
memory.)  And so on.

You can almost, but not quite, get the desired effect for memory zero-
ization with volatile.  Something more is needed, and software that
will be used to write cryptographic algorithms needs access to that
something more (to be pinned down explicitly).

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Leichter, Jerry
|  However, that doesn't say anything about whether f is actually
|  invoked at run time.  That comes under the acts as if rule:  If
|  the compiler can prove that the state of the C (notional) virtual
|  machine is the same whether f is actually invoked or not, it can
|  elide the call.  Nothing says that memset() can't actually be
|  defined in the appropriate header, as a static (or, in C99, inline)
|  function.
| 
| The standard actually says ... it is permitted to take the address of
| a library function even if it is defined as a macro  The standard
| works for me as a source code author who needs an execution-aware
| memcpy function from time to time. Overworked GCC contributors should
| work to comply to the standard, not to address Peter, Thierry, and
| whoever's wildests dreams.
If the function is defined as I suggested - as a static or inline - you
can, indeed, takes its address.  (In the case of an inline, this forces
the compiler to materialize a copy somewhere that it might not otherwise
have produced, but not to actually *use* that copy, except when you take
the address.)  You are allowed to invoke the function using the address
you just took.  However, what in that tells you that the compiler -
knowing exactly what code will be invoked - can't elide the call?

By the way, you might wonder what happens if two different CU's take
the address of memset and we then compare them.  In this kind of
implementation, they will be unequal - but in fact nothing in the
Standard says they can't be!  A clever compiler could have all kinds
of reasons to produce multiple copies of the same function.  All you
can say is that if two function pointers are equal, they point to the
same function.  No converse form is provable within the Standard.

You might try something like:

typedef (void *(*memset_ptr)(const void*,int,size_t));

volatile memset_ptr p_memset = (memset);

(I *think* I got that syntax right!)

Then you can invoke (*p_memset).  But if you do this in the same
compilation unit, a smart compiler that does value propagation could
determine that it knows where p_memset points, and that it knows what
the code there is, so it can go ahead and do its deeper analysis.

Using:

volatile memset_ptr p_memset = (memset);

in one compilation unit and then:

extern volatile memset_ptr p_memset = (memset);

will keep you safe from single-CU optimizations, but nothing in the
Standard says that's all there are.  Linker-based optimizations
could have the additional information that nowhere in the program
can p_memset be changed, and further that p_memset is allocated to
regular memory, and in principle the calls could be elided at that
point.  Mind you, I would be astounded if any compiler/linker system
actually attempted such an optimization ... but that doesn't make
it illegal within the language of the Standard.

|  Then the compiler can look at the implementation and prove
|  that a memset() to a dead variable can be elided
| 
| It can't prove much in the case of (memset)()
In principle (I'll grant you, probably not in practice), it can
provie quite a bit - and certainly enough to justify eliding the
call.
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Intercepting Microsoft wireless keyboard communications

2007-12-13 Thread Taral
On 12/10/07, Steven M. Bellovin [EMAIL PROTECTED] wrote:
 Believe it or not, I thought of CFB...

What about PCFB to get around the block issue? I remember freenet
using it that way...

-- 
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

2007-12-13 Thread James A. Donald

Steven M. Bellovin wrote:
 Believe it or not, I thought of CFB...

 Sending keep-alives will do nasties to battery
 lifetime, I suspect; most of the time, you're not
 typing.  As for CFB -- with a 64-bit block cipher (you
 want them to use DES? they're not going to think of
 anything different), it will take 9 keypresses to
 flush the buffer.  With AES (apparently your
 assumption), it will take 17 keypresses.  This isn't
 exactly muggle-friendly.  Just think of the text in
 the instructions... Redundancy?  I wonder how much is
 needed to avoid problems.  It has to be a divisor of
 the cipher block size, which more or less means 8
 extra bits.  How much will that cost in battery life?

Keypress signals, or change of keyboard state signals,
do not need to be a divisor of the cipher block size.

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
recipient knows what change of keyboard state signals
are changes from.  Conversely, when the receiver has not
received any signal for a while, it expects such a
signal, and distrusts anything else. Muggle
unfriendliness only occurs if user is typing through a
boot up, which is unlikely to terribly surprise the
user, who is probably banging away at the same keys over
and over again waiting for a reaction, or if the user
wanders out of range while typing, then wanders back in
range again while still typing, in which case again the
user is unlikely to be very surprised.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Thierry Moreau



Leichter, Jerry wrote:


If the function is defined as I suggested - as a static or inline - you
can, indeed, takes its address.  (In the case of an inline, this forces
the compiler to materialize a copy somewhere that it might not otherwise
have produced, but not to actually *use* that copy, except when you take
the address.)  You are allowed to invoke the function using the address
you just took.  However, what in that tells you that the compiler -
knowing exactly what code will be invoked - can't elide the call?


Case of static function definition: the standard says that standard 
library headers *declare* functions, not *define* them.


Case of inline: I don't know if inline definition falls in the standard 
definition of declaration.


Also, the standard refers to these identifiers as external linkage. This 
language *might* not creare a mandatory provision if there was a 
compelling reason to have static or inline implementation, but I doubt 
the very infrequent use of (memset)(?,0,?) instead of memset(?,0,?) is a 
significant optimization opportunity. The compiler writer risks a 
non-compliance assessment in making such strectched reading of the 
standard in the present instance, for no gain in any benchmark or 
production software speed measurement.


Obviously, a pointer to an external linkage scope function must adhere 
to the definition of pointer equality (==) operator.


Maybe a purposedly stretched reading of the standard might let you make 
your point. I don't want to argue too theoretically. Peter and I just 
want to clear memory!


Kind regards,


--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: PlayStation 3 predicts next US president

2007-12-13 Thread James A. Donald

William Allen Simpson wrote:
 The whole point of a notary is to bind a document to a
 person.  That the person submitted two or more
 different documents at different times is readily
 observable.  After all, the notary has the
 document(s)!

The notary does not want to have the documents, or to
have the necessary apparatus to produce them on demand.
Actually existent notaries do not keep the documents.

Again, you are trying to invent a protocol that works
around the flaws in MD5.  No doubt a competent engineer
can create such a protocol, but a competent engineer
would much prefer not to have flaws he needs to work
around.

Further, there is a long history of cryptographic
disasters, such as WiFi, where supposedly competent
engineers set to working around flaws, and instead
created more and bigger flaws.  Even if someone really
is a competent engineer, and perfectly capable of
producing a protocol that works around the known flaws,
it is hard for anyone else to tell if he really is
competent enough to work around the flaws, or has
produced, like WiFi and so many Microsoft projects, an
even bigger hole than that which he was trying to fix.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


PunchScan voting protocol

2007-12-13 Thread John Denker
Hi Folks --

I was wondering to what extent the folks on this list have taken
a look the PunchScan voting scheme:

  http://punchscan.org/

The site makes the following claims:

 End-to-end cryptographic independent verification, or E2E, is a
  mechanism built into an election that allows voters to take a 
 piece of the ballot home with them as a receipt. This receipt 
 does not allow voters to prove to others how they voted, but it
  does permit them to:

 * Verify that they have properly indicated their votes to 
 election officials (cast-as-intended).
 * Verify with extremely high assurance that all votes were
 counted properly (counted-as-cast).

 Voters can check that their vote actually made it to the tally,
 and that the election was conducted fairly.


Those seem at first glance to be a decent set of claims, from
a public-policy point of view.  If somebody would prefer a
different set of claims, please explain.


PunchScan contains some nifty crypto, but IMHO this looks like
a classic case of too much crypto and not enough real security.

I am particularly skeptical of one of the FAQ-answers
 http://punchscan.org/faq-protections.php#5

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.
  The Boss can go to each voter and make the usual silver-or-lead
  proposition:  Vote as I say, and then show me your voting receipt.
  I'll give you ten dollars.  But if I find out you voted against
  me, I'll kill you.

The voter cannot afford to take the chance that even a small
percentage of the ballot-keys leak out.

1) It would be nice to see some serious cryptological protection
of election processes and results.

2a) I don't think we're there yet.

2b) In particular I don't think PunchScan really solves the
whole problem.

3) I'd love to be wrong about item (2).  Does anybody see a way
to close the gaps?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Leichter, Jerry
|  If the function is defined as I suggested - as a static or inline -
|  you can, indeed, takes its address.  (In the case of an inline, this
|  forces the compiler to materialize a copy somewhere that it might
|  not otherwise have produced, but not to actually *use* that copy,
|  except when you take the address.)  You are allowed to invoke the
|  function using the address you just took.  However, what in that
|  tells you that the compiler - knowing exactly what code will be
|  invoked - can't elide the call?
| 
| Case of static function definition: the standard says that standard
| library headers *declare* functions, not *define* them.
Where does it say it *can't* define them?  How could a Standard-conforming
program tell the difference?  If no Standard-conforming program can
tell the difference between two implementations, it makes no difference
what you, as an omniscient external observer, might know - they are either
both compatible with the Standard, or neither is.

| Case of inline: I don't know if inline definition falls in the
| standard definition of declaration.
It makes not difference.

| Also, the standard refers to these identifiers as external
| linkage. This language *might* not creare a mandatory provision if
| there was a compelling reason to have static or inline implementation,
| but I doubt the very infrequent use of (memset)(?,0,?) instead of
| memset(?,0,?) is a significant optimization opportunity. The compiler
| writer risks a non-compliance assessment in making such strectched
| reading of the standard in the present instance, for no gain in any
| benchmark or production software speed measurement.
| 
| Obviously, a pointer to an external linkage scope function must adhere
| to the definition of pointer equality (==) operator.
What do you think the definition of pointer equality actually is?  Keep
in mind that you need to find the definition *in the Standard*.  The
*mathematical* definition is irrelevant.

| Maybe a purposedly stretched reading of the standard might let you
| make your point. I don't want to argue too theoretically. Peter and I
| just want to clear memory!
Look, I write practical programs all the time - mainly in C++ recently,
but the same principles apply.  My programs tend to be broadly portable
across different compilers and OS's.  I've been doing this for close to
30 years.  I stick to the published standards where possible, but there's
no way to avoid making assumptions that go beyond the standards in a few
cases:  Every standard I know of is incomplete, and no implementation I've
ever worked with is *really* 100% compliant.

It's one thing to point out a set of practical techniques for getting
certain kinds of things done.  It's another to make unsupportable arguments
that those practical techniques are guaranteed to work.  There's tons of
threaded code out there, for example.  Given the lack of any discussion of
threading in existing language standards, most of them skate on thin ice.
Some things are broadly agreed upon, and quality of implementation
requirements make it unlikely that a compiler will break them.  Other
things are widely believed by developers to have been agreed upon, but
have *not* really be agreed upon by providers.  Programs that rely on
these things - e.g., that C++ function-scope static initializers will be
run in a thread-safe way - will fail here and there, because in fact
compiler developers don't even try to support them.  Because of the ever-
growing importance of threaded programs, this situation is untenable, and
in fact the language groups are starting to grapple with how to incorporate
threads.

Security issues are a similar issue.  The fact is, secure programming
sometimes requires primitives that the standards simply don't provide.
Classic example:  For a long time, there was *no* safe way to use
sprintf(), since there was no a priori way of determining how long the
output string might be.  People had various hacks, but all of them could
be fooled, unless you pretty much re-implemented sprintf() yourself.
snprintf() fixed that.

There is, today, no way to guarantee that memset() will be run, within the
confines of the standard.  This is a relatively minor oversight - C has
seen such issues as important since volatile was introduced well before
the language was standardized.  I expect we'll see some help on this in
a future version.  In the meanwhile, it would be nice if compiler
developers would agree on some extra-Standard mechanisms.  The gcc hack
could be a first step - but it should be written down, not just something
a few insiders know about.  Standards are supposed to grow by standardi-
zing proven practice, not by innovation.

The problem with unsupportable assumptions that some hack or another
provides a solution is that they block *actual* solutions.  By all means
use them where necessary - but push for better approaches.

-- Jerry

| Kind regards,
| 
| 

Google Tech Talk : Theory and Practice of Cryptography

2007-12-13 Thread Ryan Phillips
I have yet to watch it.

http://video.google.com/videoplay?docid=2899172465808407804

Description:

Topics include: Introduction to Modern Cryptography, Using Cryptography in
Practice and at Google, Proofs of Security and Security Definitions and A
Special Topic in Cryptography

This talk is one in a series hosted by Google University: Wednesdays,
11/28/07 - 12/19/07 from 1-2pm

Speaker: Steve Weis
Steve Weis received his PhD from the Cryptography and Information Security
group at MIT, where he was advised by Ron Rivest. He is a member of
Google's Applied Security (AppSec) team and is the technical lead for
Google's internal cryptographic library, KeyMaster

-Ryan

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


gauging interest in forming an USA chapter of IISP

2007-12-13 Thread Alex Alten


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: PlayStation 3 predicts next US president

2007-12-13 Thread Florian Weimer
* William Allen Simpson:

 Assuming,
   Dp := any electronic document submitted by some person, converted to its
 canonical form
   Cp := a electronic certificate irrefutably identifying the other person
 submitting the document
   Cn := certificate of the notary
   Tn := timestamp of the notary
   S() := signature of the notary

   S( MD5(Tn || Dp || Cp || Cn) ).

 Of course, I'm sure the formula could be improved, and there are
 traditionally fields identifying the algorithms used, etc. -- or something
 else I've forgotten off the top of my head -- but please argue about the
 actual topic of this thread, instead of incessant strawmen.

The problem is not the outer MD5 (explicitly mentioned in your
description), but that Dp is typically (well, to the extent such
services have been deployed) some kind of hash.  This has got the
advantage that the timestamping service does not need to know the
contents of the document.  On the other hand, if the timestamping
service archives Dp and can reveal it in a dispute, evil twins can be
identified and analyzed -- which undermine the submitting party's claim
that it submitted the second document instead of the first.

Of course, this is actually cheating by substituting proven protocols
for fragile cryptography.  And the result is still open to
interpretation, but all evidence is.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Thierry Moreau

/ testf.c /
#include stdio.h
#include string.h

typedef void *(*fpt_t)(void *, int, size_t);

void f(fpt_t arg)
{
if (memset==arg)
printf(Hello world!\n);
}

/ test.c /
#include stdlib.h
#include string.h

typedef void *(*fpt_t)(void *, int, size_t);

extern void f(fpt_t arg);

int main(int argc, char *argv[])
{
f(memset);
return EXIT_SUCCESS;
}

/*   I don't want to argue too theoretically.

- Thierry Moreau */

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Leichter, Jerry


On Wed, 12 Dec 2007, Thierry Moreau wrote:

| Date: Wed, 12 Dec 2007 16:24:43 -0500
| From: Thierry Moreau [EMAIL PROTECTED]
| To: Leichter, Jerry [EMAIL PROTECTED]
| Cc: Peter Gutmann [EMAIL PROTECTED], cryptography@metzdowd.com
| Subject: Re: More on in-memory zeroisation
| 
| / testf.c /
| #include stdio.h
| #include string.h
| 
| typedef void *(*fpt_t)(void *, int, size_t);
| 
| void f(fpt_t arg)
| {
|   if (memset==arg)
|   printf(Hello world!\n);
| }
| 
| / test.c /
| #include stdlib.h
| #include string.h
| 
| typedef void *(*fpt_t)(void *, int, size_t);
| 
| extern void f(fpt_t arg);
| 
| int main(int argc, char *argv[])
| {
|   f(memset);
|   return EXIT_SUCCESS;
| }
| 
| /*   I don't want to argue too theoretically.
| 
| - Thierry Moreau */
I'm not sure what you are trying to prove here.  Yes, I believe that
in most implementations, this will print Hello world\n.  Is it,
however, a strictly conforming program (I think that's the right
standardese) - i.e., are the results guaranteed to be the same on
all conforming implementations?  I think you'll find it difficult
to prove that.

BTW, it *might* not even be true in practice if you build your program
as multiple shared libraries!
-- Jerry



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: More on in-memory zeroisation

2007-12-13 Thread Thierry Moreau



Leichter, Jerry wrote:



On Wed, 12 Dec 2007, Thierry Moreau wrote:

| Date: Wed, 12 Dec 2007 16:24:43 -0500
| From: Thierry Moreau [EMAIL PROTECTED]
| To: Leichter, Jerry [EMAIL PROTECTED]
| Cc: Peter Gutmann [EMAIL PROTECTED], cryptography@metzdowd.com
| Subject: Re: More on in-memory zeroisation
| 
| / testf.c /

| #include stdio.h
| #include string.h
| 
| typedef void *(*fpt_t)(void *, int, size_t);
| 
| void f(fpt_t arg)

| {
|   if (memset==arg)
|   printf(Hello world!\n);
| }
| 
| / test.c /

| #include stdlib.h
| #include string.h
| 
| typedef void *(*fpt_t)(void *, int, size_t);
| 
| extern void f(fpt_t arg);
| 
| int main(int argc, char *argv[])

| {
|   f(memset);
|   return EXIT_SUCCESS;
| }
| 
| /*   I don't want to argue too theoretically.
| 
| - Thierry Moreau */

I'm not sure what you are trying to prove here.  Yes, I believe that
in most implementations, this will print Hello world\n.  Is it,
however, a strictly conforming program (I think that's the right
standardese) - i.e., are the results guaranteed to be the same on
all conforming implementations?  I think you'll find it difficult
to prove that.


If there is a consensus among comforming implementation developers that 
the above program is comforming, that's a good enough proof for me.


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.


Reading ANSI X3.159-1989, I believe there would be such a consensus, and 
I find it quite obvious. You may disagree, and I will no further argument.


Regards,

--

- Thierry Moreau

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]