雜湊、訊息鑑別碼與簽章

最近剛翻完Understanding Cryptography這本書，內容真的是淺顯易懂，每章的最後也都會附上相關的參考跟深入研究可讀的參考資料，是本適合當入門的好書，看完之後，想通了雜湊、訊息鑑別碼與簽章三者的差別，在這裡筆記一下，這三個對應的英文分別是 Hash, Message Authentication Code (MAC) 和 Signature，都是訊息傳遞時，用來檢查訊息內容有無「問題」的演算法，三者相似但有些許不同，主要是要對付的問題不一樣。

當我們要傳送一大筆資料時，我們必須要驗證傳送的正確性，沒有錯誤或遭人修改，最基本的就是使用Hash 雜湊，概念就是把傳送端的資料攪一攪，吐出一段代表這份資料的值，接收端再把收到的資料攪一攪，看看出來的值是否一樣。

我們要求Hash 至少要有這些特性：
* 任意長度的輸入，固定長度的輸出
* 要快：如果傳資料要花一秒，算Hash 要十秒，有人要用嗎
* 輸入少量——即便是一個bit 的變動——也應該要讓output 完全不一樣
拿果汁機當比喻，好的果汁機要能攪拌任何輸入的食物並給你一杯新鮮可口的果汁，還要很快攪好，最後，當你攪蘋果汁時加了一些些咖哩，它也要把咖哩分子均勻散佈到每一口蘋果汁裡，打成一杯美味的咖哩蘋果汁(X

另外有Hash三個安全性的要求：
* 從輸出推不出輸入(preimage resistance)
* 給定一個輸入和它的輸出，攻擊者無法產生另一個輸入有同樣的輸出(second preimage resistance)
* 攻擊者無法產生兩個輸入有同樣的輸出(conllision resistance)

知名的Hash如md5, SHA-2，在傳檔案不希望有毀損時，用這些雜湊驗一下是不錯的檢查。

要注意的是，hash 的演算法都是公開的，所以如果有心人Oscar偽造一筆資料跟它的Hash值送給接收端，這筆資料會被誤信為真的資料，Hash 無法對付有心的第三方偽造的攻擊，要對付這種狀況就需要MAC。
MAC和hash 一樣，對一組輸入產生代表的輸出，但MAC除了Hash 的特性外，還會要求一把key，在共同擁有這把的key 的雙方，能驗證訊息完整(integrity)，也能確定訊息無法被沒有key的第三方偽造，因此MAC 有時又稱為Keyed Hash Function。
再拿果汁機當例子，共有的key 就像某種獨門配方…像金克拉吧，攪咖哩蘋果汁的時候放點金克拉進去，只有用了金克拉才能吸收土壤兩米下的氮磷鉀攪出金克拉風味咖哩蘋果汁，其他人就無法偽造出這獨特的金克拉風味。

但再進一步，MAC並不提供”不可否認性”，MAC雙方共有這把key，他們都可以產生可被驗證的MAC訊息，這就像有人可以故意打出「有杏仁味的金克拉風味咖哩蘋果汁」然後說是我打的，那我不是冤大頭？這時我們就需要簽章Signature：
簽章跟MAC差異不大，只是我們把hash value 用非對稱演算法的私錀加密過，並公布它的結果，這樣所有有公錀的人都能驗證這份資料是我簽的，卻無法偽造這份簽章；另一方面，我也無法否認這份資料是我簽的，這就是”不可否認性”，這在晶片卡、網路交易上有極大的應用。
就像攪果汁的時候，吐點口水進去，所有人都能驗我的DNA，證實是我攪的果汁；但DNA就只有我有，任何人都無法偽造。

簡而言之，如果你拿訊息過來攪一攪，那是雜湊；攪一攪的同時加上一把通常是對稱性的金錀，這變成MAC；如果產生的過程用上你的私錀，用非對稱加密演算法處理過，就成了簽章。

Star Wars ep 7 Force Awaken原力覺醒(有電)

期待已久的Star Wars ep 7 force awaken 總算上映，又正好趕上放假立馬去看，不用叫子孫燒給我了XDD

整體表現不俗，就跟Star Trek ep 11一樣，是個重開機作品，JJ Abrams 善於利用高速鏡頭，對準一個主體帶出巨大的場景，這在Star Wars上非常適得其所，把戰機間的狗戰拍得相當帥氣。
劇情是全新設計，就算ep 1-6都沒看過應該還是看得懂，也許會對角色口中Luke, Leia, Han這些人物不太熟悉，不過當他們是前輩就好，隨著劇情他們的身分會逐漸揭露，唯一從劇情了「比較」看不出來的，大概就是Darth Vadar，只有一句台詞帶過。

為了連結過去，先看過ep 4-6 還是比較容易上手，也能看出片中一些場景道具是在指什麼，或是向某個東西致敬，像我看到沙漠裡巨大的AT-AT 跟滅星者，想到ep 4-6 它們曾是讓反抗軍聞之變色、如同Borg Cube 一樣恐怖的存在，現今卻淪落在沙漠中腐朽，不禁讓人感慨輝煌一時的帝國，大概也像武器一樣祇剩過往的榮光；而新共和與絕地勢力尚未壯大，電影開頭就跟那片沙漠的拾荒者一樣，給人無限蒼涼的感受。

世界觀的部分，整片的世界觀其實很破碎，沒有太多著墨，究竟新共和跟反抗勢力的關係是啥？反抗勢力經過了這麼多年，竟然還是只有一個前線基地，拿X-wing 機群突入為主力，而沒有可跟滅星者相抗衡的主力艦隊？First Order 又是代表整個舊帝國，還是前線跟反抗勢力作戰的主力？不過這些都算是細節，忽略掉沒關係，一開始就是從邊境星域開始(就如同Tatooine 一樣XD)，可能雙方主力都鞭長莫及，所以不是劇情重點，或許隨主角一步步深入核心，這些內容會在 ep 8-9 補齊。

我覺得這部表現最讓我失望的是它的音樂，可能是被東方系列養慣的關係，現在非常注重電影主題配樂，而不只是聲光效果；以往的星戰影片產製了很多扣人心弦的音樂，開頭畫面的 Star Wars main theme，ep 5的帝國進行曲(Imperial March), ep 1的duel of fate, ep 2 across the star，六集內我評價最低的ep 3 也還有the great duel 這首，雖然混了其他配樂但還有個連音緊湊的基調。
這部我看完卻沒什麼有印象的配樂，好像都是舊配樂拿上來充場面？沒有某人某物「主題曲」的感覺，隔壁棚的star trek 也有類似的問題，ep 11 音樂我非常滿意，像Enterprising Young Men，到了ep 12 Into darkness 卻沒了，頂多是一開始的London calling，大部分場面只剩爆炸音效，少了音樂把整個場面襯出來，希望未來兩集能多加強這部分。

總評來說，這集可算是星戰的全新入門款，不但承先也啟後，幾乎所有的概念都Reset ，舊作的角色出來串場但絲豪不影響主角戲份，很簡單就能從新角色的視角，重新體會這個風靡全球的遙遠銀河。

準備好了嗎？進電影院感受Star Wars Theme 的震憾，享受最新的星戰鉅作吧。

Google App Engine 回應動態內容

文章標題是照翻原來的內文：Dynamic Image，這次試著處理聲音，發現一樣可以使用，就記錄一下，相關內容可見：
https://cloud.google.com/appengine/articles/python/serving_dynamic_images
http://www.renepedersen.com/2010/04/12/how-to-serve-images-dynamically-from-google-engines-datastore/

找一下舊文章發現上一篇類似主題竟然是七月的事：
http://yodalee.blogspot.tw/2015/07/google-app-engine-ajax-request.html
well，畢竟在陰間不好辦事，又遇到base64 decode的問題，弄了很久一直沒進度，這次放假問題解掉了，順利把資料送到後端；問題有兩個

一個是我之前把資料放在url 裡面一起送，結果base64 string 的'+'全變成space，後端python base64 module decode不出來，本來是用一種很蠢的解法，先讓資料經過data.replace(“ “, “+”)，結果deploy 的時候遇到問題二：資料放在url 裡面有長度限制，應該要放在send資料裡才對，連帶這樣也沒'+'被取代的問題，詳情寫在上面那篇文內。

資料送到後端，寫入google app engine 的ndb 資料庫，這部分請參考：
https://cloud.google.com/appengine/docs/python/ndb/
很直覺，先建一個class 把該有的資料庫項目填進去，不管影像或聲音都是ndb 的BlobProperty

class RecordFile(ndb.Model):
  content = ndb.BlobProperty(indexed=False)
  date = ndb.DateTimeProperty(auto_now_add=True)

這是prototype 的關係，只記了兩個欄位。

在upload handler裡面，就可以用put()把資料寫到資料庫裡，用Key的get可以把資料再取出來：

recordFile = RecordFile(content=decoded)
retrieveKey = recordFile.put()

要怎麼把取出來的blob 塞進html 裡面？
這裡首先要寫一個Handler負責取出資料庫裡的BlobProperty，然後把binary 直接寫出來：

class GetAudio(webapp2.RequestHandler):
  def get(self):
    recordFile = retrieveKey.get()
    if recordFile.content:
      self.response.headers['Content-Type'] = 'audio/wav'
      self.response.write(recordFile.content)

再來我們要把跟圖片/聲音的request 都轉給這個handler，這裡我是假定跟/wav有關的url 都轉給它，在handler register加上這行：

app = webapp2.WSGIApplication([
('/wav', GetAudio),
], debug=True)

最後我們就能在圖片/聲音 tag 的src後面，直接寫上/wav, /img之類的網址：

<audio controls>
  <source src="/wav?key=XXX” type="audio/wav">
  Your browser does not support the audio element
</audio>

我這裡當然不是真的寫XXX，實際上的做法是{{ key }}，再用JINJA2的render把資料塞進去，一樣的方法也適用圖片上，寫個/img 的handler 並把image 的blog 寫回去即可。

安裝Minecraft Shader

這次放假回家，試著在Minecraft 上面安裝Shader，這裡記一下過程與結果。

試了之後發現，原本要裝GLSL Shader MOD 現在都不用了，1.8 的Optfine 已經把Shader 選項整合進去，只要安裝Optifine 即可開啟Shader 選項
http://minecraftsix.com/optifine-hd-mod/
而且Optfine 的安裝也變簡單了，直接執行載下來的jar 檔就能安裝完成，跟以前手動把jar 檔拆開，把檔案複製進去，刪掉Meta-inf一堆步驟，不小心還會爆開要刪掉重裝的過程根本天壤之別。

裝完optfine再來就可以去載Shader 來玩了，這邊有三個shader可以載，列表打開也有一排shader任君選擇，不過我覺得看多了其實大同小異，通常還是用Sonic Ether's Unbelievable Shaders medium
http://minecraftsix.com/glsl-shaders-mod/
不過Shader 開了，為求效果通常把亮暗對比調得很高，這其實很妨礙建築跟探險，所以只限於拍照用。

另外是一個插曲，一開始裝好的時候，不管是哪個shader，打開畫面都會一片漆黑，下面出現類似：
Invalid program: final
Cannot create FrameBuffer
之類的錯誤，後來發現我沒用Optirun開，使用的顯卡是Intel 的HD Graphics 4000，可能是程式不相容不然就是顯卡不夠力，總之顯示不出來；後來用了Optirun 用筆電的nVidia GT 640M才一切正常，這是顯示結果：

世界變得好漂亮lol。

話說回來，這根本是在虐待顯示卡，用Ultra 的shader fps 都會降到 24左右，移動時畫面看得出頓點，用medium才能回到50 fps，而且以下個人意見：打minecraft 最好玩的還是徒手打造理想世界的那股衝勁，還有完成它的成就感，shader充其量只是裝飾的工具，真正強大的顯示卡，其實是你我的想像力呀。