David LeBlanc's Web Log - All Comments

re: Compilers, Integers and Optimizations

Pascal Cuoq — Sat, 24 Dec 2011 16:31:38 GMT

> (int)(~(unsigned int)x + 1)

> This does the right thing, and forces the compiler to do the right thing,

> because now everything is defined by the standard.

Almost. The cast to int is implementation-defined, not defined by the standard. Everything else in the expression is defined by the standard.

[dcl] Well, yes, but that's only because the representation of negative numbers is a matter of choice, and I've already established that this only works for two's complement. The number of bits used for the int are also implementation-defined, but that doesn't matter to the expression.

re: Compilers, Integers and Optimizations

Ben Craig — Fri, 23 Dec 2011 21:24:36 GMT

Sometimes I wonder if it would be easier to just use inline assembly for some of SafeInt. You could then leverage the "JC" (Jump if Carry) instruction, and possibly avoid a ton of compiler woes.

Of course, I haven't tried it myself, and I you would still need a bunch of C++ code to deal with mixed types.

[dcl] We tired that, and as soon as you start inlining assembly, the compiler figures you know what you're doing, and quits optimizing. Turns out the compiler is smarter than we are, and perf was horrible. You also end up non-portable.

What I'd like is for the compilers to give me intrinsics for more of this. I was able to use intrinsics for the 64-bit multiplication, and it resulted in much smaller code. Or over the very, very long haul, it would be great if the processors had instructions for some of this, but at the moment, I see more different processors and compilers in use for most of us, so portability wins.

re: More on Checking Allocations

Yuhong Bao — Thu, 07 Jul 2011 00:00:09 GMT

Don't forget this:

support.microsoft.com/.../284893

re: MS-Offcrypto Examples

Daniel — Thu, 19 May 2011 14:32:27 GMT

For Standard Encryption, this is great but would you consider creating a sample project to illustrate Agile Encryption?

[dcl] - Yes, I should do that

re: Don’t Forget the Document Password!

AlexKr — Tue, 22 Mar 2011 10:04:54 GMT

Hi David,

Unfortunately AES security does not really help if you consider distributed approach.

For example, http://passwordnow.com offers their cluster to recover even office 2007-2010 documents.

It works in the following way.

Let's say the average PC gets 100 passwords per second. Then you get 1000 cores working together, thats 100K passwords per second.

Assuming most of the users are NOT using strong passwords the brute force search will eventually uncover most of the data.

So it is really a job for a user to use the correct passwords.

I would even say it is mandatory to have such education about choosing correct passwords.

Best wishes,

Alex

[dcl] Sure it helps - let's look at the math. An iterated hash can drop your cracks/second by anywhere from 5-6 orders of magnitude. A cluster of 1000 systems only gains you 3 orders of magnitude. The password is still effectively 100x stronger using a well-build KDF than not. This will obviously not save you if the password is poorly chosen, but it takes a 3-day password crack out to 300 days. Most people give up long before that, and aren't willing to throw 3 million computer-days at the problem.

And to be clear, it isn't AES that saves you - AES does nearly nothing here. It's the key derivation function that's important.

re: Office 2007 SP2 Encryption Settings

David — Wed, 05 Jan 2011 15:50:03 GMT

Does Office 2007 encryption protect embedded objects? This PC World article (www.pcworld.com/.../encryption_does_not_protect_oleembedded_files.html) indicated that back in 1997 Office's encryption did NOT protect embedded files. Has this been changed?

Put differently: If I embed a PDF or an Excel worksheet in a Word 2007 .docx and then encrypt the .docx, is the embedded file also protected?

[dcl] Yes - if you're encrypting a docx, or any other OOXML file, embedded objects are protected.

re: Office Crypto Follies

Yuhong Bao — Thu, 21 Oct 2010 04:35:48 GMT

"Sadly, most of the implementation flaws remained. I found one place where there was triple key stream re-use (though only for 8 bytes) in the same spot."

Worse. If you read MS-DOC or MS-XLS, each stream is encrypted with a block number starting at zero *for each stream*. If you read MS-OFFCRYPTO, you will read there is no place where the name of the stream is mixed into the key. This means *each stream* is encrypted with the *same* set of keys.

[dcl] yes, this is why I say to just not use the RC4 encryption. Upgrade the file to a new format, and get good encryption. Or use something else.

re: Don’t Use Office RC4 Encryption. Really. Just don’t do it.

Yuhong Bao — Fri, 01 Oct 2010 05:49:31 GMT

Could Office be updated to use different RC4 keystreams on each save without breaking the file format?

I think it is likely.

[dcl] No - we looked at that, and the problem, as always, is backward compatibility. If all you use is the CAPI 128-bit RC4, then things get better, but are still not great.

re: Another technique for Fixing DLL Preloading attacks

janglin — Wed, 25 Aug 2010 14:18:02 GMT

Is this how you would use SetDllDirectory?

typedef BOOL (WINAPI *PSDLLD)(__in_opt LPCWSTR);

HMODULE SafeLoadLibrary_1(const wchar_t* wzFileName)

{

HMODULE hMod = NULL;

static PSDLLD pSetDllDirectory = NULL;

if (NULL == pSetDllDirectory)

{

pSetDllDirectory = (PSDLLD)GetProcAddress(GetModuleHandleW(L"kernel32.dll"),

"SetDllDirectoryW");

}

if (NULL != pSetDllDirectory)

{

if (pSetDllDirectory(L"")) // remove '.' from search order

{

hMod = LoadLibrary(wzFileName);

pSetDllDirectory(NULL); // restore default search order

}

return hMod;

}

[dcl] Well, you could. Unless you're supporting Windows 2000 or XP gold, you can skip getting the proc address of SetDllDirectory. The problem with this is that it is process-wide and not thread safe. What I'd really recommend instead is just call SetDllDirectory("") as the first thing you do in main() or WinMain(), and just run like that.

If you have problems with doing that, and sometimes need the option of using the CWD, then you can't do that, and need to take some other approach, like the example.

re: Another technique for Fixing DLL Preloading attacks

asf — Tue, 24 Aug 2010 12:28:11 GMT

static wchar_t wzSystem[MAX_PATH]={0}; ?

[dcl] The language standard says that all globals and statics get initialized, and failing a constructor, they get initialized to zero.

Also, MAX_PATH limit is evil

[dcl] Not really. Try installing Windows into a directory that won't fit in MAX_PATH, and my prediction is that it won't go well. You could potentially have issues with the CWD, and if you're worried about it, write the code to fall back and allocate the buffer. While this is fairly close to production quality, it is sample code, and could use more error checking and one might want to make it more robust.