必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。通信相手の認証については読み取れない。ことが明示されています。サーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。利用されていることでしょう。有効にしているそこのあなた、今すぐ無効にしましょう。ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。軽いという点をどのように実装しているのか気になります。22時40分に閲覧:ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート(アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全であると判断できるか否かを決める大切な情報です。22時40分に閲覧:既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。実装されており近年では広く使われています。要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。仕組みを利用しています。共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。22時40分に閲覧:ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。ビット反転攻撃に弱いことが知られています。データの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。ようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。上で説明したとおり鍵管理という問題への解決策になりません。公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。サーバーから取得するようなものではないかと思います。用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。公開鍵と秘密鍵がどこでどのように保管されているのか気になります。サーバーに預託していないことを祈るばかりです。鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。アプリに何か細工をする方がより簡単でしょう。ないと考えられ、望ましくないという意見もあるようです。サーバーでも同様です)。鍵についてはそのユーザーに影響が限定されます。採用しないという判断かもしれません。いう情報も守りたくなります。サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。