[Owasp-esapi-c++] Encryptor.h

Kevin W. Wall kevin.w.wall at gmail.com
Wed Aug 3 16:45:29 EDT 2011


On Wed, Aug 3, 2011 at 2:40 PM, Jeffrey Walton <noloader at gmail.com> wrote:
[Snip]
>> // Or should we use
>> //      #pragma once
>> // instead of "#include guards"?
> All compilers consume `#include <foo>`. Modern compilers support the
> pragma. GCC was the hold up for pragmas because Stallman objected to
> the inability to include in preprocessor macros. GCC now has _Pragma,
> so Stallman is happy.
>
> `#pragam once` handles links correctly, `#include <foo>` does not (or
> might not).

I propose we go w/       #pragma once
then. Its not like we couldn't write a simple script to change them
all back to using #include guards should we run across some
important compiler that doesn't support them. In the meantime,
it's a lot less error prone (or am I the only one whose copied-and-pasted
an #include guard and forgot to change the name of the guard? ;-)

>> namespace esapi {   // Preferred over the longer org::owasp::esapi
> Yes, I like the flatter namespace.
>

Me too. Also easy to change should we decide later. I propose
we just use               'namespace esapi'.

Any objections???

>> virtual std::string hash(std::string plaintext, std::string salt, count_t iterations)
> Perhaps const std:;string& would be more efficient.

Good catch. I missed that one.

>> hash(std::string plaintext, std::string salt) and
>> hash(std::string plaintext, std::string salt, count_t iterations)
> I believe these can be folded if you provide a default for `iterations`:
>   hash(std::string plaintext, std::string salt, count_t iterations = 1)

As long as the default count is 4096 or whatever we are using,
I'm OK w/ that. It needs to be compatible w/ the Java version.
But it's definitely not 1.

>> Lastly, as far as implementation goes, at least for Encryptor, I am planning
>> on ditching the implementation as a singleton.
> Good idea - otherwise, you need to provide locks.

Blech! I hate locks. Proper design is the best way to address thread
safety issues; i.e., avoid it in the first place.

-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the Owasp-esapi-c++ mailing list