On Mon May 2 2011, derleader mail wrote:
> >> > I'm going to use stream protocol - TCP/IP. Here is the
> >> template source
> >> > code of the server without the encryption part
> >>
> >> We mean application protocol.
> >>
> >> > while (1) {
> >> > sock = accept(listensock, NULL, NULL);
> >> > printf("client connected to child thread %i with pid %i.\n",
> >> > pthread_self(), getpid());
> >
> >pthread_t and pid_t are not required to be int and sometimes aren't.
> >I don't think they're even required to be any integers.
> >
> >> > nread = recv(sock, buffer, 25, 0);
> >> > buffer[nread] = '\0';
> >
> >Where buffer is char[25]. If the client always sends 25 bytes
> >(or more) this will write outside the space allocated for buffer[].
> >This is undefined behavior in C and the program can fail arbitrarily.
> >On today's systems usually this will 'accidentally' work,
> >but you have no confidence of that in the future.
> >Either make maximum read at least one byte smaller than buffer,
> >or buffer at least one byte larger than maximum read.
> >
> >Also, recv() returns -1 if error; storing to buffer[-1]
> >is also undefined and more likely to actually screw up.
> >
> >For that matter, accept() can fail and return not a valid socket,
> >in which case the recv() and send() can't succeed.
> >
> >> > printf("%s\n", buffer);
> >
> >If this is the only reason you wanted null termination,
> >you could do printf("%.*s\n",nread,buffer) instead.
> >
> >> > send(sock, buffer, nread, 0);
> >> > close(sock);
> >> > printf("client disconnected from child thread %i with pid %i.\n",
> >> > pthread_self(), getpid());
> >> > }
> >> > }
> >>
> >> This code isn't very helpful. It just reads and writes the very same
> >> data. Nothing in this code tells us, for example, how to identify a
> >> complete message.
> >>
> >Unless the messages are fixed-length 25 bytes. I've seen crazier.
> >
> >> You could interpose an encryption protocol that also imposed no such
> >> requirements. You would need to work out your own padding though.
> >> Blowfish is a block encryption algorithm and cannot encrypt just a
> >> single byte. So if you only read one byte, you'd need to pad
> >> it before
> >> encryption and then you'd need some way to remove the padding on the
> >> other end.
> >>
> >Not quite; OP's earlier code had Blowfish *CFB*,
> >a stream mode that can handle any number of bytes.
> >(The mode itself can handle any number of bits, but
> >the OpenSSL API doesn't handle sub-byte amounts.)
> >
> >However a stream mode is generally more vulnerable to
> >bit-flipping unless authenticated, which the OP didn't.
> >
> >Also his 'test' had a fixed IV (and key),
> >but maybe that was only a test.
> >
> >> I would strongly urge you to just use SSL. It is designed for
> >> *exactly*
> >> this purpose.
> >>
> >Agree there.
> >
> >Also it should be noted session caching only helps
> >if both ends support (and allow) it; it is optional.
> >If you write both programs and use OpenSSL, it's easy,
> >but in some other situations it might not be.
>
>
> One more question:
>
> If I decide to go with openssl and blowfish what are the potential threats?
> Is there another security mechanism that I can use with blowfish?
>
???
What does the output of:
'openssl enc ?'
have to say to you?
Mine says that openssl does do Blowfish.
???
I thought you wrote that you wanted performance?
Why then Blowfish instead of one of the encryptions supported in hardware?
VIA processors do AES in hardware (and OpenSSL has an engine for it).
Another poster mentioned that new Intel processors also do hardware AES.
What does your project specification require that makes you choose Blowfish
in software over something else in hardware?
Mike
> Regards
> Peter
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
