<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>monopolecr89のブログ</title>
<link>https://ameblo.jp/monopolecr89/</link>
<atom:link href="https://rssblog.ameba.jp/monopolecr89/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>ブログの説明を入力します。</description>
<language>ja</language>
<item>
<title>ゼロ知識証明</title>
<description>
<![CDATA[ <p>ゼロ知識証明<br><br>　証明する手続きの中で、相手に納得してもらう以外の情報を与えない手法。<br>　ゴールドワッサー、ミカリ、レイコフが定式化。<br>　以下３つの性質がある。<br>　<br>　（１）完全性<br>　　　命題が正しいなら検証者は必ず納得する。<br>　　　<br>　（２）健全性<br>　　　検証者が納得したなら、ほぼ１００％の確率でその命題は正しい。<br>　　　<br>　（３）ゼロ知識性<br>　　　検証者は命題が正しいこと以外の情報を得られない。</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12756260568.html</link>
<pubDate>Sun, 31 Jul 2022 16:05:44 +0900</pubDate>
</item>
<item>
<title>秘密計算</title>
<description>
<![CDATA[ <p>　MPC<br>　　ｎ人の参加者が、それぞれ秘密の値s1,s2,・・・snを持ち寄り<br>　　互いに自分の秘密値を見せることなくあんる関数の値を計算するプロトコル。<br>　　<br>　MPCの構成法<br>　　秘密分散、Garbled Circuit。<br>　　<br>　MPC参加者の仮定<br>　　semi-honestモデル<br>　　　参加者全員が指定されたプロトコルに従って正しく正直に振る舞うモデル。<br>　　　<br>　　maliciousモデル<br>　　　参加者の中にプロトコルに従わず途中の計算で嘘の値を与える悪意ある人がいる</p><p>　　　モデル。<br><br>　秘密分散<br>　　秘密鍵などの重要な情報を複数のデータに分散させて、それら単独では元の情報を</p><p>　　得られないようにすること。シャミアによる秘密分散が有名。<br>&nbsp;</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12756257251.html</link>
<pubDate>Sun, 31 Jul 2022 15:44:56 +0900</pubDate>
</item>
<item>
<title>準同型暗号</title>
<description>
<![CDATA[ <p>　　準同型暗号<br>　　　「暗号化したまま計算ができる方式」。<br>　　　データを暗号化してしまうと、平均や分散、相関などの計算処理ができず、従来の暗号方式の場合、復号してから計算する必要があった。<br>　　　準同型暗号を使うと、暗号化したまま統計処理を行い、そのまま暗号化された結果だけを取得可。<br>　　<br>　　加法準同型暗号<br>　　　準同型暗号のうち、暗号文同士で加算と減算のみ可能。ペイエ暗号、リフテッド・エルガマル暗号が有名。<br>　<br>　　完全準同型暗号<br>　　　暗号文同士で加算、減算、乗算も可能。格子暗号が有名。</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12756248185.html</link>
<pubDate>Sun, 31 Jul 2022 14:45:19 +0900</pubDate>
</item>
<item>
<title>HTTPの歴史</title>
<description>
<![CDATA[ <p>HTTP/1.1 1997/1～<br>&nbsp; １コネクションで複数のデータを順番に受信する。<br>&nbsp; 問題点：性能が低い<br>&nbsp;&nbsp;<br>HTTP/2 2015/5～<br>&nbsp; ストリームというデータ要求と受け取りの仕組みを導入し、複数の<br>&nbsp; ストリームを並行して処理する方式を導入。（ストリーム多重化）<br>&nbsp; 問題点：TCPパケットの一部が欠損すると再送されるまでストリーム全体が<br>&nbsp; 　　　　停止。（HOLブロッキング）<br><br>HTTP/3 2018/11～<br>　・２をベースにTLS1.3で秘匿性・完全性を確保<br>　・トランスポート層をUDPに変更（Google提唱のQUIC。ポート443上でUDP使用）<br>　・TLSとQUICで重複する暗号化機能するが、QUIC側で暗号化機能を使用<br>　　するように変更</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12755149283.html</link>
<pubDate>Mon, 25 Jul 2022 07:38:53 +0900</pubDate>
</item>
<item>
<title>メールのセキュリティ</title>
<description>
<![CDATA[ <p>SMTPS---クライアントとメールサーバ間にてTLS上でSMTPを行う。<br>　　　　メールサーバ間転送は保護されない。E2E(End-to-End）で保護されない。<br>　　　　<br>S/MIME--E2Eの為、秘匿性に公開鍵暗号、完全性と否認防止に署名利用。<br>　　　　ただし、利用するにはS/MIME対応のメールクライアントが必要なことと<br>　　　　秘匿性利用時には通信相手の公開鍵が必要。<br><br>Webメール--メールサービスとブラウザ間はTLS経由で保護。<br>　　　　　&nbsp;ただサービス提供者による閲覧が可能。<br>　　　　　&nbsp;ただしE2Eが提供されているメールサービスもあり、<br>　　　　　&nbsp;ProtonMail、Tutanotaがある。</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12755146352.html</link>
<pubDate>Mon, 25 Jul 2022 07:12:01 +0900</pubDate>
</item>
<item>
<title>Azure File Sync</title>
<description>
<![CDATA[ <p>【概要】<br>　　Azure FilesとオンプレまたはAzure上のWindowsサーバとのファイル同期<br>　　　(例)<br>　　　Azure Files &nbsp;&lt;-----&gt; オンプレWindwosサーバ<br>　　　　　　　　　　　|<br>　　　　　　　　　　　--&gt; &nbsp;Azure仮想マシン(Windowsサーバ）<br>　　　　　　　　　　　<br>【構成要素】<br>　　①ストレージ同期サービス<br>　　　　同期グループの管理<br>　　②Azure File Syncエージェント<br>　　　　同期するWindowsサーバにインストールするエージェントプログラム。<br>　　③同期グループ<br>　　　　同期する単位<br>　　④クラウドエンドポイント<br>　　　　同期の対象となるAzureファイル共有へのポインターとなるオブジェクト<br>　　⑤サーバーエンドポイント<br>　　　　同期の対象となるWinodwsサーバへのパスを表す情報<br><br>【実装手順】<br>　　①ストレージ同期サービスデプロイ<br>　　②Windowsサーバの準備<br>　　③WIndowsサーバへのエージェントインストール＆ストレージ同期サービスへのサーバ登録<br>　　④同期グループとクラウドエンドポイント作成<br>　　⑤サーバエンドポイントの追加<br>　</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12755142113.html</link>
<pubDate>Mon, 25 Jul 2022 06:28:56 +0900</pubDate>
</item>
<item>
<title>DNSのセキュリティ対策</title>
<description>
<![CDATA[ <p>【DNSSEC(DNS Security extensions)】</p><p>　権威DNSサーバが返す値に署名を付与したもの。権威サーバとキャッシュサーバ間の通信の完全性を保証。</p><p>&nbsp; 権威サーバからの応答を偽装するキャッシュポイゾニング攻撃対策。</p><p>&nbsp;</p><p>【DoT(DNS over TLS)とDoH(DNS over HTTPS)】</p><p>　クライアントとキャッシュサーバ間の通信の機密性と完全性を保証。</p><p>&nbsp; DoTはポート853/TCP通信を行う為、ファイアウォールの設定が必要。</p><p>　DoHはHTTPSで通信を行う為、ファイアウォールの設定は不可であるがブラウザ毎に設定が必要。</p><p>&nbsp;</p><p>【ESNI(Encrypted SNI)】</p><p>&nbsp; &nbsp;１台のサーバで複数のサーバ証明書を保持している場合、クライアントはサーバへどのドメインにアクセスしたいかをサーバへ通知(ClientHello中の項目)する（SNI-Server Name Indication))。この場合、通知するドメイン名は暗号化されていない。</p><p>&nbsp;</p><p>　　ESNIは上記ドメイン名を暗号化する仕組み。</p><p>&nbsp;</p><p>【ECH(Encrypt ClientHello)】</p><p>&nbsp; ESNIはClientHello内のドメイン名の暗号化だが、ECHはClientHello自体の暗号化を行う仕組み。ClientHello暗号化する際の公開鍵を保持する目的でDNSにHTTPS RRレコードを追加。</p><p>　ESNIやECHは暗号化によりプライバシー保護が強化されるが、政府介入が困難となる為、中国やロシアでは通信ブロックにより使用させない方針。</p><p>&nbsp;</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12754980357.html</link>
<pubDate>Sun, 24 Jul 2022 07:50:55 +0900</pubDate>
</item>
<item>
<title>前方秘匿性(Forward Secrecy)</title>
<description>
<![CDATA[ <p>【定義】</p><p>　長期間利用される公開鍵暗号の秘密鍵が漏洩しても、それまでに通信していた暗号文の内容は保護（解読できない）ような性質。</p><p>&nbsp;</p><p>【経緯】</p><p>　2013年にスノーデンにより、NSAがインターネットを盗聴していることを暴露。NSAはスノーデンが利用していたメールサービスプロバイダに対し、メールの暗号解除目的でプロバイダ自身の秘密鍵の提供を裁判にて求め、勝訴。スノーデン以外の利用者の暗号解除も可能な為、このプロバイダ（Lavabit）はサービス終了となった。</p><p>&nbsp;</p><p>【利用技術】</p><p>　DH鍵共有やECDH鍵共有を使用。TLS1.3では前方秘匿性は必須となっている。</p><p>&nbsp;</p><p>&nbsp;</p><p>　</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12754976422.html</link>
<pubDate>Sun, 24 Jul 2022 07:13:27 +0900</pubDate>
</item>
<item>
<title>Azure仮想マシンのネットワークインターフェイス(NIC)</title>
<description>
<![CDATA[ <p>Azure仮想マシンのネットワークインターフェイス(NIC)<br>　・Azure 仮想マシン (VM) には、複数のネットワーク インターフェイス (NIC) をアタッチ可<br>　・NIC には、複数の静的または動的パブリックおよびプライベート IP アドレスを割り当て可<br>　・1 つの NIC 上のすべての IP 構成は、同じサブネットに関連付けられている必要がある<br>　・NIC に割り当てることができるプライベート IP アドレスの数には上限あり(256個)<br>　・NIC に割り当てることができるパブリック IP アドレスの数には上限あり(256個)</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12754317885.html</link>
<pubDate>Wed, 20 Jul 2022 07:28:30 +0900</pubDate>
</item>
<item>
<title>Azureのロック</title>
<description>
<![CDATA[ <p>　・ロックの種類は２種類<br>　　　（１）削除(CanNotDelete)－－－読取：可　変更：可　　削除：不可<br>　　　（２）読取専用(ReadOnly)－－－読取：可　変更：不可　削除：不可<br>　　　　　　（＊）仮想マシンの起動・停止操作も「変更」範囲に含まれる<br>　　　　　　（＊）リソースグループへの新規リソース追加も「変更」範囲に含まれる<br>　・ロックのスコープは、サブスクリプション／リソースグループ／リソースの３種類<br>　　上位のスコープで設定されたロックは下位に継承される。</p>
]]>
</description>
<link>https://ameblo.jp/monopolecr89/entry-12754316046.html</link>
<pubDate>Wed, 20 Jul 2022 07:12:02 +0900</pubDate>
</item>
</channel>
</rss>
