1) 送信側と受信側の処理は、以下のようになります。

送信側（アリス）

(1) メッセージダイジェスト関数を使って本文のダイジェストを作成します。
(2) プライベート鍵をキーとしてダイジェストを公開鍵暗号方式で変換します。　→　署名データの作成
(3) 本文と署名データ((2) の結果)をメールで送ります。

受信側（ボブ）

(4) 発信者と同様に、メッセージダイジェスト関数を使って本文のダイジェストを作成します。
(5) 署名データを発信者の公開鍵をキーとして公開鍵暗号方式で復号します。その結果、発信者の作った、ダイジェストを得ます。
(6) (4) と (5) の結果を比較して、同一であれば、発信が作成したメッセージであることが保証されます。

　

2) ディジタル署名のついたメールメッセージの中身

ディジタル署名をつけた、メッセージは下表のような形式になっています。

署名者を識別するデータがあるので、そこに示された証明書発行者名とシリアル番号から、署名者の証明書が明らかになり、その証明書に含まれる、公開鍵によって、署名を検証します。

3) 証明書の添付

署名者の証明書は、受信した側で既に持っていることも考えられるので、通信量を減らすなどの目的で証明書が添付されていない場合もあります。
Microsoft Outlook Expressでは、「署名付きメッセージにデジタルIDを追加する」をチェックすると証明書を添付し、チェックをはずすと証明書を添付しません。
Netscape Messengerでは、常に証明書を添付しています。
Oangesoft Winbiff+S/Goma では、「証明書を添付する」をチェックすると証明書を添付し、チェックをはずすと証明書を添付しません。

4) 平文のエンコード

電子署名には、上表のようなメッセージ本文を平文のまま送る形式とBASE64とよばれる、コード化をする形式があります。BASE64でコード化された場合、平文は一目では明らかになりませんが、元に戻すための決まった方法があるので、ユーザが意識することなく、メールソフトなどが自動的に元に戻して、平文が確認できます。
Microsoft Outlook Expressでは「署名する前にメッセージをエンコードする」をチェックするとこの形式になります。
Netscape Messengerでは、この形式は選択できません。
Oangesoft Winbiff+S/Gomaでは「分離署名(クリア電子署名)」のチェックを外すとこの形式になります。

1) 送信側と受信側の処理は、以下のようになります。

送信側

(1) ディジタル署名をします。
(2) ディジタル署名のついたメッセージを入力として暗号化します。

受信側

(3) 受信したメッセージを復号して、ディジタル署名されたメッセ−ジを得ます。
(4) ディジタル署名を検証します。

2) ディジタル署名と暗号化を組み合わせる2つの方法

暗号化とディジタル署名をひとつのメッセージに対して行う場合、2通りの方法が考えられます。

(1) ディジタル署名したデータを入力として暗号化をする（Sign-Then-Envelop）
受信側では、暗号文を復号し、電子署名されたデータを得る。その後、ディジタル署名の検証を行います。
1)ではこの方法について説明しています。S/MIMEではこの方法が使われます。

(2) 電子署名したデータと暗号化をしたデータをくっつける。（Sign-And-Envelop）
受信側では、暗号文を復号し、平文を得ます。
平文のダイジェストと、電子署名中の暗号化されたダイジェストを復号し、比較、検証します。
PEMと呼ばれる、S/MIMEに似た古い仕様では、この方式になっており、S/MIMEではPEMとの互換のためにのみ用いられます。

i一方のみが使えるようにしておきます。ただし、プライベート鍵のパスワードの扱い方は、製品によって、様々です。OSと統合する、起動後の初回のみ確認するなどのバリエーションがあります。