標題: Irreversible Encryption Algorithm [打印本頁]

---

作者: samiux    時間: 2014-8-30 11:27     標題: Irreversible Encryption Algorithm

本帖最後由 samiux 於 2014-8-30 19:04 編輯

Mr. Benny Tai (戴耀廷) said that the information at 6.22 Civil Referendum website (https://secure.popvote.hk) is encrypted by irreversible encryption algorithm.

The information that the website keeping is the Name, HKID card number and telephone number of the voters.  Suppose that the HKID card number and telephone number are encrypted by irreversible encryption algorithm.

There are a number of encryption algorithm available in the market.  I suppose Mr. Benny Tai will not create a new encryption algorithm for the voting.  That means, the website will use the available encryption algorithm.  The irreversible encryption algorithm is similar (or same as) to produce a hash value of the original string or data, such as MD5, SHA1, SHA-256 or RSA.

There are a number of hash cracking tools in the market.  Those tools can detected the encryption algorithm that used by the hash value automatically.

The website only allow Hong Kong citiizen to vote.  That means, the HKID card number should be in the following format - A123456(7).  There should not be XA123456(7) as it is for foreigner only.  Therefore, the first letter should be one character from A to Z.  And follows by 6 numeric.  Then the character in the bracket should be between 0 to A (that is 0123456789A, it is module 11).  The policy of the HKID card is very easy to predict.  Meanwhile, the telephone number is only 8 numeric.  As a result, we got the policy of HKID card number and telephone number.

As I said before, the hash cracking tools can detect the encryption algorithm automatically.  We can apply the HKID card number and telephone number policies to the hash cracking tools, such as hashcat or oclhashcat (http://hashcat.net/oclhashcat/), and we can crack the irreversible encryption data very easily.

This article is based on my presumption only.

Update reason : typo fix

---

作者: snoopy11hk    時間: 2014-8-30 13:04

本帖最後由 snoopy11hk 於 2014-8-30 13:08 編輯


according what he said, it should be a encryption algo + a hashing algo
but i suspect that PRC can crack it using the DDOS troops.

---

作者: samiux    時間: 2014-8-30 13:26



If so, it should be a little bit complicated only.

Samiux

---

作者: snoopy11hk    時間: 2014-8-30 13:47



it is no use against the DDOS password crack

---

作者: samiux    時間: 2014-8-30 13:58



I don't understand what you mean.

Anyway, I think the web server cannot do a lot of encryption or/and hash algorithm in the real time as it requires a lot of process power (CPU power here) to do so in term of performance and security.  

Samiux

---

作者: snoopy11hk    時間: 2014-8-30 14:09




    i mean cracking using the distributed computing...

---

作者: KoolFreeze    時間: 2014-8-30 14:55



Is distributed computing necessary?

According to the benchmark by oclHashcat, a single typical computer with a decent GPU can easily achieve hash rate 1000 million tries / s.

HKID has only 26 * 10^6 (1 letter + 6 digit) combination = 26 million

By simple calculation, we can reverse the "irreversible" hash in 0.026s, or 26 millisecond, less than ping time from my computer to Google.

It's irresponsible for Mr. Tai to claim that the data can't be decrypted.

---

作者: KoolFreeze    時間: 2014-8-30 15:05



^ It seems that what they meant by encryption is just SSL!? It should be irrelevant if the hacker cracked the database.

---

作者: dsscss    時間: 2014-8-30 17:18

本身DESIGN無透露, 跟本就好難評估...
你唔可以話佢易CRACK,
又唔可以話佢難CRACK...
因為無相關資料提供...

HASH的話通常會配合埋SALT, 唔係就咁HASH就算...
而SALT的話會用幾多BIT呢?
這些都會增加破解的難度...

---

作者: Charcoal99    時間: 2014-8-30 18:15

unreservable  ???
Do you mean irreversible.

---

作者: snoopy11hk    時間: 2014-8-30 18:58

本帖最後由 snoopy11hk 於 2014-8-30 19:01 編輯



    what if they used an encrypted algo before hashing?
e.g. AES-256 + (SHA-256 + Salt)?

---

作者: samiux    時間: 2014-8-30 19:05


My bad,  thanks.

---

作者: samiux    時間: 2014-8-30 19:15

Due to the performance of the web application,  the data should be MD5  + salt.   If it is too complicate,  the web application will response very slowly.

Samiux

---

作者: Charcoal99    時間: 2014-8-30 20:46

原文是這個 https://popvote.hk/english/project/vote_May2014/privacy/
佢地無話到個 algorithm 是irreversible, 只是話果堆gen 出嚟嘅 HashCodes 無法reverse 為原本嘅 data,
只能比較新輸入data 所gen 嘅 HashCode, 看有沒有重覆，僅此而矣。
而且佢嘅陳述重係  effectively no one can reverse or decode them.

---

作者: KoolFreeze    時間: 2014-8-30 21:19

本帖最後由 KoolFreeze 於 2014-8-30 21:28 編輯


In the article PopVote: A Revolution in Gathering Opinions in Hong Kong in year 2013, the following sentence is included at the section "Future Development"

"As for privacy, a random salt can be added to data before hashing to make it difficult to work out the original data by the hashed pattern, while iterating the hashing process a few more times will increase the difficulty of hacking."

So we can be sure that at least in the past, PopVote did use single iteration plain hash without salt. It's still unknown whether it has implemented it now.

---

作者: samiux    時間: 2014-8-30 21:33

本帖最後由 samiux 於 2014-8-30 21:34 編輯


The statements at https://popvote.hk/english/project/vote_May2014/privacy/ is not for the 6.22 Civil Referendum.  The data destroy date should be later than June 2014.  I think the data has not been destroyed until now.



Samiux

---

作者: samiux    時間: 2014-8-30 21:40



According to http://hkupop.hku.hk/english/columns/columns153.html, it stated that :



However, how to explain the data captured by the hacker here? (http://www.freebuf.com/articles/web/41533.html)

The HKID numbers and the telephones have not been hashed or encrypted.

Samiux

---

作者: KoolFreeze    時間: 2014-8-30 22:25



It's their future development , so they probably haven't done it yet.

BTW, has anyone here verified whether the data captured by the hackers are really those from PopVote? They only released a password encrypted .7z file. HKU claims otherwise.

Unless the data are verified, we can't exclude the possibility that the "hacking" is a completely fake attack that didn't happen.

---

作者: samiux    時間: 2014-8-30 22:43

本帖最後由 samiux 於 2014-8-30 23:24 編輯


The dump.7z is password protected.  There are some tools to crack this kind of protection.  The only things are time and money (the electricity bill).  By the way, the size of the dump.7z is only 2MB in size.  It seems only a part of the whole database.

According to the screenshots, it seems that the data is from the server of popvote.hk but not sure it is from https://secure.popvote.hk or not.

I have read the news that some of the HKID card numbers and telephone numbers owners on the screenshots confirmed that they are the voters but some claimed not to be (if they are telling the truth).

Update reason : typo fix

---

作者: wdtech    時間: 2014-8-31 00:58

利申: 係中學讀過電腦科咁大把, 以下乃個人知識最真切見解。有錯就笑一下就好
讀得書少, 唔太識(打)英文

1) Hash function既大概原理係將資料(data) 變成一D index. 如有31個學生, 阿john 既香港考試及評核局[會考學生號]係 01, Marry 係 02... Peter 係 31.
你問Marry, 佢永遠會答你佢會考學生號係 02. 但如果你係街邊執到份HKEAA 既試卷上面好多個大交叉, 而個[會考學生號] 03, 其實你想找返個學生出黎恥笑既機會係零。因為你都無個table (or algorithm, de facto) 可以俾你對返係邊個學生豬咁蠢....

2) 而? 但唔係有D叫oclHashca 既野可以俾你Brute-force attack D hash 既??
係, 但其實你要知個 hash 既algorithm, 之後對返個program randomised 既data 如 (sorry*for%my!ignorance1, sorry*for%my!ignorance2, sorry*for%my!ignorance3, sorry*for%my!ignorance4..... ) 既hash 同你手上偷返黎既data 個hash 係唔係一樣. 如一個32byte 既hash, 理論上係有16^32 既組合(combinations) (而唔係26 * 10^6...... 因為我地係crack個hash) . 當然, 世上有D叻人會用number theory 去將collision attack 既combinations 次數減少。[好老實, 如果我係叻人, 我唔會有時間去打D野俾大家笑甩牙]

3) 唔係wo, 我知有D情況, 我用D program 好快會crack 到個(e.g.) MD5 password!?
呢個咁既情況, 我地只可以怪D人唔正確咁用hash function 去store 個password.
好似我用google, 查散列值字典"d5aedf560b928e289dc4a76d8765bc4e" 就會出到佢係"newbie" 既MD5 hash. 其實如果寫database program 個newbie 係個hash function 加d鹽 (糖好似唔得), 就唔會出事....

4) "所有以電子方式收集的個人資料會於傳送時使用SSL進行加密，並會以不能還原的散列代碼形式記錄於伺服器，以確保有關資料實際上無法被人破解和還原。"
請留意"並會" 這兩個字

5) [個人意見] 佢D用紅線mask 左既身份證號碼, 點解好似有D mask左一個字, 有D兩個字。搞到我覺得身份證號碼有D共有8個字, 有D有9個字咁得意

最後, 如果popvote 係在手機apps generate hash (md5, sha-256 etc) 再加鹽 再用SSL/TSL 建立安全連線到database, 而又無機會俾人middle man attack, 個人資料理應安全, "can crack the irreversible encryption data very easily." 未必成立。

最後八掛問一問, 各位大大對cryptography 有什麼經驗和心得 (用crack tool 不計)。小弟/女在此拋磚引玉。完

---

作者: samiux    時間: 2014-8-31 02:12

本帖最後由 samiux 於 2014-8-31 02:13 編輯


First of all, my English is not good indeed but I cannot input Chinese.  My bad.

In the view of a hacker, hash with or without salt can be cracked.  The key is time and money (electricity bill).  As far as I know, you can identify the type of hash by the structure of the hash, such as MD5, MD5+salt, and etc.  The typical cracking tool - John the Ripper can detect the type of hash automatically.

Basically, oclhashcat can handle hash with or without salt (please see below).  As oclhashcat uses OpenCL or CUDA to crack, the performance is quite good, such as 15445M c/s for a AMD HD7970 display card.  (where c/s stands for crack per second and M stands for million).  If oclhashcat combines with password/hash policy, the time of successful cracking will be reduced a lot.

The basic operation of cracking tools is to compare the hash of the generated string/data and the original hash.  If the hashes are matched, the crack is successful.  The cracking tools are not cracking the hash.  They are comparing the hashes instead.  If the cracking tools are working with password/hash policy, such as oclhashcat, the cracking time will be shorter.  The password/hash policy of HKID card number is mentioned at the Post #1, please refer to that.

The following is the list of algorithms that oclhashcat can handle :


The following is the cracking speed of oclhashcat :

[youtube]vD9AFcGW5lY[/youtube]

To answer your (Item 5).  Basically, HKID card number has maximum 2 letters in front.  For Hong Kong citizens, the letter is range from A to Z (single letter).  For foreigners, it should be two letters, such as XA, XD, XE and etc.  However, this policy is changed after 1997.  For example, domestic helpers, their HKID card numbers letters will be W or WX.

The screenshot shows on the top portion - users enter their HKID card number from the second letter of the input field.  While the bottom portion of the screenshot shows - users enter their HKID card number in the beginning of the input field.

One thing that I should mention is that the HKID card numbers and telephone numbers are not hashed and they are stored in the database in plain text from the captioned hack.

Finally, if the data is hashed with salt and transmitted via SSL, the data still can be cracked if the hacker can access the database.  The key is time and money.  With the help of oclhashcat, the time will be reduced a lot if working with suitable hardware.  Cracking tools are comparing the hashes instead of cracking the hash, you should keep in mind about that.

Meanwhile, the hash algorithm used in web application is usually MD5 or MD5+salt due to the performance.  If the web application uses SHA-256 as hash algorithm, the web application will response very slowly and it will looking like hang when it is busy.  

I am not a computer science expert.  I only express my point of view in term of a hacker.

Update reason : typo fix

---

作者: snoopy11hk    時間: 2014-8-31 02:49

本帖最後由 snoopy11hk 於 2014-8-31 02:50 編輯



    If the web application uses SHA-256 as hash algorithm, the web application will response very slowly and it will looking like hang when it is busy.

I wonder if popvote will out source most of the work load to the browser (i.e. Javascript asymmetric encryption/hashing)

---

作者: samiux    時間: 2014-8-31 07:16



In my opinion, if the hash generation is at the client side, it is not wise to do so in term of security.

Samiux

---

作者: tsangwailam    時間: 2014-8-31 09:27

用sha256 應該都唔會太慢，佢submit result先做一次，或者係佢係client己經做左，send出去己係hash code，係server加salt再md5 hash一次，勁難先解到。

---

作者: stephenwong    時間: 2014-8-31 10:01

本帖最後由 stephenwong 於 2014-8-31 10:03 編輯

What you guys said, using GPU, blah blah blah, can find out the original plaintext of hash codes, captured by PopVote, 'easily', it's simply wrong.  You made a wrong assumption that there is ONE hash for HKID, ONE hash for telephone number, and you know the combinations of 'alphabets' in HKID, and telephone number are limited, so, you can 'easily' exhaust all the combinations and compare with the hash (to find out the original HKID and telephone number of the voters.)  There must be a data structure to put the HKID and telephone number before hashing is applied.  Usually, the data structure will be of some fixed size (or padding will be applied), for example, if the data structure is 16 bytes (128-bits) in size, you don't know which bytes correspond to HKID and which bytes are used to store telephone number.  Although the plaintext still won't exhaust all 2^128 combinations, due to some plaintext combinations are not valid (eg. no such HKID, no such telephone number), you can't reduce your brute force trial space.  Because you don't know the data structure in the first place.  Assume you can achieve 10,000M hash per sec, you still need roughly 1E28 years to find out the plaintext of a given hash.  This has nothing to do with 'salt'.  Without 'salt', if you have enough time, you can generate a 'dictionary' of all 2^128 hash codes correspond to all possible plaintext combinations, and with the dictionary, you can find out the plaintext by searching your 'dictionary'.  By adding 'salt', you just make the 'dictionary' approach even more complex, say, if you add a 2-bytes 'salt', you add 65536 times complexity, because there are 65536 dictionaries to be generated.

But hey, I just illustrated an example IF the data structure is 16-bytes in size, who knows if the data structure is 64-bytes in size, 128-bytes in size.  You cannot tell from the hash how big was the original plaintext!

You guys also question how the apps work, whether the hash and encryption was done on the client or on the server.  There are a lot of possibilities, and even the hash and encryption was done on the client, it can be designed such that you won't be able to cheat, say, by adding a round of asymmetric cryptography.  

You said, the server won't be able to handle the encryption / hashing?  You must be joking, there were 700k voters in the last PopVote?  A simple Intel i5 can sustain easily 20MB to 30MB AES encryption per second.  Just like using Bitlocker in Windows, usually, the bottleneck is still the speed of your hard disk.  Those 700k voters did not vote in the same second (but spread in a few weeks), so, don't worry about the server, worry more about the DDoS attack from North!

---

作者: KoolFreeze    時間: 2014-8-31 13:50



How can you know that assumption is wrong? Are you the developers of PopVote?
You are also making an assumption that the developers of PopVote genuinely care about security and know the right way to implement it, which might be also a wrong assumption.
Maybe the developers are lazy so they just implement it with the simplest way possible to satisfy the request of their boss.

---

作者: dsscss    時間: 2014-8-31 14:50

回覆 26# KoolFreeze

你唔明白佢既意思...
總括 0黎 講,
佢成段既意思就係話
1) 一開始既ASSUMPTION已經係唔 0岩, 因為你唔知佢點樣IMPLEMENT...
本身個FACT係唔 0岩 既話, 你唔可以再用呢樣 0野 推論落去..

2) 正常情況下(即係唔係用DDOS攻擊),係唔需要考慮HASH 既PERFORMANCE.

就好似我之前講,"你唔可以話佢易CRACK,又唔可以話佢難CRACK,
因為你都唔知佢點IMPLEMENT"
...

---

作者: stephenwong    時間: 2014-8-31 15:17

I also has my own assumption, the PopVote developers, supposedly some RAs working in HKU, were properly trained in computer programming / security implementation.  Of course, I don't have a chance to see the actual code, but for a secured system, it doesn't matter the source code is published or not.  Digital security is basically an art of very large permutations.  You can brute force try all combinations, but it will take a long long time, that's it.

Well, put data into a data structure (record) is also an assumption, but it is so basic that any programming course will teach data structure in a very early stage.  So, if the developers did not put data into a record (and hash that afterwards), I don't think those developers are qualified.

---

作者: samiux    時間: 2014-8-31 16:40



In the first beginning, I assumed that the data is hashed or encrypted according to official wording.  The GPUs and oclhashcat as well as HKID card number policy can made the job done easily but it requires two keys, that is time and money.  The more complicate it is, the more time and money it requires for the cracking as well as lesser performance of the web application is.  For the performance of hashing or encrypting, we can setup a lab for the experiment of hashing/encrypting of 10+ threads in parallel.

As far as I know, the https://secure.popvote.hk is installed on AWS (Amazon Web Services) and behind Cloudflare protection.  The AWS and Cloudflare are situated in USA (very far away from Hong Kong).  I think the bandwidth of voters (2.5G to 1Gbps) is also important for the performance too.  You will find out that MD5 or MD5+salt have the better performance.   I have discussed the DDoS and Cloudflare matter on the site before and I will not going to talk about them here.

However, not related to the topic here, it is very hard to explain this attack (http://www.freebuf.com/articles/web/41533.html).  Why the attacker can extract the data from the database that are in plain text (assumed that the database is from the https://secure.popvote.hk, but it is believed to be from the site according to the screenshots.)?

Samiux

---

作者: Charcoal99    時間: 2014-8-31 17:19

就 20# 那個 screenshot 而言, 數據顯然已經排序了, 就只得這麼少???

---

作者: samiux    時間: 2014-8-31 20:46



The said hacker provides a database dump to download but it seems that the dump is a partial of the database.

Samiux

---

作者: arshum    時間: 2014-8-31 23:39



network bandwidth 唔影響 server 計數能力 ga wor...
無論 server 用 MD5, SHA1, SHA2 做 hash, 佢由 us reply 番去 hk 既 travel time 都一樣架?

留名學野

---

作者: wdtech    時間: 2014-9-1 00:44

其實呢, 如果popvote programming 班友係醒既, 佢可以係client side 先RSA (or other asymmetric key encryption schemes) 個HKID 同電話號碼再hash. 另一方法係用random salt. 但如果佢地真係醒既, 佢地做左都唔會話你知。

另外, 我對 "15,445M c/s" 係完全無興趣。我地擔心既係個 architecture 夠唔夠secure。一個好既implementation 對呢D所謂  "15,445,000,000M c/s" 其實無大影響。

"The cracking tools are not cracking the hash.  They are comparing the hashes instead." 呢方面同意, 因為係Point #2 我都有陳述。

"One thing that I should mention is that the HKID card numbers and telephone numbers are not hashed and they are stored in the database in plain text from the captioned hack."
個hacker 講啫, 無人知係唔係真係621 popvote d 資料。如果條友真係好似佢所講咁清高, 佢就唔會放左個似是而非既 encrypted 7zip 出黎。仲有, 呢個世界有D野叫做honeypot. 如果popvote真係implemented 佢所講既野, 理論係無可能有plaintext 資料係server。出現呢D笑料, 一係hacker講大話或真心膠, 一係 popvote講大話。呢一刻無人知。

"if the data is hashed with salt and transmitted via SSL, the data still can be cracked if the hacker can access the database.  The key is time and money.  With the help of oclhashcat, the time will be reduced a lot if working with suitable hardware. "
我係細果時都好迷戀"速度"呢樣野。但當你大過你就會明白, 黑白兩方係平手既。另如好真係好似你咁講到D algorithm, implementation 等 係咁脆弱，我諗你應該要仲驚過我, 因為最少起碼你EPC dollar 多過我.

"Cracking tools are comparing the hashes instead of cracking the hash, you should keep in mind about that."
唉, 本如想完, 但最終又要回帶 - 呢方面同意, 因為係Point #2 我都有陳述。

"If the web application uses SHA-256 as hash algorithm, the web application will response very slowly and it will looking like hang when it is busy.  "
不解釋: http://www.cryptopp.com/benchmarks.html

學下computer architecture. 學下 programming. 用人地寫出黎既野同自己親手做, 所學到既野同成就感係唔同嫁。其實我年紀係唔細, 所以有時係會長氣D。希望你地呢D後生既, 後浪推前浪

---

作者: samiux    時間: 2014-9-1 04:27

After reading your comment, I remembered that I have read a very interesting article - Speed Hashing (http://blog.codinghorror.com/speed-hashing/).  This article is written in 2012 but what he said is still valid today.  You may not agree with him but it is truth.

I hereby to quote what the author of above link said ("what he said" as below) to reply about bandwidth related or web application response time questions.  Meanwhile, it is not secure to do the hashing or encryption at the client side :




Hereby, I quote what he said to reply about hash algorithms security question :




As I said before, if oclhashcat use with HKID card number policy, the cracking time will be reduced a lot.  It is because the HKID card number policy is too simple.



I am so sorry not to reply you directly.

Samiux

---

作者: polarhei    時間: 2014-9-1 10:46

回覆 10# Charcoal99


算式有兩種, 單向或對稱. 通常, 因為, 發起人要的, 只是數字, 故只有單向. 完成後要按政策銷毀.

---

作者: dsscss    時間: 2014-9-1 21:34

你SHARE既ARTICLE 幾好...
佢既意思係話加SALT都係唔SECURE...
但你要諗 0下 係基於 0羊 SITUATION 先...

就好似樓上某D師兄所講,
你要知道原本羅 0黎 做HASH個STRUCTURE係點排列...
舉個例子..
就算簡簡單單...
只係用ID_NUBMBER做HASH..
HASH(SALT || REVERSE(ID_NUMBER))
同HASH(SALT || ID_NUMBER)
都已經係兩回事...
後者你可以用TOOLS + HACKER既"直覺"..
咁 0岩 估中個STRUCTURE 就俾你CRACK到..
咁前者呢...

JUST MY 2 CENTS...

---

作者: toylet    時間: 2014-9-1 21:46

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: snoopy11hk    時間: 2014-9-1 23:36



did you study computer security before?

---

作者: toylet    時間: 2014-9-2 00:23

提示: 作者被禁止或刪除 內容自動屏蔽

---

作者: samiux    時間: 2014-9-2 01:05



MD5 may has chance to have same hash.  Please refer to the article (http://blog.codinghorror.com/speed-hashing/) or googling :



Update reason : fix typo

---

作者: samiux    時間: 2014-9-2 01:08



As I said before, it involves performance vs security.  Basically, the HKID card number policy is too simple to predict as it is Module 11.

Samiux

---

作者: dsscss    時間: 2014-9-2 01:35

你都係唔明...
你用呢D TOOLS之前點都要PREDICT條FORMULA係點樣組成...
你撞中條FORMULA先算CRACK到...

係SHA256(SALT || REVERSE(ID_NUMBER))
定係SHA256(SALT || ID_NUMBER)
定係SHA256(SALT || SHA256(REVERSE(ID_NUMBER)))
定係SHA256(SALT || SAH256(ID_NUMBER))
定係SHA256(SHA256(SALT) || SAH256(ID_NUMBER))
定係用其他HASH FUNCTION...
等等等等咁多個...

同"the HKID card number policy is too simple to predict as it is Module 11"完全無關...

---

作者: samiux    時間: 2014-9-2 04:09

本帖最後由 samiux 於 2014-9-2 07:22 編輯


As far as I know, the 6.22 Civil Referendum website was written with PHP.  I am not an elite programmer.  Or I am not a programmer even I will write some hacking tools myself.

I do not know if PHP can apply XOR with HASH functions or not.  In my mind, the hash programming in PHP is something like this - http://code.tutsplus.com/tutoria ... rds-safe--net-17577 .

By the way, I already assumed that Mr. Benny Tai will not create a new algorithm or even will not apply a very complicate algorithm on the web application.  

Performance for the web application should be concerned for almost all the web application programmers.

The more complicate the encryption is, the slower the performance of the web application is.  

I admit that hacking is more or less a guessing game.

May be I am not answering your question as I do not know what I am saying.

Samiux

Update reason : fix typo

---

作者: samiux    時間: 2014-9-3 22:42

This article is dated Sept 1, 2014 - http://www.freebuf.com/articles/neopoints/42171.html

Samiux

---

作者: wdtech    時間: 2014-9-10 15:27



After going through all your comments, I would still stand strong on my views - Please put more time and effort in understand what is cryptography. Emphasizing how fast can people crack a (salted) checksum (we call them signature in fact) is not productive.

Currently, many CPUs (x86, MIPS etc) implement instructions that accelerate encryption and signature's generation (e.g. AES NI). Generate hash, especially for just a short string, is not computationally demanding - A good code will work. Your android or iPhone can get the stuff (ok, you want SHA-2, bcrypt etc) done in a few milliseconds.

All the signature are subject to brute force attack. No exception. What we do is in fact get a signature algorithm candidate out (e.g. SHA-1 in 2008,SHA-2 in ~2016) which can defeat the foreseeable "cracking" efforts.

"As I said before, if oclhashcat use with HKID card number policy, the cracking time will be reduced a lot.  It is because the HKID card number policy is too simple."
Contact me if you want: 5630dc3b41a969e4eaa5a734e1d8f6ad40fdc987
Great hint: HKID with "( )" + space + telephone no. -> AES (CBC) -> SHA-1 (no salt)

Hope you get my points - Read/learn, think and practice. I teach when I write - this is my profession.

---

作者: samiux    時間: 2014-9-10 16:02



It sounds like you do not know what is web application programming and its requirement.  Meanwhile, you do not know what is GPU computing (or parallel computing).  I do not have any comment to you now.  Discussion terminated.

---

作者: dsscss    時間: 2014-9-13 00:05

回覆 45# wdtech

算啦...
有咁多個都用心良苦打一大篇文同佢講, 佢都係活係自己世界...

邊個講得 0岩 / 錯, 睇多D 大學LECTURE NOTES / 研究 0下 HASH / HASH KEY SIZE既PAPER就明,
成日話HACKER乜, HACKER物..
連讀U既SECURITY課程我 諗佢都未必上過,
唔識好難講....

---

作者: samiux    時間: 2014-9-13 06:45

本帖最後由 samiux 於 2014-9-13 06:47 編輯

I know that there are many strong encryption algorithm available.  However, the implementation is another thing.

Yoggi Berra says :


I have read an article about implementation of strong encryption in communication software, such as email client.  It is not 100% related to this discussion, but it is worth to have a read :

(1) http://www.freebuf.com/articles/network/42692.html
(2) http://www.washingtonpost.com/bl ... prss=rss_ezra-klein

Samiux

Update reason : fix typo

---

作者: ～虎～    時間: 2014-9-13 16:48

本帖最後由 ～虎～ 於 2014-9-13 16:50 編輯

如果知道佢個Algorithm 又真係唔難解
最白癡 $hash = sha1($hkid . $phone); 的話
Enumerate哂所有Combination出來 一個Rainbow table就KO佢

加左Salt又唔同玩法... 每個Hash都唔同Salt, Rainbow table就廢武功
$salt = some_random_strong_salt_func();
$hash = $salt . ':' . combination_of_some_strong_hash_func($hkid, $phone, $salt);
CPU解又好, GPU解又好, Quantum Computer解都好 Cryptography從來都係時間問題...

樓主講HKID + Phone本身Data既Combination太少係事實
但佢地係咪真係用Weak Hash Algorithm只係推測

---

作者: dsscss    時間: 2014-9-13 18:32

回覆 49# ～虎～

>>HKID + Phone本身Data既Combination太少係事實
COMBINATION小 =/=容易CRACK.
可以SHA256(ID || ID || PHONE || PHONE)
又可以SHA256(ID || REVERSE(ID) || PHONE)
又可以....好似我只前講咁多COMBINATION...

你講到咁簡單..
不如我提供1萬個RAW DATA, 連埋個HASH 0左 既RESULT俾你,
你講返我用乜方法 0黎 做HASH吧.

過左一佪月, 你解到我就俾一萬你,
你解唔到就俾返一萬我,
好嗎?

---

作者: Sodi    時間: 2014-9-13 20:16



樓主解了 #45 大大出的先啦..........
===========
Contact me if you want: 5630dc3b41a969e4eaa5a734e1d8f6ad40fdc987
Great hint: HKID with "( )" + space + telephone no. -> AES (CBC) -> SHA-1 (no salt)
===========

---

作者: samiux    時間: 2014-9-13 21:26

It is very interesting that someone else asked me to crack a given hash.  However, I will not waste my resources to prove something else to you all and I am unwilling to teach you all something else.  

I think that to crack an useless hash and rewarded $10,000-HK is not worth for me to do so.  In real life, if I cracked a useful hash, I will gain more than that.  I do that kind of work very often.  

Meanwhile, I am not caring about if anyone else believe in me or not.  I just bring up my point of view for that matter only.

My last word : While you do not know attack, how can you know about defense? (未知攻,焉知防?)

Samiux

---

作者: dsscss    時間: 2014-9-13 22:45

回覆 52# samiux

你真係好笑.

你講到咁易,
你係HACKER 0黎 0麻,
你只要寫到個PROGRAM係
GEN COMBINATION -> 產生HASH TABLE -> COMPARE -> IF MATCH = SUCCESS, ELSE RETURN TO STEP1

而對於一個本身真係做開破解既人,
因為本身己經有一套TOOLSET係做呢D 0野....
跟本唔需要由頭寫D PROGRAM / 乜SCRIPT...
所以我唔知SIDE 左 你D什麼RESOURCE啦...

我個人比較務實,
所以我唔會吹一吹水,
就話因為ID+PHONE既組合太少,
所以個DATABASE易CRACK...

---

作者: samiux    時間: 2014-9-13 22:51

本帖最後由 samiux 於 2014-9-13 22:54 編輯




My friend is interested in it if you are sure to give him $1282-US (about $10,000-hk) for the successful crack.

However, he will not pay back you the same amount when he failed.  Deal?

Samiux

Update reason : add the hash

---

作者: dsscss    時間: 2014-9-13 23:01

回覆 54# samiux

你可以想一想點解你個FRIEND會話NOT PAY BACK THE SAME AMOUNT WHEN HE FAILED,
這是因為你個FRIEND都知道COMBINATION可以太多...
沒有這個RULE,就沒有意思了...

---

作者: samiux    時間: 2014-9-13 23:03

本帖最後由 samiux 於 2014-9-13 23:05 編輯


You can contact him at freenode ask him if he want to pay you back if he fail or not.  Our deal is not his deal.

If you agree, I pm you the contact method.

I have no interest in this stuff.

Samiux

Update reason : fix typo

---

作者: lazyfai    時間: 2014-9-13 23:38

嘩一個吹水post吹到咁多頁, 睇死人

---

作者: samiux    時間: 2014-9-13 23:48




Sure.  I do surprise too.  May be the topic or the content or the target (6.22 Civil Referendum) is interesting.

My first post is based on my presumption.  I already mentioned.  

Samiux

---

作者: KoolFreeze    時間: 2014-9-16 21:04



Keep in mind that you are assuming the source code isn't compromised, which might not be true.

Moreover, the scheme of hashing ID and phone together has a significant problem:
THE SYSTEM CAN'T CHECK IF AN ID HAS VOTED TWICE with two different phone number.
It's seems to me that's a rather rubbish "voting system".
If you hash that with more info, then the hash is even more useless.

If such a hash is useless, why keep the hash at all?
Not storing any info is the most secure method.
Why don't just increment a counter when somebody vote?
Then no hacker can hack it.