I'm not sure cross posting to these two lists is appropriate for
this question, but here are some alternatives you can use.
1)OpenPGP defines the packet length in the header of the packet.
This is done with a scheme based on it being an old or new packet followed
by a set of bytes which encode a byte count for the packet body. Since it
uses a modified CFB technique, padding is not an issue. This is a fairly
effective method.
2)You can encode it using ASN.1 Octet string to encode the
message. The ASN.1 encoding will have a length encoded in the first few
bytes, like OpenPGP. If you need multiple encodings then you put them in
a sequence encoding. This technique probably has the most code to support
it (in both crypto++ and openssl). Some sort of padding may be required,
but the encoded length can define where it starts.
3)You can have a pre defined end packet. This is of limited use
and should really only be used to determine the padding to remove (if you
are using a block cipher in a block mode). PKCS 5 describes one method
you can choose (section 6.2) that is commonly used. It basically
consists of repeating the number of octets that are padding. Here is an
excerpt from the document.
6.2 Encryption-block formatting
The message M and a padding string PS shall be formatted
into an octet string EB, the encryption block.
EB = M || PS . (1)
The padding string PS shall consist of 8 - (||M|| mod 8)
octets all having value 8 - (||M|| mod 8). (This makes the
length of the encryption block EB a multiple of eight
octets.) In other words, the encryption block EB satisfies
one of the following statements:
EB = M || 01 -- if ||M|| mod 8 = 7 ;
EB = M || 02 02 -- if ||M|| mod 8 = 6 ;
.
.
.
EB = M || 08 08 08 08 08 08 08 08 -- if ||M|| mod 8 = 0 .
Note. The encryption block can be parsed unambiguously since
every encryption block ends with a padding string and no
padding string is a suffix of another.
Hope this helps.
73,
Shawn
On Fri, 8 Mar 2002, Mads Rasmussen wrote:
>
> Hi,
>
> This might be a stupid question, but it keeps troubling my mind.
>
> I was thinking, when encrypting a string ( with symmetric cipher) you
> would want to enter some information about the length of the original
> string.
> Does anyone know a standard for this? I mean I might choose to do it one
> way and send my message to Alice but how is Alice supposed to know how
> to recover the message fully? How will she know when the message stops
> and padding begins.
> If the message is text you could argue that the message has to make
> sense, but when dealing with binary data how would you know?
>
> Then I would like to know if there is some standard that talk about
> padding messages for symmetric encryption and where I need to store the
> size of the original data.
> What we do here is to reserve bytes in the beginning of the ciphertext
> about length of the message and its padding but I would like to hear
> other opinions.
>
> What is common practice?"
>
> Regards,
>
> Mads Rasmussen
> Open Communication Security
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
