2013年7月31日 星期三

儲存密碼的方法:Java 的 Scrypt KDF 演算法

使用 Scrypt 的原因可以參考 [1-2],其中 [2] 是比較主要的原因~
大概是說一般常見的密碼儲存方法是使用 One-Way Hash Function 來把密碼變成一串亂碼,儲存在系統上
但不管使用哪種雜湊演算法,其實都不夠安全~主要原因來自於雜湊演算法的兩點特徵:

2013年7月28日 星期日

取得放在專案資料夾內的圖片

在 eclipse 的專案中,要讓程式取得放置於專案內的圖片檔案,可以利用 Source Folder 來達成。

2013年7月27日 星期六

JFace 的必備 library

在嘗試使用 SWT + JFace [1] 時,想要用手動的方式匯入 JFace 需要的 library
因此記錄一下使用 jFace 要自己放入的 library 有哪些。

2013年7月25日 星期四

WindowBuilder:Java GUI 的 WYSIWYG 編輯器

前幾天被問到要用 Java 做簡單的視窗程式,希望很快就寫出來,不要花太多時間
不過因為需要做 GUI,當時心裡想~用 .NET 寫的話可以靠 Visual Studio 拉介面
產生 GUI 的速度會遠比用 Java 自己打程式碼快得多。
回家之後查了一段時間,無意間發現了 WindowBuilder 這個工具,而且是 Google 提供的開發工具!
後來看了一下網路上的資料,有人說原本是 Instantiations, Inc. 開發的付費工具,後來 Google 買下來以後就改成免費提供了。
真實性不清楚,也沒有仔細去查,不過總之現在它是 Google 提供的免費開發工具就是了。

2013年7月11日 星期四

在 Java 使用加密演算法(六):KeyGenerator、Cipher、工作模式與填充方式之間的關係

記錄一下有關 KeyGenerator(在這個主題中,可以替換為 KeyPairGenerator 或 KeyFactory) 與 Cipher 之間的關係。

keyGenerator 是用來產生 Key 的產生器,取得 KeyGenerator 的實體必須透過 getInstance() 方法,同時需要輸入使用的演算法的名稱。
Cipher 則是用來進行加密、解密的工具,取得 Cipher 的實體也必須透過 getInstance() 方法,同時輸入要使用的演算法名稱。

2013年7月10日 星期三

(書籤) MongoDB transaction

暫存一下,還沒有很仔細在看內容,不過大略看了一下,有注意到這個實作 MVCC 的 transaction 的方法
每 commit N 個操作,必須送出 2N+2 個資料庫指令....
不知道這划不划算~目前覺得好像有點不划算。

參考資料:
1、MongoDB transactions?
2、GitHub:MongoDB transaction example

2013年7月9日 星期二

Word 標題自動按階層編號

記錄一個跟寫程式無關的小事~
在 Word 裡面想對某個樣式做階層式的自動編號時,可以利用「多層式清單」的功能
搭配增加縮排/減少縮排,就可以達到讓某個樣式自動生成想要的階層的清單。

2013年7月8日 星期一

在 Java 使用加密演算法(五):使用 RSA 加解密長資料的另一種實作方法

原本使用前篇「在 Java 使用加密演算法(三):使用 RSA 加解密長資料」中寫的方法在做 RSA 加解密
但不知道為什麼突然跑出 javax.crypto.BadPaddingException: Data must start with zero 的 Exception
找來找去都不知道問題出在哪.....後來查到 [1] 時發現好像有比較簡潔的寫法...。

2013年7月5日 星期五

在 Java 使用加密演算法(四):使用 Jasypt 與 Bouncy Castle 產生雜湊

要在 Java 做加密方法好像有不少,之前也曾 PO 過以內建的方法產生加密的文章。
不過基於希望程式碼簡潔、容易呼叫,並且能夠支援更多的加密演算法,所以還是嘗試找了一下
根據在 StackOverflow 社群上的問答 [1],在這裡嘗試了使用 Jasypt 與 Bouncy Castle 作為產生雜湊碼的方法。

(書籤) Open Source License

記錄跟 Open Source License 有關的書籤~。

GNU GPL

GNU LGPL

Apache License Version 2.0
自由軟體鑄造場:利用 Apache-2.0 程式所應遵守的義務規定
有時候使用者利用 Apache-2.0 程式的方式,也可以不要去改變該程式原來 Apache-2.0 的授權宣告,在這樣所產生的新專案中,除了 Apache-2.0 程式碼外,還併存有自行開發的封閉專案程式碼。此時,Apache-2.0 授權的部份如果在散布時願意提供源碼的話,散布者仍可以自發性的提供源碼,但依 ASF 的解釋(同註二),如果散布者轉以不提供源碼的方式來運用此一原以 Apache-2.0 授權的程式,亦可。此時最低的義務性要求,就是散布時須一併提供 Apache-2.0 授權條款的全文,以及該程式前手已註解的相關聲明。所以,如果是採後者將專案整體程式碼封閉起來的利用方式,那筆者建議此時專案整體著作權與授權聲明的說明文字,求其簡便之故,可在適當的位置加入如下的簡要資訊來滿足 Apache-2.0 授權條款要求的標示義務,這些適當的位置可以是圖形化介面中的「關於 (About)」下拉選單、嵌入式裝置所附隨的說明書,或應用程式安裝過程中所出現的著作權與授權資訊頁面