NTT、計算機科学の未解決問題を解決 著名教科書の「二分決定グラフ」に関する誤りを指摘
NTTは2月19日、計算機科学の未解決問題を解決したと発表した。同社が解決したのは、著名なデータ構造として知られる「二分決定グラフ」に関する未解決問題。今回示した理論は、計算機科学の著名な教科書にあった記述の誤りを指摘しており、研究チームの修正案が承諾され、内容が改訂されるという。 二分決定グラフとは、集合のあつまりである「集合族」を表現するデータ構造だ。例えば、集合｛1, 2｝と集合｛2, 3｝からなる集合族は、｛｛1, 2｝,｛2, 3｝｝と表現できる。集合族は汎用性が高く、さまざまなデータ構造を表現する際に使われる。その例には、ある地点から別の地点までの移動経路の組合せや、同時に利用可能なクーポンの組合せなどがある。 ネットワークの通信パターンを表現する集合族、二分決定グラフの例 図では16個の通信パターンを16個の集合からなる集合族で表現し、それを11個のノード（節点）を結ぶ線から
Javaの圧縮・解凍ライブラリ（JDK標準GZIP、Commons Compress、snappy-java、LZ4 Java）を試す - CLOVER🍀
ちょっと圧縮・解凍ライブラリを調べていまして、簡単に以下あたりを比較したり、確認するための 下地を作ってみようかなと思いまして。 参考） 2016年のOSS圧縮ツール選択カタログ Snappyとか名前をちらっと見かけたことがあるくらいだったので、こういう機会に1度見ておこうかと。 ピックしているものはけっこう適当だったり雰囲気だったりしますが、ご愛嬌。 なお、とりあえず確認にはテストコードを使うため、JUnitとAssertJをMaven依存関係に加えている ものとします。 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> <dependency> <groupId>org.assertj
Commons Compress – Overview
Compress Overview User Guide Known Limitations Conventions Issue Tracking Download Security Wiki API Docs Javadoc Javadoc Archive Project Documentation Project Information About Summary Team Source Code Management Issue Management Mailing Lists Maven Coordinates Dependency Management Dependencies Dependency Convergence CI Management Distribution Management Project Reports Commons Home License Comp
JavaVM 用圧縮ライブラリの比較 - Qiita
Java 標準の GZIP や Deflate (ZIP) に加えて以下のアルゴリズムを実装しているライブラリを使用した。それぞれの Maven リポジトリ ID はページ末リンクの build.sbt 参照。 Zstandard: 圧縮率は gzip 以上 bzip2 未満だがそれらより有意に速い。既存の gzip はもちろん、数%のサイズ差が事業コストに跳ねるようなシビアな世界でなければ bzip2 も Zstd 化を検討する価値あり。レベルで調整可能。 lz4: 圧縮率で Snappy と同等、速度面で Snappy より有利なため、処理速度優先なら lz4。 Brotli: 高圧縮率勢の中でも頭一つ抜けることがある。圧縮と展開の速度差が大きく、展開速度は Zstd に劣るが gzip, bzip2 よりは速い。UTF-8 モードを使えばテキスト圧縮の効率は上がる (未確認)。 Sn
Java のデータ圧縮ライブラリを極める #jjug_ccc #ccc_c7
テキストデータや画像・音声データなどの種類を問わずに適用できる 汎用的なデータ圧縮ライブラリ というと、deflate アルゴリズム の実装である zlib が古くからデファクトスタンダードとして存在しており、実際に広く使われています。ご多分に漏れず、zlib は Java にも組み込まれており、標準ク…
UUID(v4) がぶつかる可能性を考えなくていい理由 - Qiita
お手軽にランダムなIDを取得したい時にUUIDはとても重宝します。 でもたまに、 「このID(UUID)ってぶつかることない？対策しなくて大丈夫？」 と聞かれることがあります。 それに対して、 「ウィキペディア先生がぶつからねえって言ってたから大丈夫だよ！（＃ﾟДﾟ）」 で切り抜けるのもそろそろ限界のような気がするのでちゃんと調べました。 (もちろんウィキペディア先生を頼りました！) 2つの理論 UUIDの衝突確率について考える上で次の2つの理論が重要になります。 鳩の巣原理 誕生日のパラドクス 鳩の巣原理 鳩の巣原理とは、 m個の入れ物にn個のものを入れるとき、n > m ならば少なくとも1個の箱には2個以上のものが入る 9個の巣箱に10羽の鳩が入る場合、必ずどれかの巣箱には2羽以上入ることになるということです！(ウィキペディア先生) 考えれば当たり前のことですが同様にして考えれば、 「
何故パスワードをハッシュ化して保存するだけでは駄目なのか？ - NRIネットコムBlog
不正アクセスによるIDとパスワードの漏洩を受けて、MD5によるハッシュ化について話題になっていました。システムを作る上で、パスワードの管理や認証はどう設計すべきかを考えるために、少し整理をしてみます。もし事実誤認があれば、どしどしご指摘ください。 == 2023/8/21追記 == この記事は、ハッシュの保存の仕方一つとっても、沢山の対策方法が必要であるということをお伝えするために記載しています。そして、これから紹介する手法を取れば安全とお勧めしている訳ではないので、その点をご留意いただければと思います。攻撃手法に応じての対応策の変遷を知っていただくことで、セキュリティ対策は一度行えば安全というものではないことを知って頂くキッカケになれば幸いです。 == 追記終わり == パスワードのハッシュ化 まず最初にパスワードの保存方法です。何も加工しないで平文で保存するのは駄目というのは、だいぶ認
一意な識別子の生成でUUID/ULID/CUID/Nano IDなど検討してみた - Sweet Escape
最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
What are ssh-keygen best practices?
Most users would simply type ssh-keygen and accept what they're given by default. But what are the best practices for generating ssh keys with ssh-keygen? For example: Use -o for the OpenSSH key format rather than the older PEM format (OpenSSH 6.5 introduced this feature years ago on 2014-01-30) How should one calculate how many rounds of KDF to use with -a? Should -T be used to test the candidate
SSH Key Best Practices
Ensure Separation Ensure SSH Keys Are Associated With a Single Services Tie SSH keys back to an individual services, rather than just a generic key that is associated with multiple services github / acquia /aws etc . This will provide an effective SSH audit trail and more direct oversight. Use a separate key per client you SSH from So don’t copy the private key from your laptop to another laptop f
ソート可能なUUID互換のulidが便利そう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? UUIDは重複しないIDを生成する手段として便利ですが、特にversion4(乱数によるUUID)を利用する場合は一意性を得るのと同時に乱雑さも得ることになりますので、UUIDに順序性を求めることができません。 UUID - Wikipedia https://ja.wikipedia.org/wiki/UUID UUID（Universally Unique Identifier）とは、ソフトウェア上でオブジェクトを一意に識別するための識別子である。UUIDは128ビットの数値だが、十六進法による550e8400-e29b-41d4-
徹底解剖 TLS 1.3 | 翔泳社
wolfSSLをもとに、SSL/TLSの正しい利用法と仕組みを理解する 暗号化された安全な通信は、ネットワークを使う全てのアプリケーションにとって、 考慮すべき重要な課題です。 セキュアな通信を実現するために用いられる技術SSL/TLSの最新版がTLS 1.3であり 各種SSLライブラリも対応してきています。 ただ、ライブラリだけが最新のものになっても、仕組みを知り、 正しく使わなければ、安全は担保されません。 そこで本書は、そんなTLS 1.3の基礎的なプロトコルの流れから、 暗号化・認証の仕組み、アプリケーション実装のベストプラクティスを 組み込みシステム向けの軽量＆高機能なライブラリwolfSSLを例に 解説していきます。 さらに、ライブラリコードの解説を含め、内部実装にまで踏み込んだ解説も行い、 SSLライブラリを徹底的に理解できる一冊です。 Part 1：TLSの技術 ・Chap
OpenSSHがSHA-1を使用したRSA署名を廃止、BacklogのGitで発生した問題と解決にいたるまでの道のり | 株式会社ヌーラボ(Nulab inc.)
サービス開発部SRE課の@vvatanabeです。 2021年9月26日、OpenSSH 8.8がリリースされました。大きな変更として挙げられるのは、SHA-1ハッシュアルゴリズムを使用したRSA署名の廃止です。 本記事では、この変更がBacklogに与えた影響、その時現場で起こっていたこと、問題解決のプロセス、なにを教訓にしたのか等、順を追って解説します。 ※ 本記事はNuCon 2021で発表した内容をブログ化したものです。 問題の発覚 BacklogのGitへSSHでアクセスできない TypetalkのBacklog開発者のトピックで、以下のフィードバックが投稿されました。 「OpenSSH 8.8へアップデートすると、BacklogのGitへSSHアクセスできない」という内容でした。 問題の調査 Inside SSH protocol v2 深堀りしていく前に、SSHプロトコルの接
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - luben/zstd-jni: JNI binding for Zstd
[0.0, 1.0) の乱数を得るための“本当の”方法
Amazon.co.jp: 独学コンピューターサイエンティスト Pythonで学ぶアルゴリズムとデータ構造: コーリー・アルソフ (著), 清水川貴之 (翻訳), 新木雅也 (翻訳), 大村和子 (翻訳), tell-k (翻訳): 本
Home — Memory Management Reference 4.0 documentation
SSH Key Management Overview & 10 Best Practices | BeyondTrust
ReDoS 検出の最先端 recheck の紹介 / State of the Art of ReDoS Detection
GitHub - ulid/spec: The canonical spec for ulid
