OpenSSL to sign & encrypt a binary file? - SCO

This is a discussion on OpenSSL to sign & encrypt a binary file? - SCO ; Hi everybody. I know this is not an OpenSSL devoted group but given the experienced guys hanging around, I though this would be one of the best place to ask. If not, please accept my apologies and skip this message. ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: OpenSSL to sign & encrypt a binary file?

  1. OpenSSL to sign & encrypt a binary file?

    Hi everybody.

    I know this is not an OpenSSL devoted group but given the experienced
    guys hanging around, I though this would be one of the best place to ask.

    If not, please accept my apologies and skip this message.

    Under SCO OS 5.0.7 I need to sign & encrypt mail messages from the
    command line.

    While I found it's relatively easy to sign & encrypt an plain text
    message, I did not find a way to do the same for binary attachs.

    As an example, the following sign & encrypts a text file using rzini's
    cert and key:

    openssl smime -sign -in text.txt -signer rzini.pem -inkey rzini.key \
    -text | openssl smime -encrypt -from r.zini@strhold.it \
    -to r.zini@strhold.it -subject "Test mail ENC" \
    -des3 rzini.pem | sendmail r.zini@strhuld.it

    The above works just fine but what about signing and encrypting a binary
    file such as /tmp/file.tar.gz?

    I've tried with several combinations of OpenSSL smime but unsuccessfully.

    Just to complicate the scenario a little bit, what about signing and
    encrypting a message composed of 2 parts:

    .. a text message (such as "Here's your encrypted file")
    .. a binary file (such as the above /tmp/file.tar.gz file)

    A browsed the 'Net but I've only found a comment who said that you must
    be a mail wizard to do the above from the command line (without using
    external MUA I mean).

    At the minute, I can't use pine or mutt since the customer does not want
    to add anything to the base OS; mail/mailx (the one included in the base
    OS) is allowed though.

    Thanks,
    Rob
    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  2. Re: OpenSSL to sign & encrypt a binary file?



    Ciao Roberto,

    First some basic information to make sure that we are talking about
    the same things.

    * An email message as transmitted on the wire by SMTP (sendmail) is
    simply one long string of 7-bit ASCII characters. Sendmail does not
    understand anything about the contents of the message, including
    whether or not it is encoded using MIME, whether there are attachments
    or whether you are intending to send a binary file.

    * The fact that 7-bit ASCII is used by SMTP means that almost all
    "real" mail messages (and especially those that contain binary
    attachments or non-ASCII characters) *must* be encoded in some way.
    The most popular mechanism for doing so right now is MIME.

    * The concept of "attachments" is implemented by MIME. That is, the
    sending MUA and the recieving MUA must understand MIME for attachments
    to work correctly. Again, sendmail treats the (MIME encoded) message
    as a simple 7-bit ASCII string.

    * The different "parts" of a MIME message (e.g. the text message and a
    binary attachment) are separated from each other by a boundary
    marker. The boundary marker is created by the sending MUA and is
    defined in the (SMTP compliant) header of the MIME message so that the
    receiving MUA can split the message correctly.

    * S/MIME is a variation of MIME that has (SMTP compliant) headers that
    mean the receiving MUA can determine how to handle the incoming
    message.

    * Like MIME, S/MIME requires that both the sending and the receiving
    MUAs understand the encoding scheme. To re-iterate, sendmail does not
    care about the contents of the message, except that it is a 7-bit
    ASCII string.

    * When using OpenSSL with the smime parameter, all the correct SMTP
    mail headers for the signature and encryption are added
    automatically. OpenSSL also provides options for adding other SMTP
    headers such as the address of the receiver, the sender and the
    subject (-to, -from, -subject)

    So... the command line you are using first signs the message, adding
    some SMTP headers (whether or not you use -text) and creates a
    multipart MIME message (the message and the signature), this message
    is then encrypted (including the headers and all the MIME
    information), some SMTP headers as well as the To: From: and Subject:
    are then added and this is then passed to sendmail for delivery to the
    recipient.

    *If* the receiving MUA understands S/MIME
    *and* the receiving MUA has access to the private certificate that
    matches the public certificate used to encrypt the message
    *then* the receiving MUA will be able to correctly decrypt and decode
    the message.

    Since there is nothing fundamentally wrong with your command line, the
    first question therefore is, what MUA is the recipient using, and does
    it support S/MIME?

    As far as a multipart S/MIME encoded message is concerned, this is (as
    you have heard) not as easy as it might be. But it is not
    impossible. First, you need to create your normal (unsigned,
    unencrypted) multipart MIME encoded message. Then sign and encrypt
    the entire message using the same command line as you are using now.
    (MIME encoded messages can be nested).

    A multipart MIME encoded message with a single text message and a
    small binary attachment looks as follows:

    Content-type: multipart/mixed; boundary="rzini-boundary"
    MIME-version: 1.0

    This is a multi-part message in MIME format.
    --rzini-boundary
    Content-type: text/plain

    This is the body of the message.
    --rzini-boundary
    Content-type: application/octet-stream
    Content-transfer-encoding: base64

    PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogIC AgPHA
    +VGhpcyBpcyB0aGUg
    Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2 h0bWw+Cg==
    --rzini-boundary--

    The most important point is that the boundary string ("rzini-boundary"
    above) must not occur anywhere else in the document. Generally, MUAs
    generate large random strings to use as the boundary to ensure that
    this is the case.

    Any text between the MIME-version number and the first boundary is
    ignored by MIME clients (old, non-MIME, clients will display this
    text).

    You will of course also need a way to generate a base64 octet stream
    from your binary file. Fortunately, OpenSSL can also do simple
    encodings and so:

    openssl enc -a -in

    will generate (to standard output) a base64 encoding of the file.

    I hope this helps. Let me know if you need any further information.

    Regards

    Mike Moore


  3. Re: OpenSSL to sign & encrypt a binary file?

    mike@moore.gb.com wrote:
    >
    > Ciao Roberto,
    >
    > First some basic information to make sure that we are talking about
    > the same things.
    >
    > * An email message as transmitted on the wire by SMTP (sendmail) is
    > simply one long string of 7-bit ASCII characters. Sendmail does not
    > understand anything about the contents of the message, including
    > whether or not it is encoded using MIME, whether there are attachments
    > or whether you are intending to send a binary file.
    >
    > * The fact that 7-bit ASCII is used by SMTP means that almost all
    > "real" mail messages (and especially those that contain binary
    > attachments or non-ASCII characters) *must* be encoded in some way.
    > The most popular mechanism for doing so right now is MIME.
    >
    > * The concept of "attachments" is implemented by MIME. That is, the
    > sending MUA and the recieving MUA must understand MIME for attachments
    > to work correctly. Again, sendmail treats the (MIME encoded) message
    > as a simple 7-bit ASCII string.
    >
    > * The different "parts" of a MIME message (e.g. the text message and a
    > binary attachment) are separated from each other by a boundary
    > marker. The boundary marker is created by the sending MUA and is
    > defined in the (SMTP compliant) header of the MIME message so that the
    > receiving MUA can split the message correctly.
    >
    > * S/MIME is a variation of MIME that has (SMTP compliant) headers that
    > mean the receiving MUA can determine how to handle the incoming
    > message.
    >
    > * Like MIME, S/MIME requires that both the sending and the receiving
    > MUAs understand the encoding scheme. To re-iterate, sendmail does not
    > care about the contents of the message, except that it is a 7-bit
    > ASCII string.
    >
    > * When using OpenSSL with the smime parameter, all the correct SMTP
    > mail headers for the signature and encryption are added
    > automatically. OpenSSL also provides options for adding other SMTP
    > headers such as the address of the receiver, the sender and the
    > subject (-to, -from, -subject)
    >
    > So... the command line you are using first signs the message, adding
    > some SMTP headers (whether or not you use -text) and creates a
    > multipart MIME message (the message and the signature), this message
    > is then encrypted (including the headers and all the MIME
    > information), some SMTP headers as well as the To: From: and Subject:
    > are then added and this is then passed to sendmail for delivery to the
    > recipient.
    >
    > *If* the receiving MUA understands S/MIME
    > *and* the receiving MUA has access to the private certificate that
    > matches the public certificate used to encrypt the message
    > *then* the receiving MUA will be able to correctly decrypt and decode
    > the message.
    >
    > Since there is nothing fundamentally wrong with your command line, the
    > first question therefore is, what MUA is the recipient using, and does
    > it support S/MIME?
    >
    > As far as a multipart S/MIME encoded message is concerned, this is (as
    > you have heard) not as easy as it might be. But it is not
    > impossible. First, you need to create your normal (unsigned,
    > unencrypted) multipart MIME encoded message. Then sign and encrypt
    > the entire message using the same command line as you are using now.
    > (MIME encoded messages can be nested).
    >
    > A multipart MIME encoded message with a single text message and a
    > small binary attachment looks as follows:
    >
    > Content-type: multipart/mixed; boundary="rzini-boundary"
    > MIME-version: 1.0
    >
    > This is a multi-part message in MIME format.
    > --rzini-boundary
    > Content-type: text/plain
    >
    > This is the body of the message.
    > --rzini-boundary
    > Content-type: application/octet-stream
    > Content-transfer-encoding: base64
    >
    > PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogIC AgPHA
    > +VGhpcyBpcyB0aGUg
    > Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2 h0bWw+Cg==
    > --rzini-boundary--
    >
    > The most important point is that the boundary string ("rzini-boundary"
    > above) must not occur anywhere else in the document. Generally, MUAs
    > generate large random strings to use as the boundary to ensure that
    > this is the case.
    >
    > Any text between the MIME-version number and the first boundary is
    > ignored by MIME clients (old, non-MIME, clients will display this
    > text).
    >
    > You will of course also need a way to generate a base64 octet stream
    > from your binary file. Fortunately, OpenSSL can also do simple
    > encodings and so:
    >
    > openssl enc -a -in
    >
    > will generate (to standard output) a base64 encoding of the file.
    >
    > I hope this helps. Let me know if you need any further information.
    >
    > Regards
    >
    > Mike Moore
    >


    Ciao Mike.

    Thanks again for your feedback.

    As discussed in a private email, you gave me a good starting point to
    solve the above myself.

    Basically, the idea is to nest different MIME headers into a single
    message, sing it with OpenSSL's "sign" and then encrypt it using
    OpenSSL's "encrypt" module.

    I've just scripted it into a file just to ease things a bit.

    Thanks,
    Rob

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

+ Reply to Thread