「xor」を含む日記 RSS

はてなキーワード: xorとは

2020-01-12

anond:20200112211011

話は違うけど

乃木坂ってAKBにつくんですか?欅坂につくんですか?どっち?パイソン使いだけにな!

 ↓

話は違うけど

乃木坂ってAKBにつくんですか?欅坂につくんですか?どっち?パイソン使いだけにな!

XOR 乃木坂,欅坂

※例:

2019-11-09

anond:20191109110921

検索したら「ブール代数では1+1=1」って記事がいくつも出てくるんだが。もしかして計算機科学世界ではブール束における「∨」を「+」で書く流儀があるのか?

ブール代数=ブール束=ブール環だから、+って書いたら普通はブール環における演算のことだと(俺は)思ったのだが。その場合xor解釈されるのが自然

"+"をxor意味で扱ってるブール代数テキストがあったら是非読んでみたいもの

2019-10-23

日常生活で【A or B】と言う時はほとんどの場合「A xor B」(AとBのどちらか一方)なんだから数学的な意味での「A or B」(AとBのどちらかまたは両方)は日常的な意味での「A or B」に【or】の表記を譲って新しい全く別の表記を使うべきだろ

なんで日常的な意味での「A or B」の方が新しい表記xor】を使わされてるんだよ

2018-10-31

TRICKxor” TREAT が正しい!」って言う人って

ビーフ or チキン」に「両方ください」って返すの?

2017-08-03

https://anond.hatelabo.jp/20170803114141

XORをゾアと読むと笑われるのに

NORをエヌオアと読むと笑われる

ふしぎ

プログラマーだけどXORのことゾアって読んで恥かい

2017-03-09

某国通信業者に勤めてるんだけどさ

何気ない会話の中で

「そこは2人のANDを取らないといけないですね」

って言ったらみんな「?」な顔してるんだよね

んで

情報理論的なANDですよ,ORとかXORとかの」

とか言ったらもはや

「い,い,い,いくし,なんだって?」

って感じで半笑いになったんだよ

んで説明しても

「あー研修でそんな話もあったね」

ぐらいの反応なわけ

別にたまたまその人が単に畑違いなだけではなくて,そこにいる人たちみんな「?」ってなってて

後で他のグループとかにも聞いたらやっぱり「?」ってなって

唯一反応したのがサーバ系の調達任されてるヲタクだけだったわけですよ

そん時気づいたんだけど,ネットワーク屋さんって情報処理屋さんではなくて

近い存在でもなくて全く無関係職業なんだな,と

ヤマトパソコン運んでてもパソコンに詳しいわけじゃないもんね

いや,ぶっちゃけ薄々勘付いてはいたんだけどまさかそこまでとは思わなかった

2016-11-04

お前らってNANDとかXORが好きそうだよね

無題

2016-08-28

http://anond.hatelabo.jp/20160827212940

単独

語中

  • /ks/(クス) ox (オクス)
  • /gz/(グズ) exam(エグザム)
  • /kʃ/(クシュ) sexual(セクシュアル)
  • /gʒ/ (グジュ) luxury(ラグジュリー

語頭

略記

参考

2016-04-14

http://anond.hatelabo.jp/20160414194858

設定ファイルに書くにしても、最低限のXOR暗号化だけはしておこうな。

アプリに内蔵のパスワードXORするみたいな。

2014-06-27

徳丸本の内容を実践しながら学べた話

新卒入社したA社は、親会社B社のシステムの内製と、B社の顧客層向けのパッケージソフトウェア制作販売するソフトウェアハウスだった。

入社1年目の自分は、いくつかの細かい業務を平行して担当することになったが、その中にホームページ管理があった。主な業務は、ページの文章更新と確認、誤字脱字の修正、古く間違ったHTML修正など。

会社ホームページには自社のサービス製品だけを扱う小さなショッピングシステムがあり、ユーザ登録・ログイン・購入・履歴確認など一通りの機能を持っていた。このシステムを改修したり更新したりする予定はなかったが、せっかく担当となったわけだし、以前から興味のあったWebアプリケーションセキュリティ勉強しようと、徳丸本を購入した。(当時は紙の本しかなかった)

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

この本は説明不要の名著で、平易な文章で細かく正確な記述がなされている。Webアプリケーション制作に携わる新人プログラマは必読だ。

から読み進める。1章に用語の整理があるおかげでだいぶ理解やすい。2章の実習環境の用意は、都合がつかず読み飛ばした。3章は流し読みし、いよいよ4章。様々な脆弱性を個別にとり挙げ、原因と対策について具体的な説明がされており、非常に興味深い。

なるほど、XSSクロスサイトスクリプティング)という言葉は知っていたが、具体的にこういうものなのだな。入力ボックス入力した内容が遷移後のページに表示されるというUIはよくあるから、気をつけなければ……そういえば、会社ホームページにも検索機能があって、「検索ワード:○○」と表示されるところがあったな。あれもXSS対策がされているはずだ。どれ、見てみよう。テストサーバで画面を表示して、<script>alert(1)</script>(本当は半角)と入力……

検索ワード:
   +----------------+
   |                |
   |   1            |
   |       [  OK  ] |
   +----------------+

なるほどこれがXSSか。実習環境の用意はしなかったが、実物を拝むことができたぞ。脆弱性修正の実習もできるな。

このようにして、徳丸本を読み進め、(テストサーバで)攻撃を実践しながら、脆弱性を直していった。覚えている限りでは、以下の実習ができた:

  1. 上述のXSS。直した。
  2. SQLインジェクション - XSSと同様の検索フォーム部分、ログイン部分。誰のアカウントにでもログインできた。急いで直した。
  3. CSRFクロスサイトリクエストフォージェリ) - ログイン済みのユーザを細工されたページに誘導すると、パスワード任意の値に変更できた。すぐ直した。
  4. クッキー不適切な利用 - httponlyでないCookieに、ユーザIDパスワードナンチャッテ暗号化(全ユーザ統一の値でxorしただけ)して保存していた。1のXSSとの合わせ技でその内容を外部に送信できたし、暗号の強度もダメだったし、そもそもログイン自体に使う情報Cookieに保存すべきではない。しかしこのCookie依存している箇所がたくさんあったため、XSS修正とhttponlyの対応だけになった。一応直った。

ショッピングシステムの中身が、フレームワークライブラリなし・SQL発行共通関数なし・オブジェクト指向なし・数万行の巨大ファイル1つであることを知ったのは、脆弱性修正にとりかかってからだった。その他のシステムもすべてこのショッピングシステムを参考に作られているらしく、プレースホルダエスケープもない文字列組み立てSQL発行があらゆる場所に散乱していた。とても直し甲斐があるシステムであった。

これらのシステムは、日付zip以上のバージョン管理が行われていなかったため、該当部分を誰が書いたのかはわからなかった。そんな状況であったので、大量に報告された脆弱性始末書は、すべて現在担当である自分が書くことになった。

自分入社するより前からあった、誰が作ったのかもわからない脆弱性を、探し修正始末書を書いた。「私が担当になる前からあった脆弱性なので、原因はわかりません。おそらく不勉強が原因です。対策は、勉強会コードレビューバージョン管理です。」などと書いた。今思えば、"よい始末書"の書き方を勉強する機会を逃していたのかもしれない。

自分の作業はすべてgitで記録していたので、自分担当になったときにはすでに脆弱性があったと主張したが、「自分だけバージョン管理などという便利なものを使っていてずるい」と怒られて終わった。(なお、それよりも前に社内でのバージョン管理ツールの使用は提言していたし、それが「よくわからないから」と却下されてからは、自分だけで使う許可は得ていた。)この経験からバージョン管理をしていない、もしくはクソみたいな管理しかしていない組織内で、自分だけでも上手く管理する方法についての知見を得た。

こうして、徳丸本の内容を実践しながら学習できたので、セキュリティ分野についての興味はより高まり、知識も増え、A社に対する信頼はほとんど失われたので、さら勉強し、3年目に入るころには情報セキュリティスペシャリスト試験合格し、転職した。

Webサービスセキュリティ勉強したいと思ったならば、徳丸本を読んで、実践しながら勉強することを強く推奨する。紙の本には実験環境CDもついているので、A社でホームページ担当していなくても、実践しながら勉強することが可能だ。(電子版の場合はどうなのだろうか。申し訳ないが各自確認していただきたい。)

すばらしい本を書いてくださった徳丸先生感謝します。

http://tatsu-zine.com/books/sbcr-taiketekinimanabu

2014-05-23

http://anond.hatelabo.jp/20140523125940

(x XOR y) XOR y = x XOR (y XOR y) = x XOR 0 = x

XOR結合法則を満たす

0をXORしても変化しない

http://anond.hatelabo.jp/20140523125940

まぁ、そういうことだね。

z = x XOR y とすると、

x = z XOR y

y = z XOR x

という関係が、 x,y,z の間に成り立つ。

これはそいうもんだと思っておけばおk

2014-05-22

http://anond.hatelabo.jp/20140522013231

x=0,y=0 の時

(x XOR y) XOR y = (0 XOR 0) XOR 0 = (0) XOR 0 = 0 = xと同じ

x=1,y=0 の時

(x XOR y) XOR y = (1 XOR 0) XOR 0 = (1) XOR 0 = 1 = xと同じ

x=0,y=1 の時

(x XOR y) XOR y = (0 XOR 1) XOR 1= (1) XOR 1 = 0 = xと同じ


x=1,y=1 の時

(x XOR y) XOR y = (1 XOR 1) XOR 1= (0) XOR 1 = 1 = xと同じ

http://anond.hatelabo.jp/20140522011839

y := (x XOR y) XOR y

1bitで考えてみな。xが2通り、yが2通りで4通りしかないから

2013-03-23

http://anond.hatelabo.jp/20130323083532

アホか

ついったーに送るにはいつか生のキーXORしなきゃいけなくって、その時ダンプを取ったら丸見えだよ、っていう話だろ

からこの作者が「プロテクト強化した(ドヤァ」とかやっても意味ないよ、と。

tweetdeck中の人は多分それはわかっていてだから面倒なプロテクト(笑)はしなかったんだろうけど、もふったーの作者であるところのスーパーハカー様はなんか勘違いされているようですね

プロテクト強化後のもふったーも予想以上に酷かった件(追記あり)

ことのあらまし
  1. Twitterクライアントもふったーの作者「TweetDeckのconsumer secret簡単に抜ける、終わってる」(http://blog.livedoor.jp/blackwingcat/archives/1760823.html)
  2. 別の誰か「もふったーのconsumer secretも簡単に抜ける」(http://d.hatena.ne.jp/kusano_k/20130318/1363640368)
  3. もふったーの作者「プロテクト強化した」(http://blog.livedoor.jp/blackwingcat/archives/1762970.html)

プロテクトかけたアルゴリズムを実装したバージョン差し替え」たなんて言われると本当に「プロテクト」がかかっているのか確かめてみたくなるのが人情というもの。というわけで、プロテクト強化後のもふったー(v0.9.6b)からconsumer secretが抜けるか試してみた。結論から言うと、あっけなく取り出せた。以下に手順を記す。

手順

動作がよくわかっていないアプリケーションを解析して仕様を明らかにすることをリバースエンジニアリングと呼ぶ。ソフトウェアリバースエンジニアリングは基本的に対象を逆アセンブルしてひたすら読むことによって行う(その補助に1命令ずつ実行してレジスターやメモリーの様子を観察することもある)。しかし、よっぽど小規模なものでなければオブジェクトコード全体を逆アセンブルして最初から最後まで読むなんてのは不可能だ。人間の読速度には限界があるし、時間も有限だからだ。そして、詳しい動作を知りたい部分というのは全体のごく一部であることが多いので全逆アセンブリを読むのには非常に無駄が多い。

からリバースエンジニアリングはいかに詳らかにすべき動作を行っているコードを絞り込むか(=読むべき逆アセンブリを少なくするか)が重要になる。

この場合も同様だ。TwitterGUIクライアントを頭から読むのは到底無理なので、どうやって解析すべきコードの範囲を狭めるかを考えた。それにはOAuth認証においてconsumer secretがどのような役割を果たすのかを知る必要がある。

OAuth認証で、consumer secretはそのままサーバーに送信されたりはしない。signatureの生成にHMAC-SHA1が使われ、その鍵にconsumer secretが使われる。HMACは次のように算出される。

HMAC (K,m) = H ((K ⊕ opad) ∥ H ((K ⊕ ipad) ∥ m))

ここで

である

まずはこのあたりから攻めようと思った。SHA-1計算はいくつか特徴的な定数が使われるので、そこからSHA-1計算に使われているであろう関数444190を特定する。この関数エントリーポイントに中断点(ブレークポイント)を設定してOAuth認証をさせるべくもふったーの「ブラウザ認証ボタンを押す。狙い通り中断するので関数を抜けるまで実行する。関数401100の4012DAに出た。少し下を見るとこのようになっている。

CPU Disasm
Address   Hex dump          Command                                      Comments
00401311  |.  33F6          xor     esi, esi
00401313  |   8D8C24 A40000 /lea     ecx, [local.54]
0040131A  |.  394C24 14     |cmp     dword ptr ss:[local.90], ecx
0040131E  |.  75 0E         |jne     short 0040132E
00401320  |.  3BF5          |cmp     esi, ebp
00401322  |.  73 29         |jae     short 0040134D
00401324  |.  0FB68434 A400 |movzx   eax, byte ptr ss:[esi+esp+0A4]
0040132C  |.  EB 21         |jmp     short 0040134F
0040132E  |   3BF5          |cmp     esi, ebp
00401330  |.  73 1B         |jae     short 0040134D
00401332  |.  8B5424 18     |mov     edx, dword ptr ss:[local.89]
00401336  |.  52            |push    edx                                 ; /Arg1 =  [LOCAL.89]
00401337  |.  8D8C24 FC0000 |lea     ecx, [local.33]                     ; |
0040133E  |.  8BD6          |mov     edx, esi                            ; |
00401340  |.  E8 CB4D0000   |call    00406110                            ; \mofooter.00406110
00401345  |.  83C4 04       |add     esp, 4
00401348  |.  0FB6C0        |movzx   eax, al
0040134B  |.  EB 02         |jmp     short 0040134F
0040134D  |   33C0          |xor     eax, eax
0040134F  |   34 5C         |xor     al, 5C
00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al
00401358  |.  83C6 01       |add     esi, 1
0040135B  |.  83FE 40       |cmp     esi, 40
0040135E  |.^ 72 B3         \jb      short 00401313
00401360  |.  895C24 3C     mov     dword ptr ss:[local.80], ebx
0040134F  |   34 5C         |xor     al, 5C

が注意を引く。もしかしてこれはopadとのxorではないか?

00401351  |.  888434 B80000 |mov     byte ptr ss:[esi+esp+0B8], al

xorした結果を格納している。

先ほどの中断点は無効化しこのループを抜けた地点である401360まで飛ばす。この時点でesp+0B8を見ると次のようになっている。

Hex dump
64 2E 16 64|37 04 32 6D|0F 0D 26 29|3A 37 1F 2F|
18 69 6E 6E|0D 25 29 33|11 34 29 69|12 36 24 1E|
05 16 33 6A|04 3B 0E 68|7A 5C 5C 5C|5C 5C 5C 5C|
5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|5C 5C 5C 5C|

あとはこれと5Cとをxorすればconsumer secretが手に入る。終わり。

追伸

はてな増田スーパーpre記法で半角の<>が含まれていると投稿が出来ないのを早く直してください。

3/23 18:45追記

もふったーの作者から反応があった。「本気だったつもりのもふったーのデバッグ処理が残ってた」らしい(http://blog.livedoor.jp/blackwingcat/archives/1763951.html)。修正したとのことなので最新版(v0.9.6e)を見てみた。確かに若干変更されているが何の問題もない。SHA-1の呼び出しに中断点を設置して渡されているバイト列を見るだけ。

CPU Disasm
Address   Hex dump          Command                                  Comments
00401324  |.  8D4424 20     |lea     eax, [local.102]
00401328  |.  50            |push    eax                             ; /Arg1 = 
00401329  |.  E8 623A0400   |call    00444D90                        ; \mofooter.00444D90

ここでeaxが指すメモリーを見ると以下のようになっている。

01 23 45 67|89 AB CD EF|FE DC BA 98|76 54 32 10|
F0 E1 D2 C3|00 02 00 00|00 00 00 00|40 00 00 00|
40 4F 73 53|62 54 5C 7E|59 57 53 42|55 45 7A 57|
61 47 7A 5B|42 4F 7B 61|5D 66 5E 7A|42 7F 40 63|
79 66 05 55|79 4C 60 42|02 10 36 36|36 36 36 36|
36 36 36 36|36 36 36 36|36 36 36 36|36 36 36 36|

先頭32バイトゴミ無視して0x36とxorすればconsumer secretが得られる。

2010-03-22

http://anond.hatelabo.jp/20100322042642

ほんと、そのへんが、プログラマの領域だと思う。

俺はそうは思わない

コンパイラの賢さを考えると、人間が注力すべきは、プログラム全体のアルゴリズムであって、姑息最適化じゃない

コンパイラが出力するコードは、人間が書くコードよりも、圧倒的に賢い

 

まず、基本ブロックの入れ替えが起るような、大域的な最適化は、手じゃ絶対に無理

例えば Lazy Code Motion (PLDI '92) を手でできる人はいないだろうし

partial redundancy elimination が扱っている冗長性を理解している人すら、あまりいないだろう

 

それに、局所的な最適化でもコンパイラ(を書いた人)のほうが賢い(ハードウェアに詳しい)

ターゲットマシンx86 で、レジスタを0で初期化するときに、gcc最適化オプション付けると

xorl %eax, %eax

ってなるけど

subl %eax, %eax

でも

movl $0, %eax

でも無く、xor が一番速い理由を知ってるやつとか、なかなかいないだろう

しかし、gccx86machine description を書いた人間は知っている

2009-03-31

http://anond.hatelabo.jp/20090331020214

数学用語として定着する前の日本語の「以上」「以下」には、等しいものを含まない用法もあったらしい。

つまり、古い用法では、以上は「より上」、以下は「より下」(つまり、未満だな)を意味することがあった。

「~より上でも下でもない」なら「~と等しい」で何もおかしいことはない。

古い用法が今でも慣用的に「以上でも以下でも無い」という言い回しに使われてるんだろう。

数学用語と日本語日常的用法にズレがあるものとしては、たとえば「高々」「または」がある。

日本語日常的用法の「または」は、ORよりはXOR演算に近い語感がある。数学ではORの意味で使うけど。

日本語日常的用法の「高々」は、侮る意味が付加されていることが多い。数学では単に「~を超えることは無い」という意味に使う。

2009-03-26

http://anond.hatelabo.jp/20090326123924

適当ググる。がいくつかあったので羅列

str.charCodeAt(0) + str.charCodeAt(str.length-1)
(str.charCodeAt(0) + str.charCodeAt(str.length-1)) * str.length
    while (*key != '\0') 
        hashval += *key++;
    do{
        x = (x * 0x60 + *s - 0x20) % hashsize;
    }while(*++s);
/* ハッシュ値算出ルーチン */
/* 各文字コードを左に3シフトしたものでXORをとり、 */
/* ハッシュテーブルのサイズで割った余りを返す */
int HashCalc( SearchData )
char *SearchData;
{
  int HashValue;

  for ( HashValue = 0 ; *SearchData != '\0' ; )
    HashValue ^= (int)*SearchData++ << 3;
  return( HashValue % HASHSIZE );
}

2009-01-04

http://anond.hatelabo.jp/20090104122556

なぜか慣例的に^でべき乗は、いまだに見る気がする。

^は私にとってXORなのだが。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん