Re: Cross platform password string encryption

Wow, I've been away for nearly a week and I've come back to a bunch of
posts on the matter. Thanks for all the helpful and constructive
responses.
I happen to have solved it now, I ended up using the Delphi LockBox
implementation of 3DES and found on CodeProject an implementation that
was compatable with it for C#.

I just want to make a few comments as well.
Google has been helpful and I did find a whole host of blowfish and
other implementations, unfortunately non seemed to be cross platform
compatible between desktop pc and windows mobile. I also struggled and
didn't particularly have time to understand the IV concept and really
just wanted something fairly quick and out of the box to just work with
a key.

Also to those "posters" suggesting I use other languages, if I could I
would have. I know a few languages very well, and can obviously fairly
quickly pick up others. It is fairly pointless to suggest that I use
other languages when I am being specific in my need for solutions
between these two, don't you think?
FYI, I am using Delphi on the PC as it is a large program that has
already been produced by software engineers past, and I am just
updating it, not least to say that it is a very good language to use
and certainly the forerunner for all MS's .NET stuff (which one of the
orginal Delphi programmers went over to MS to help create).
I am using C# as there is a RAD need for a Pocket PC equivalent of the
PC program. Doing this in older embedded Visual C++ or some other
alternative would just hold things up.

C may be "better", faster and closer to the hardware, but I couldn't
really care less as I am not working close to the hardware I am working
at an application level. People can scoff at Delphi/Pascal, .NET, Java,
all they like the fact is that they are easier and quicker to use at
higher levels and produce results quicker at these levels. Perhaps they
aren't as fast when executing but with computers as quick as they are
these days who really cares other than specialists for specialist
needs?

Sorry for the rant but I found some of the cynicism irritating!

Thanks,
Zief


henrick@xxxxxxxxxxxx wrote:

Tom St Denis wrote:
Zief wrote:
I am currently searching for implementations of any of the free to use
encryption algorithms that will work on Delphi 7 on Windows and on the
Pocket PC using C# .NET Compact Framework, to encrypt and decrypt
strings.

Use C?

Despite the random poster, few people use Delphi or C# compared to C
and C++ which is why it's harder to find stuff for it.

Aren't you the one who keeps insisting that Google is your friend? I
had no problem finding half a dozen Pascal/Delphi implementations of
Blowfish in no time. <g>

The one in here is mine and tested against the test vectors:
http://sourceforge.net/projects/openstrsecii.

On a serious note, though, IME using an implementation written in C is
really only an advantage if it makes you able to use the same code on
both platform targets and if the implementation has been tested on both
platform targets. Otherwise it *really* doesn't matter which language
is used, because there are a number of potential problems that are far
more likely to be a concern:

1. The algorithm implementations are not compatible. E.g. one complies
with the test vectors and the other one doesn't, or one doesn't comply
with the test vectors on the platform target it is used for.

2. The consuming code doesn't use the library code in the right way.
E.g.
2.a. The key schedule routine is skipped and the developer is passing
a raw key directly to the encrypt routine.
2.b The IV is ignored and the two implementations handle that
differently (e.g. one is using a string of zero octets while the other
one generates one at random and prepends it to the cipher text and
presumes the encryptor did the same if used for decryption).

3. Either implementation might have options to use a KDF for processing
key data before passing it to the standard key schedule.

4. Either implementation might have options to use padding, which might
do anything from just appending PKCS last block padding to calculating
a MAC and putting the ciphertext in a packet for SSH transport.

5. The consuming code is trying to pass strings to the routines and
doesn't take proper care to ensure the format is correct. E.g. UTF16LE
Unicode strings are used on .NET, while Delphi Win32 defaults to Ansi 8
bit strings. Similar problems might occur if either implementation
expects the key, the IV or the cipher text to have some transport
encoding such as Base64 or hexadecimal.

Etc. I could go on for quite a while, but you get the point.

.

Relevant Pages

  • Re: 64-bit Windows for AMD 64 is here...
    ... and the same went for Delphi vs. VS/win32. ... Delphi has quite a few features other languages don't have. ... But Delphi ports to .NET are a lot ... >> strings or StringBuilders. ...
    (borland.public.delphi.non-technical)
  • Re: Cross platform password string encryption
    ... few people use Delphi or C# compared to C ... The consuming code doesn't use the library code in the right way. ... a raw key directly to the encrypt routine. ... The consuming code is trying to pass strings to the routines and ...
    (sci.crypt)
  • Re: Pascal Server Page
    ... this is a Delphi forum, ... assume everybody here prefers Delphi over other languages, ... but PHP is better suited for web ... PHP supports varaiable interpolation in strings which makes ...
    (borland.public.delphi.non-technical)
  • Re: Noun Oriented Thinking Considered Harmful
    ... I like Delphi because it doesn't force me to use classes or interfaces to ... Object Pascal and entirely object-oriented languages like Java and C#. ... again need one or more diagrams - UML diagrams showing inheritance trees, ... programming paradigm introduced in Pascal and perfected in languages like ...
    (borland.public.delphi.non-technical)
  • Re: Delph Superior to New D Language
    ... There is nothing wrong with discussing other languages, seeing improvements ... and comparing them to Delphi. ...
    (borland.public.delphi.non-technical)