Amazon Q (來猜名字的由來...)

AWS 推出了 Amazon Q,目前還在 preview 階段:「Amazon Q brings generative AI-powered assistance to IT pros and developers (preview)」。

產品本身主要就是 LLM 的應用,以現在來說沒有太特別,主要是 Hacker News 上大家在猜這個 Q 到底是取自哪裡:「Amazon Q (Preview) (amazon.com)」。

看到有猜 Q (Star Trek)Q-learning 以及 Q (James Bond)

id=38448900 這邊有人提到 Q 是 question:

from the NYTimes article: The name Q is a play on the word “question,” given the chatbot’s conversational nature, Mr. Selipsky said. It is also a play on the character Q in the James Bond novels, who makes stealthy, helpful tools, and on a powerful “Star Trek” figure, he added.

找了一下應該是「Amazon Introduces Q, an A.I. Chatbot for Companies」這篇文章,因為 paywall 的關係可能看不到全文,可以看 archive.today 這邊的 archive:「Amazon Introduces Q, an A.I. Chatbot for Companies」。

反正牽扯的到的都提一下...

關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.