Version 4 (modified by 14 years ago) ( diff ) | ,
---|
Boost.勉強会 #4 ノート
Boost Fusion Library
タプルとは
- Boost Tuple Library
- std::pair の N個版
ヘテロなコンテナとは
あらゆる型を格納できるコンテナ。 std::vector<boost::any> タプルもヘテロの一種
Boost.Fusion
タプルをヘテロとみなして STL チックな種々のアルゴリズムを適用するライブラリ。
Fusion シーケンス
- vector, list, deque が使える
- イテレータもいける
- for_each の実装例 ... 要素毎に型が異なるので再起関数として実装する
アルゴリズム
- View を用いた遅延評価が特徴。
使いどころ
- 名前がついているがシーケンスとしても扱いたい場合 (RGB など)
- 構造体として扱うと名前を付けられるがシーケンスとして扱えない
- 配列だと名前が…
- DSEL の内部実装 (Boost.Spirit.Qj/Karma)
- 異なる型のシーケンスを扱う機会が多い。Regexp やパーサコンビネータ。
fusion::vector<int, char, double> result; parse("1 a 3.14", int_ >> char_ >> double_, result);
- 異なる型のシーケンスを扱う機会が多い。Regexp やパーサコンビネータ。
- Fusion Sequence をコンセプトとするライブラリへの一括アダプト (Boost.Geometry)
- Fusion シーケンスとしてアダプトされたすべての型を、 Geometry の coordinate として扱うことが出来る。
ライブラリの設計
- タプルは値 (メンバ変数) と値の集合 (クラス) に、名前のない複合データ型。
- Boost.Fusion では、ユーザー定義型を Fusion シーケンスにアダプトすることで、名前有りタプルとみなすことが出来るようになる。
- ユーザーコード: 名前有り世界 / ライブラリコード: 名無し世界 として棲み分けするとよさげ…。
- タプルはクラスを作るのが面倒くさいときに即興で使われることが多い。... メンテナンス性が低下する
- データを単なるシーケンスとして扱って良いのはライブラリの中だけ。
- ユーザーコードではユーザー定義型を fusion シーケンスへアダプトすることで有用なアルゴリズムが使えるようになる。
まとめ
- タプルをリストとみなす
- タプルに名前をもたらす
- ライブラリの設計に取り入れればユーザーコードが柔軟に
C++プログラマの為のセキュリティ入門
- 基本的且つ普遍的な事柄が中心ですよ~
セキュリティって?
- ツッコミが恐い世界w
- ここ数年のトレンドは常に追っていこう
- こうしておけば安心というのは幻想
- セキュリティはトータル
- コスパは重要
- 存在時の被害よりコストが増大では意味がない
- 攻撃に成功するのにかかるコストが十分に大きければよい
- リスクアセスメント
- 情報資産の棚卸し
- CIA の観点からリスクを列挙 (機密性、完全性、可用性)
- コストパフォーマンス
- そもそも何を防ぐべき?
- 意図しない/許さない
- 権限の取得
- 処理の実行
- 情報の漏洩、盗聴、削除、改ざん
- DoS
- spam/嵐
- H/W の損壊/盗難
- 意図しない/許さない
- どう防ぐべき?
- 権限管理
- 入力チェック <- ?
- 入出力の正確なエンコード/デコード/エスケープ/アンエスケープ
- 暗号
- 証明
- ケンジントンロック
- 法的圧力
- etc...
- 公開されているロジックで (暗号の話)
- 安全性の定義
- 暗号の安全性
- 情報理論的安全性
- 正解が (理論的に) わからない →強秘匿性
- 暗号文と同じ分量の鍵情報が必要になる。使い回しできない。
- 正解が (理論的に) わからない →強秘匿性
- 計算量的安全性
- 大量のコスト (時間、CPU) をかけなければ解けない
- コンピュータの進化は早い…
- 大量のコスト (時間、CPU) をかけなければ解けない
- 情報理論的安全性
- 事例を追いかけよう
さまざまな問題
- 通信の盗聴
- バッファオーバーフロー
- 整数オーバーフロー
- エスケープ
- セッションハイジャック
- 辞書攻撃
- ファイルパス
- ファイルコンテンツ
歴史
- DES の最強っぷりと衰退、そして AES へ
さまざまな技術
- ハッシュ関数
- MD5, SHA1, SHA2
- MD5, SHA1 は非推奨…
- 一方向性関数
- MD5, SHA1, SHA2
- 暗号
- 秘密分割
- XOR
- 秘密分散
- 多項式+有限体
- 上記 2つは情報理論的暗号性、強秘匿性があるよ
- 秘密分割
- 乱数
- 真性乱数
- 偏りが現れる。
- 一般的に遅い。
- 疑似乱数
- 真性乱数
- PKI
- 実在証明でしかない
- おれおれ証明書だとなりすましを防げないよ
- 証明書の更新時には秘密鍵もちゃんと更新しよう!
- TPI
C++ では
- クライアントで動作するコードであれば
- すべてクラック可能
- システム管理者とユーザーとゲストとリモートアクセスに対してどのようにあるべきか
- クラックにも難易度が
- コードサイニング (署名)
- サーバーで動作するコードであれば
- 入出力チェックを厳格に
- バッファーオーバーラン対策
- 文字数上限チェック
- マルチバイト周り、サロゲートペア周りでちょんぼしないこと
- 整数オーバーフロー対策→値域上限チェック
- 正しくエスケープ
- 文字数上限チェック
- 不正な文字エンコードの検出
- UTF-8 でのチェック逃れ
- マルチバイト文字列での閉じ文字喰い
- ファイルパス
- 相対パスのチェック
- NGワードの除外
- 偽バックスラッシュ
- UNICODE 外のエンコードに変換時にバックスラッシュに化ける
- UNICODE 制御文字
- Shift と XOR を使った文字列の難読化
- nul 文字を nul 文字のままに出来る
- セキュアな乱数
- Windows: CryptGenRandom()
- Linux: /dev/random, /dev/urandom
- /dev/random は長時間ブロックする場合がある。 /dev/urandom は必ずしもセキュアではない。
- ライブラリ
- Crypto++
- Crypto API
- Windows の Crypt API を使用する上での注意
- JISEC と JCMVP
参考情報
- IPA
- セキュアプログラミング講座
- JISEC
- JCMVP
- セミナー・イベント
- JPCERT CC
- セキュリティーホールmemo
- 本当は恐い文字コードの話
- それ Unicode で
- 暗号技術大全
Note:
See TracWiki
for help on using the wiki.