Re: [dgc.chat] Fwd: [NEC] #2.12: The RIAA Succeeds Where the CypherPunks Failed
On Wednesday, December 17, 2003, at 09:38 PM, Steve Schear wrote: Note that the broadening adoption of encryption is not because users have become libertarians, but because they have become criminals; to a first approximation, every PC owner under the age of 35 is now a felon. http://www.shirky.com/writings/riaa_encryption.html I'm not sure if Clay ever hung out on the cypherpunks list. None of this comes as a surprise. Most knew early on that widespread adoption of crypto would require a killer app and that cypherpunks were not delivering these apps because one could not predict what they would be. Right, a fair point. I've heard cypherpunks say that and I do think Clay was being a bit hard on them. To place the cypherpunks in the best possible light, perhaps better than they deserve, we might say it's sort of like criticizing Nikola Tesla for not routing an AC power grid through rural Tennessee. They would surely not be PGP and other encrypted email nor digital cash unless and until there was a small but lucrative market that could be addressed by such technology or a large market with broad citizen support. That file sharing could be it was also recognized a long time ago on the cypherpunks list. Yes, I have seen statements to that effect. Mind you, I only had occasional exposure to the cypherpunks list via Hettinga's feed. Which is probably fine because I have heard that receiving the cypherpunks list is like drinking from a fire hose, and Hettinga seems to forward the really informative and entertaining stuff from Tim May, Adam Back, et al anyway. The really interesting aspect of this is what it portends for the future. If, as Clay suggests, the current situation is like Prohibition from citizen perspective can we expect a similar repeal of government surveillance? If not, what will happen as large numbers of citizens adopt P2P systems that not only flaunt copyright law but communications more dear to those in power? Right, on the one hand it's cool that hordes of otherwise ordinary computer users can become interested in darknets, but on the other hand it's a bit scary that the sheer scale of it is orders of magnitude beyond getting a whiskey in a speakeasy. This could either thoroughly discourage the government or motivate them to do really draconian things like requiring computers and chips to meet a specific government specification which severely limits how they function. They're working on it. steve For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, My First Impression of the U.S.A., 1921 Yes, a good observation from the time of the first big War on Drugs, that is, the demon alcohol, wrecker of homes and corrupter of public morals, as anyone who has watched Cops can attest. Now I need a drink -- a glass of port sounds good. -- Patrick
Re: COWed news networks not showing Baghdad market dead
Status: RO Date: Fri, 28 Mar 2003 11:42:41 -0800 Subject: COWed news networks not showing Baghdad market dead From: Tim May [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I'm scanning all four COWed networks--CNN, Fox, MSNBC, CNBC--for images from the downtown Baghdad market and housing area strike. Supposedly Al Jazeera is showing the images of dismembered children, frantic searches under rubble, body parts blown against walls. Estimates are of 50 dead, though this may change. ... The BBCA evening news hosted by the lovely Mishal Hussein showed it all. Grown men screaming and crying over lost loved ones, a worried man muttering Allah Akhbar in clinging hope, a ten year old boy weeping near a puddle of blood on a stone stairway, frantic women screaming in hospital hallways, a child in hospital minus two legs. They were not targeted deliberately but that doesn't seem to console them. The specific operation underway now called Operation Iraqi Freedom is one small part of a much larger operation called The Project for a New American Century. This project aims, among other things, to depose brutal totalitarian dictators if and only if they make the mistake of opposing the interests of the U.S. government and its corporate partners without first acquiring nuclear weapons. The upside of the Project is that some brutal totalitarian dictators might possibly be replaced with the sort of kinder and gentler dictators we enjoy here in America. Which is good as far as it goes. Fewer people get thrown feet-first into plastic shredders, for example. I believe this Project will make more Arabs rally in support of firm Islamic government, reject Western culture and ideals, join radically anti-American militias, and commit more attacks against Americans. This threat will make more Americans rally in support of the U.S. government and gladly throw votes, dollars, and freedoms at the feet of those who promise security. This widespread popular support will enable the U.S. government to employ military tactics both domestically and abroad for the stated purpose of enhancing security. Of course, war is a racket, and the racket here is to expand the power and wealth of the government and its corporate partners. -- Patrick http://fexl.com
Yes, I really did zeroize that key (good sig this time I think)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(My PGP client botched the signature last time when I used the
clipboard method. This time I'm using the plugin button and it should
work. Stupid GUI crap.)
I have devised what I believe to be a foolproof and completely
portable way of setting an array of bytes to all zeroes, a common
security operation in cryptography programs.
void
clear_bytes(char magic, char p[], int n)
{
int i;
p[0] = magic;
for (i = 1; i n; i++)
p[i] = p[i-1];
for (i = 0; i n; i++)
if (p[i] != magic)
exit(magic);
}
In order to guarantee that this works, you must pass in 0 as the
value of the 'magic' parameter, and you also must establish that 0
value using a method that is completely undecidable even to the most
intelligent compiler optimizer theoretically possible.
Here is a simple example of how we can generate this undecidable
zero and pass it into the routine.
int
main(int argc, char *argv[])
{
char array[32];
char magic = (argc 1 ? 0 : 255);
clear_bytes(magic, array, sizeof(array));
return 0;
}
If you call this program with no command line arguments, the value of
magic will be 0 and the clear_bytes is guaranteed to zero out the
array.
If you call this program with any command line arguments at all, the
value of magic will be 255 and the clear_bytes routine will exit with
code 255. So the clear_bytes routine serves a dual purpose as an
assertion that the clearing operation actually occurs properly. If
it doesn't, your program aborts.
It is impossible for a compiler to optimize away any of this code,
because you can always find a way from OUTSIDE the program to make
magic take on a nonzero value and thus reach the abort condition.
Of course, your program will very likely expect command line
arguments, but you can use a slightly altered technique for
generating the necessary magic undecidable zero. For example, if
you know that your program will never be called with more than 5
arguments, just use this line:
char magic = (argc 6 ? 0 : 255);
In the very worst case the number of arguments to your program will
be totally indeterminate, with no theoretical upper bound. This
could easily happen if you expect file names with shell expansion,
for example. In this case, you could simply require that the very
first argument to your program must always be a specific character,
for example 't'.
char magic = ((argc 1 argv[1][0] == 't') ? 0 : 255);
With this line, if the first argument to the program starts with a
't', magic will take on the correct value of 0.
I do not recommend using anything in argv[0] because that is the
actual name of your program as invoked from the command line. This
could change if the executable file is renamed or if you call it with
a leading path.
You can always find some way to generate a magic undecidable zero.
Some variation of the argc/argv technique should serve you well in
all reasonable circumstances, but if you absolutely had to you could
read a zero byte out of a file somewhere.
Note that the clear_bytes function 'ands' each byte of the array with
the previous byte, starting with the magic value. Only a magic value
of 0 is guaranteed to make all the bytes zero. The second loop then
checks the operation, ensuring that each byte is equal to the magic
byte. This can only succeed if magic is 0 and all the bytes are 0.
(Actually it could succeed with a nonzero magic value, but only if
all the bytes were already equal to magic to begin with. Obviously
this case is irrelevant.)
So folks, this routine will definitely zero out an array, and it
doesn't rely on the va_list (vararg) technique described in
Welschenbach's book.
Personally I rarely use global variables, so I like to pass the magic
value around as an explicit parameter wherever it is needed. But you
could use a global magic variable if you preferred.
- - -- Patrick
http://fexl.com
-BEGIN PGP SIGNATURE-
Version: PGP 8.0
iQA/AwUBPl71Y1A7g7bodUwLEQKoywCgg50VenX0boJAeIxrNIYI9KAmhR0AoOvJ
XByLpkEtgt9QhFbmiHokzC3V
=ZLC3
-END PGP SIGNATURE-
Fwd: [dgc.chat] Yes, I really did zeroize that key
On Friday, February 28, 2003, at 12:50 AM, Jeroen C. van Gelderen wrote:
You are going trough a lot of trouble. What is your threat model?
Nothing special, just taking the typical step of zeroing out memory. I
just wanted to find a way to do it without using the va_list technique.
On Thursday, Feb 27, 2003, at 23:18 US/Eastern, Patrick Chkoreff wrote:
void
clear_bytes(char magic, char p[], int n)
{
int i;
p[0] = magic;
for (i = 0; i n-1; i++) {
p[i+1] = p[i];
for (i = 0; i n; i++)
if (p[i] != magic)
exit(magic);
}
Well... a theorem prover could infer that exit() isn't called if magic
is zero. If magic isn't used after clear_bytes is called on it then
the whole function call can be translated to:
void
clear_bytes(char magic, char p[], int n)
{
int i;
if(0==magic)
return;
[...]
}
This is a valid optimization.
That is a very astute observation. The [...] you mention would handle
the weird case of checking that all the bytes of the array happen to
equal the nonzero magic byte. For example, if you passed in magic ==
37, and all the bytes happened to be 37, then the exit call would not
be reached.
So the full exact optimized code that did not actually affect the
memory bytes would be:
void
clear_bytes(char magic, char p[], int n)
{
int i;
if (magic != 0)
for (i = 0; i n; i++)
if (p[i] != magic)
exit(magic);
}
So yeah, a theorem prover could possibly figure this out. After all,
you and I did. :-)
Alternatively the two loops could be fused and and the calculation
could happen in registers without ever hitting main memory. This is
exactly valid when the contents of p[] are not accessed again after
clear_bytes().
Good point. That's even more likely than the theorem prover issue
above. I could write the fused code but I'm too lazy right now.
In order to guarantee that this works, you must pass in 0 as the
value of the 'magic' parameter, and you also must establish that 0
value using a method that is completely undecidable even to the most
intelligent compiler optimizer theoretically possible.
Why not use the value of a convenient system call, such as time(3)?
Because I need a way of generating a 0 in a way a compiler cannot
predict. If I said this:
int i = funky_system_call();
Then I need a way to map i into 0 under the compiler's radar. Well
these techniques certainly will NOT work:
char magic = i - i;
char magic = i ^ i;
... etc.
In all cases the compiler will know that magic == 0, and it can hack
and optimize everything away.
But as you said, that point is moot if the compiler fuses the loops.
It is impossible for a compiler to optimize away any of this code,
because you can always find a way from OUTSIDE the program to make
magic take on a nonzero value and thus reach the abort condition.
Unlikely maybe, not impossible.
True. Probably much more likely even that the va_list trick.
. and I see your second message has arrived
subscribe: send blank email to [EMAIL PROTECTED]
unsubscribe: send blank email to [EMAIL PROTECTED]
digest: send an email to [EMAIL PROTECTED]
with set [EMAIL PROTECTED] digest=on in the message body
Yes, I really did zeroize that key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have devised what I believe to be a foolproof and completely
portable way of setting an array of bytes to all zeroes, a common
security operation in cryptography programs.
void
clear_bytes(char magic, char p[], int n)
{
int i;
p[0] = magic;
for (i = 1; i n; i++)
p[i] = p[i-1];
for (i = 0; i n; i++)
if (p[i] != magic)
exit(magic);
}
In order to guarantee that this works, you must pass in 0 as the
value of the 'magic' parameter, and you also must establish that 0
value using a method that is completely undecidable even to the most
intelligent compiler optimizer theoretically possible.
Here is a simple example of how we can generate this undecidable
zero and pass it into the routine.
int
main(int argc, char *argv[])
{
char array[32];
char magic = (argc 1 ? 0 : 255);
clear_bytes(magic, array, sizeof(array));
return 0;
}
If you call this program with no command line arguments, the value of
magic will be 0 and the clear_bytes is guaranteed to zero out the
array.
If you call this program with any command line arguments at all, the
value of magic will be 255 and the clear_bytes routine will exit with
code 255. So the clear_bytes routine serves a dual purpose as an
assertion that the clearing operation actually occurs properly. If
it doesn't, your program aborts.
It is impossible for a compiler to optimize away any of this code,
because you can always find a way from OUTSIDE the program to make
magic take on a nonzero value and thus reach the abort condition.
Of course, your program will very likely expect command line
arguments, but you can use a slightly altered technique for
generating the necessary magic undecidable zero. For example, if
you know that your program will never be called with more than 5
arguments, just use this line:
char magic = (argc 6 ? 0 : 255);
In the very worst case the number of arguments to your program will
be totally indeterminate, with no theoretical upper bound. This
could easily happen if you expect file names with shell expansion,
for example. In this case, you could simply require that the very
first argument to your program must always be a specific character,
for example 't'.
char magic = ((argc 1 argv[1][0] == 't') ? 0 : 255);
With this line, if the first argument to the program starts with a
't', magic will take on the correct value of 0.
I do not recommend using anything in argv[0] because that is the
actual name of your program as invoked from the command line. This
could change if the executable file is renamed or if you call it with
a leading path.
You can always find some way to generate a magic undecidable zero.
Some variation of the argc/argv technique should serve you well in
all reasonable circumstances, but if you absolutely had to you could
read a zero byte out of a file somewhere.
Note that the clear_bytes function 'ands' each byte of the array with
the previous byte, starting with the magic value. Only a magic value
of 0 is guaranteed to make all the bytes zero. The second loop then
checks the operation, ensuring that each byte is equal to the magic
byte. This can only succeed if magic is 0 and all the bytes are 0.
(Actually it could succeed with a nonzero magic value, but only if
all the bytes were already equal to magic to begin with. Obviously
this case is irrelevant.)
So folks, this routine will definitely zero out an array, and it
doesn't rely on the va_list (vararg) technique described in
Welschenbach's book.
Personally I rarely use global variables, so I like to pass the magic
value around as an explicit parameter wherever it is needed. But you
could use a global magic variable if you preferred.
- -- Patrick
http://fexl.com
-BEGIN PGP SIGNATURE-
Version: PGP 8.0
iQA/AwUBPl7iz1A7g7bodUwLEQIxCwCgoBhwaXuP6Umjbcmx0aa0xeWsjZEAnRBy
bYZgDf+QHEcwmPLHo2ME+/ik
=zKvd
-END PGP SIGNATURE-
Wash the key, don't clear it
On Friday, February 28, 2003, at 01:03 AM, Jeroen C. van Gelderen wrote: On Friday, Feb 28, 2003, at 00:50 US/Eastern, Jeroen C. van Gelderen wrote: You are going trough a lot of trouble. What is your threat model? Incidentally, the correct and portable (modulo compiler bugs) approach at the language level is to mark the array volatile. This means that stores to the array cannot be optimized out and neither can function calls to functions in which a volatile variable is manipulated (this is transitive). Now see, I've known about volatile since about 1985. It's just that all these cryptography books make such a big show and hoopla about zeroing out memory. Even the GnuPG code does the 'burn_stack' thing, which was shown on the DBS list to be vulnerable. So I figured the volatile feature must be horribly unreliable. I guess I'll just have to check the assembler output from gcc to make sure. You will still have to disable caching and swapping at the OS (and maybe the hardware) level to make sure no copies linger around. Yes, I do intend to use mlock and munlock for that. As for my threat model, I'm just thinking I need to make it as reliable as possible even without a dedicated server. I only need the ability to lock, use, wash, and unlock a single memory page. Today is my day to spend a few hours on the washing part. :-) And in some cases (again, what is your threat model?), you will want to overwrite your data with random bytes because overwriting with zeroes makes offline forensics easier. This thought did cross my mind, and I considered running Rijndael itself to wash out the memory. In one implementation, I have written the three routines (keysched, encrypt, and decrypt) so they declare NO internal stack variables whatsoever. Any scratchpad memory must be declared outside and a pointer passed into the routine. So after doing my primary crypto operation using Rijndael, I would then wash out the key and key schedule memory using an application of Rijndael itself. I would perhaps seed this process occasionally and chain it. So do you think I should use Rijndael itself to wash out this data? Regards, Patrick
Washing sensitive data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday, February 28, 2003, at 01:03 AM, Jeroen C. van Gelderen wrote:
Incidentally, the correct and portable (modulo compiler bugs) approach
at the language level is to mark the array volatile. This means that
stores to the array cannot be optimized out and neither can function
calls to functions in which a volatile variable is manipulated (this
is transitive).
You will still have to disable caching and swapping at the OS (and
maybe the hardware) level to make sure no copies linger around. And in
some cases (again, what is your threat model?), you will want to
overwrite your data with random bytes because overwriting with zeroes
makes offline forensics easier.
OK, I am adopting 'volatile'. In the discussion on this topic a few
months back, someone pointed out that a solid compiler MUST implement
volatile correctly otherwise device drivers run the risk of producing
smoke and sparks from your computer. I assume gcc is a solid compiler.
Also, I initially allocate all a single locked page of working scratch
pad memory and pass it into my sensitive code. The sensitive code does
not declare ANYTHING sensitive on the stack.
Here we go. Assume these declarations:
typedef unsigned char t_byte;
typedef unsigned long t_word;
typedef volatile t_byte vt_byte;
We have this code:
void main(void) {
...
int pagesize = getpagesize();
vt_byte *page = malloc(pagesize);
if (page) {
if (mlock((caddr_t)page, pagesize) == 0) {
DO_SENSITIVE_STUFF(page);
munlock((caddr_t)page, pagesize);
}
free((void *)page);
}
}
Now, the routine to do all the sensitive stuff uses page for ALL its
working memory. It calls a routine 'wash_bytes' to wipe out whatever
it uses in the page.
I have decided that wash_bytes will use a simple and fast random number
generator to randomize the memory. I have already written a nice
implementation of the Mersenne Twister, so here is the relevant
laundromat code:
#include mersenne.h
static t_mersenne twister;
void set_wash_seed(t_word seed) {
mersenne_start(twister, seed);
}
void wash_bytes(vt_byte a[], int n) {
for (...) {
t_word w = mersenne_next(twister);
/* put the 4 bytes of w into the next 4 bytes of a[] */
}
}
Periodically my main program will call set_wash_seed with a fresh
simple word of entropy, but because the Mersenne Twister has such a
long period I'll probably let it ride for quite a while.
This should give any forensics cryptanalysts a bitch of time. I assume
the main danger of zero blocks is that it give them handy reference
points within the captured memory image. I doubt they'll be able to
recognize any MT sequences, especially if occasionally reseeded. :-)
This stuff is wacky!!!
- -- Patrick
http://fexl.com
-BEGIN PGP SIGNATURE-
Version: PGP 8.0
iQA/AwUBPl+eMlA7g7bodUwLEQLzqQCg4t58FsuuyjnHVBqPKIvnHdV/5OkAnRl1
pc8HVgL3dl8uKnB+CtqwfjSa
=hs2S
-END PGP SIGNATURE-
Re: Degenerate Political Pressure (was RE: The Wimps of War)
On Thursday, February 13, 2003, at 05:45 PM, R. A. Hettinga wrote: Heck, go read some Patrick O'Brien Jack Aubrey Books. The Royal Navy earned its own keep with prizes, etc., until long after the Napoleonic wars... Come to think of it, the rise of book-entry settlement cooincides nicely with the end of war for profit. How would you distinguish the actions of the Royal Navy from those of ordinary pirates? Just prettier uniforms, better weaponry, and a bitch back in London with a crown on her head, or what? -- Patrick http://fexl.com
RE: Did you *really* zeroize that key?
From: James A. Donald [EMAIL PROTECTED] ... If the optimizer ever optimizes away a write to volatile memory, device drivers will fail. Most device drivers are written in C. If anyone ever produces a C compiler in which volatile does not do what we want, not only are they out of spec, but smoke will start coming out of hardware when the device drivers are recompiled. Good point #1. Excellent point, in fact. From: Dave Howe [EMAIL PROTECTED] ... Yup, granted. however, saying after a security breach this wasn't my fault, the compiler was out of spec isn't going to help much. in the real world, murphys law applies more often than anyone elses; you can virtually guarantee you will meet up *sometime* with an out of spec compiler ... Good point #2. Excellent point, in fact. So, given 1 and 2, it sounds like a good strategy might be: a. Declare your sensitive variables volatile and zero them normally. b. Check the assembler output because you have to do that anyway :-) c. If (b) exposes an out-of-spec compiler, report it far and wide to all available e-mail lists. Then preferably use a different compiler. If that's not an option, try the va_list trick and go to (b). -- Patrick http://fexl.com
Re: Did you *really* zeroize that key?
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote:
On Fri, Nov 08, 2002 at 08:35:06AM -0500, Patrick Chkoreff wrote:
That's an interesting idea. You'd take the pointer returned by alloca and
pass it to memset. How could the optimizer possibly know that the pointer
With GCC, it's a builtin, so it will know.
Gotcha.
I was thinking the only way to really stymie the optimizer might be to
have
the program flow depend on something read from a file! You could have a
file with a single 0 word in it. At the beginning of your program, just
one time, you say this:
I'm afraid optimizations could remove this too. The point, if I understand
it correctly, is that operations on memory have, from the compiler's POV,
a zero lifetime, since the block is freed just afterwards. So, whether you
write zero or anything else there, this write can be discarded, since it's
not used afterwards. Dead write, kind of.
You got me thinking again, and I think you're right. Allow me to simulate
the optimizer's thinking.
Here's the original code:
if (!fool_opt) sensitive = 0;
if (!sensitive) die_horribly_because_this_should_never_happen();
Here is a logical equivalent:
if (fool_opt) {
if (!sensitive) die_horribly_because_this_should_never_happen();
} else {
sensitive = 0;
if (!sensitive) die_horribly_because_this_should_never_happen();
}
Now the compiler can optimize the else case as follows:
if (fool_opt) {
if (!sensitive) die_horribly_because_this_should_never_happen();
} else {
die_horribly_because_this_should_never_happen();
}
This is logically equivalent to:
if (!fool_opt || !sensitive)
die_horribly_because_this_should_never_happen();
So you're correct, the compiler can view the sensitive = 0 statement as a
dead write as you say.
DOH!!! :-o
So it sounds like Welschenbach's var-arg trick is still the best bet at
this point for a portable zeroize technique.
-- Patrick
http://fexl.com
Re: Did you *really* zeroize that key?
At 10:20 AM 11/8/2002 +, Vincent Penquerc'h wrote: On Thu, Nov 07, 2002 at 07:36:41PM -0500, Patrick Chkoreff wrote: Everybody probably also knows about the gnupg trick, where they define a recursive routine called burn_stack: [...] Then there's the vararg technique discussed in Michael Welschenbach's book Cryptography in C and C++: How about a simple alloca/memset ? Though it would possibly be more subject to `optimizations'. -- Vincent Penquerc'h That's an interesting idea. You'd take the pointer returned by alloca and pass it to memset. How could the optimizer possibly know that the pointer pointed right into the stack frame? For all the compiler knew, the pointer might point to some device block somewhere, so the compiler would not dare remove the memset. UNLESS the compiler knew about alloca and by data flow analysis could establish that the pointer still pointed to the stack frame at the time of the memset. So yeah, it might indeed be subject to optimizations. I was thinking the only way to really stymie the optimizer might be to have the program flow depend on something read from a file! You could have a file with a single 0 word in it. At the beginning of your program, just one time, you say this: unsigned int fool_opt; FILE *fp = fopen(); fread(fool_opt,sizeof(unsigned int),1,fp); The compiler has no idea there's a zero in fool_opt. Now when you want to zero-out a variable, you'd say something like this: unsigned int sensitive; sensitive = result_of_bizarre_encryption(); /* Now let's zero out the sensitive variable. */ if (!fool_opt) sensitive = 0; if (!sensitive) die_horribly_because_this_should_never_happen(); The die horribly routine would do something like this: fprintf(stderr,Yikes!\n); exit(255); I guarantee you, there is no way on earth an optimizer can get past that one!! -- Patrick http://fexl.com
Re: Did you *really* zeroize that key?
At 02:22 PM 11/8/2002 +, Vincent Penquerc'h wrote: while (!is_all_memory_zero(ptr)) zero_memory(ptr); Right, unfortunately the compiler might be insightful enough just to optimize that whole thing to skip() -- Dijkstra's null statement. Even Welschenbach calls ispurged immediately after purgevars to make sure the memory is actually zero. The ispurged routine is also defined using va_list, and if you turn on assertion checking it dies if the memory is nonzero. The problem is you NEVER KNOW if the compiler is just being clever and optimizing the assertion away, e.g.: sensitive = 0; if (sensitive) abort(); The compiler will simply know to optimize this whole thing to skip(). However, it is highly unlikely the compiler will be able to see through va_list manipulations. This problem is a real bear. I guess you just have to check the assembler output, eh? -- Patrick http://fexl.com
Re: Did you *really* zeroize that key?
From: Trei, Peter [EMAIL PROTECTED]
[Moderator's note: FYI: no pragma is needed. This is what C's
volatile keyword is for. Unfortunately, not everyone writing in C
knows the language. --Perry]
Thanks for the reminder about volatile. It is an ancient and valuable
feature of C and I suppose it's implemented correctly under gcc and some of
the Windoze compilers even with high optimization options like -O2.
From RISKS:
http://catless.ncl.ac.uk/Risks/22.35.html#subj6
Those of us who write code need to be reminded of this
now and then.
Everybody probably also knows about the gnupg trick, where they define a
recursive routine called burn_stack:
static void
burn_stack (int bytes)
{
char buf[64];
memset (buf, 0, sizeof buf);
bytes -= sizeof buf;
if (bytes 0)
burn_stack (bytes);
}
Then there's the vararg technique discussed in Michael Welschenbach's book
Cryptography in C and C++:
static void purgevars_l (int noofvars, ...)
{
va_list ap;
size_t size;
va_start (ap, noofvars);
for (; noofvars 0; --noofvars)
{
switch (size = va_arg (ap, size_t))
{
case 1: *va_arg (ap, char *) = 0;
break;
case 2: *va_arg (ap, short *) = 0;
break;
case 4: *va_arg (ap, long *) = 0;
break;
default:
memset (va_arg(ap, char *), 0, size);
}
}
va_end (ap);
}
Here's an example of how you might call the routine:
purgevars_l(2, sizeof (la), la,
sizeof (lb), lb);
But hey, if volatile keyword works then so much the better. I would
recommend examining the assembly language output of your compiler to verify
that it honours volatile.
-- Patrick
http://fexl.com
Re: Did you *really* zeroize that key?
From: Trei, Peter [EMAIL PROTECTED] [Moderator's note: FYI: no pragma is needed. This is what C's volatile keyword is for. Unfortunately, not everyone writing in C knows the language. --Perry] Thanks for the reminder about volatile. It is an ancient and valuable feature of C and I suppose it's implemented correctly under gcc and some of the Windoze compilers even with high optimization options like -O2. Oops, I missed your real point, which is that volatile ought to suffice as a compiler guide and there is no need for an additional pragma. By declaring a variable as volatile, the compiler would also leave untouched any code which refers to that variable. Too bad that volatile is not guaranteed to work in all major ANSI-compliant compilers. Oh well. I wonder how gcc does with it? I guess we should stick with either the recursive routine trick or the var-arg trick. -- Patrick http://fexl.com
Re: [OT] why was private gold ownership made illegal in the US?
Roosevelt needed to in effect devalue the dollar during the Great Depression. However doing a straight devaluation was politically unacceptable at the time. Because the dollar was pegged to gold, devaluing the dollar meant in effect increasing the value of gold in terms of dollars. Roosevelt did devalue the dollar. On January 31, 1934, he issued an Executive Order which devalued the dollar from 23.22 grains of gold down to 13.71 grains. That was a 59% devaluation. As you say, devaluing the dollar did increase the value of gold in terms of dollars. The value of gold in terms of dollars jumped from $20.67 to $35.00, an increase of 69%. Roosevelt did not have the advantage of modern economics and he made many economic mistakes which prolonged the depression, but devaluing the dollar was not one of them. Yeah, good thing Roosevelt didn't make the mistake of devaluing the dollar! Whew! :-) Americans could be living in a People's Republic today. Confiscating gold was clearly the lesser of the evils. Yes, the only way to avoid communism was to devalue the dollar and make possession of a yellow metal punishable by fine and imprisonment. Anybody can see that. :-) Seriously though, we didn't avoid communism at all. FDR was our first communist president. -- Patrick P.S. http://www.strike-the-root.com/columns/Chkoreff/chkoreff1.html
