Bài báo “Worst-case optimal join algorithms” có một lịch sử thú vị liên quan đến blog KHMT. Số là năm ngoái bọn tôi làm một vấn đề về giải mã tín hiệu trong compressed sensing. (Bài ở STACS 2012.) Một trong những kết quả tìm được là một thuật toán cho bài lính bắn tia laser. Bài lính bắn laser vốn là một bất đẳng thức hình học, và do có cấu trúc khá chặt chẽ tôi thấy rất khó chịu khi thuật toán chỉ làm cho trường hợp 3-chiều. Tôi có viết trong một lời bình ngày 1 tháng 3, 2011 là

Tôi tin là có chứng minh tốt hơn cái CM tôi có, và có lẽ đây là trường hợp đặc biệt của cái gì đó đã biết, nhưng tôi không biết là cái gì.

Bài học 1: luôn không thoả mãn với các trường hợp đặc biệt. Nếu kết quả của mình có vẻ cơ bản thì nó phải là một ví dụ của cái gì đó tổng quát hơn, đẹp hơn!

May có bác Xuân Long cho ngay câu trả lời: đó là trường hợp đặc biệt của bất đẳng thức Loomis-Whitney. Từ đó bọn tôi đi tìm hiểu xem cách chứng minh bài laser của mình có dùng để chứng minh BĐT Loomis-Whitney hay không. Đây là chứng minh bằng thuật toán: cho các hình chiếu, xây dựng lại bộ tập điểm ban đầu, chứ không phải chứng minh BĐT toán học tuần tuý. Nếu chỉ chứng minh toán học thuần tuý thì cái chứng minh dùng entropy là tuyệt hảo rồi.

Sau một tháng, ngày 8 tháng 4, tôi ghi lại một chứng minh khác của BĐT Loomis-Whitney không dùng entropy cũng trên blog này. Lúc đó bác Nguyễn Tiến Zũng có bình luận là “chứng minh entropy có gì phù thuỷ đâu“?

Bài học 2: có sự khác biệt giữa tư duy toán học và tư duy KHMT. Dân KHMT thường nên nghĩ về thuật toán chứ không chỉ một chứng minh toán học thuần tuý.

Một trong những thứ mà tôi nhận ra ngay từ bài lính bắn laser là đây là một bài toán conjunctive join trong cơ sở dữ liệu quan hệ (relational database). Sau một vài tháng suy nghĩ thì bọn tôi tìm được một thuật toán “chứng minh” BĐT Loomis-Whitney. Tuy nhiên cái chứng minh (bằng thuật toán) này chứng minh được một BĐT yếu hơn Loomis-Whitney một chút. Dù sao, nó cũng là một kết quả thú vị về conjunctive query evaluation và bọn tôi viết lại, nộp vào SODA 2012. Các bác referees cũng khá thích kết quả này, nhưng họ càm ràm rằng lớp các conjunctive queries mà BĐT Loomis-Whitney đại diện quá đặc biệt; cần kết quả mạnh hơn. Thế là bài báo không được nhận dù review khá tốt.

Bài học 3: đôi khi một bài báo bị từ chối là một điều tốt.

Lẽ tất nhiên, bọn tôi lại phải quay lại với bút chì và giấy nháp; cố gắng thử xem thuật toán của mình có dùng để evaluate các conjunctive queries tổng quát hơn hay không. Nhưng cũng chằng đi đến đâu.

Trước đó, tôi gọi điện hỏi bác An Hải — nói cho bác ấy biết là bọn tôi có một thuật toán mới cho conjunctive join. Bác AH bảo: “không có thằng nào đi implement thuật toán mới đâu, đừng có nằm mơ, các RDBMS engines có mấy chục năm heuristics ở trong đó, inertia rất lớn, blah blah blah. Tuy nhiên, ở Wisconsin có chú Chris Ré làm lý thuyết, hay liên lạc với chú ấy xem sao.”

Bài học 4: gọi điện hỏi, nhưng đừng nghe lời bác An Hải.

Trùng hợp là một đồng tác giả của tôi, Atri Rudra, học cùng trường với Chris Ré. Sau khi liên lạc thì Chris rất thích kết quả (yếu) về BĐT Loomis-Whitney và đi hỏi các chuyên gia về join optimization. Cuối cùng, bọn tôi khám phá rất một bài báo tuyệt vời của Atserias-Grohe-Marx ở FOCS 2008. Bài báo này chứng minh một bất đẳng thức tổng quát cho mọi (full) conjunctive queries, mà trong đó Loomis-Whitney là một trường hợp đặc biệt. Hãy gọi bất đẳng thức này là BĐT AGM. BĐT AGM cũng được chứng minh bằng entropy như BĐT Loomis-Whitney.

Thế là bọn tôi chuyển hướng nghiên cứu thuật toán chứng minh BĐT AGM — và cũng là thuật toán evaluate conjunctive queries. Thuật toán trước đó cho LW không giải quyết được trường hợp tổng quát này. Do thuật toán được thiết kế cho LW, một trường hợp đặc biệt, nó tận dụng quá nhiều cấu trúc của trường hợp đặc biệt và do đó không thể tổng quát hoá nó lên.

Bài học 5: giải trường hợp tổng quát có thể “dễ” hơn trường hợp đặc biệt, và thường là sẽ cho lời giải “đúng” hơn với bản chất vấn đề.

Cuối cùng, sau khoảng 3, 4 tháng bí rị, trong vòng 1 tuần bọn tôi tìm ra thuật toán vừa chứng minh BĐT AGM, vừa là một thuật toán tối ưu cho conjunctive join. Lý do có thể “đục thủng” được sự bí rị là vì thuật toán trước chứng minh một phiên bản yếu của LW, và rất không đẹp. Cho nên quyết định chứng minh lại Loomis-Whitney một cách chặt chẽ dùng một thuật toán mới. Sau đó tổng quát hoá thuật toán mới này lên AGM.

Bài học 6: luôn luôn cảm thấy khó chịu với các lời giải không đẹp.

Lúc đó gần tháng 11. Định nộp vào STOC nhưng viết không kịp; vả lại PODS là hội nghị DB nên có lẽ là người ta “appreciate” kết quả này hơn.

Thuật toán cuối cùng phức tạp hơn thuật toán ban đầu cho LW nhiều, nhưng mặt khác nó cũng thoáng hơn vì nó giải quyết trường hợp tổng quát nên ta không bị gò bó vào các cấu trúc lắt nhắt.

OK, khoe đã xong, khi nào rảnh rỗi sẽ viết lại kỹ hơn về conjunctive joins, thuật toán NPRR, và các ứng dụng (nhiều vô kể) của conjunctive join query evaluation.

Tôi nhận được thư từ của nhiều bạn hỏi về việc nên học gì và như thế nào để có thể tìm được việc làm và làm được việc trong ngành an toàn thông tin (information security). Tôi nghĩ việc đầu tiên bạn cần phải làm là in toàn bộ bài viết “Làm thế nào để trở thành white hat hacker” ra giấy, nhưng đừng đọc, mà hãy để chúng trong toilet khi nào cần thì xài dần.

Quay trở lại câu hỏi. An toàn thông tin là một ngành rộng lớn với rất nhiều lĩnh vực. Những gì tôi biết và làm được chỉ gói gọn trong một hai lĩnh vực. Có rất nhiều mảng kiến thức cơ bản mà tôi không nắm vững và cũng có nhiều kỹ năng mà tôi không thạo. Hack tài khoản Yahoo! Mail là một trong số đó. Tôi cũng không biết cách tìm địa chỉ IP của bạn chat .

Xét theo năm mức ngu dốt thì tôi nằm ở mức “1OI – thiếu kiến thức” ở hầu hết các lĩnh vực trong an toàn thông tin. Cũng có lĩnh vực tôi nằm ở mức “2OI – thiếu nhận thức”. Nhiều lần đọc sách vở hoặc nói chuyện với đồng nghiệp, tôi hay nhận ra rằng có nhiều thứ tôi không biết là tôi không biết. Theo ý của anh Ngô Quang Hưng thì đây là chuyện bình thường:

Dân máy tính thường phải đọc/học rất nhiều để theo kịp sự phát triển với tốc độ ánh sáng của ngành mình. Trong quá trình này, với mỗi vấn đề X của ngành, ta sẽ chuyển dần dần từ 3OI xuống 1OI. Sau đó, nếu X là cái mà ta thật sự thích hoặc cần cho công việc thì sẽ chuyển nó lên 0OI.

Rất nhiều sinh viên và nghiên cứu sinh KHMT ở mức 3OI khi mới bắt đầu đi học. Sau đó họ tìm hiểu về quá trình nghiên cứu, quá trình tìm các vấn đề và hướng nghiên cứu mới, quá trính cập nhật kiến thức về ngành của mình, và chuyển dần các thứ lên 2OI. Để có một quá trình hiệu quả từ 3OI lên 2OI không dễ chút nào. Ví dụ đơn giản: các journals, conference nào trong ngành mình là có giá trị, làm thế nào để tìm đọc các bài trong chúng, phương pháp lọc bài đọc thế nào, vân vân.

Tôi thấy anh Hưng nói có lý, nên mục tiêu chính của bài viết này là cung cấp một quá trình hiệu quả để bớt ngu về an toàn thông tin.

2 Làm an toàn thông tin là làm gì?

Tôi muốn viết phần này vì nhiều người tưởng tôi làm bảo vệ khi tôi nói tôi làm security. Ngoài ra có lẽ là do thị trường việc làm an toàn thông tin ở Việt Nam không phong phú nên hầu hết đều nghĩ rằng làm an toàn thông tin nghĩa là đảm bảo an toàn hệ thống mạng (network/system security), trong khi thực tế đây chỉ là một trong số rất nhiều công việc trong ngành.

Trong bốn phần nhỏ tiếp theo, tôi sẽ giới thiệu bốn nhóm công việc chính trong ngành. Đối với mỗi nhóm công việc, tôi sẽ bàn một chút về triển vọng nghề nghiệp ở Việt Nam và Mỹ, hai nơi mà tôi có dịp được quan sát. Nếu bạn không biết bạn thích làm gì thì cứ chọn một công việc rồi làm thử. Các công việc này đều có liên quan nhau, nên kiến thức mà bạn học được trong quá trình thử vẫn hữu ích cho những nghề khác.

2.1 An toàn sản phẩm (product security)

Công việc chính của nhóm này là làm việc với các đội phát triển sản phẩm để đảm bảo sản phẩm làm ra an toàn cho người dùng và an toàn cho hệ thống của công ty, cụ thể là:

• Kiểm định mã nguồn và thiết kế của sản phẩm

• Phát triển các giải pháp kỹ thuật và quy trình phát triển phần mềm an toàn để phát hiện và ngăn chặn những kỹ thuật tấn công đã biết

• Đào tạo nhân lực để nâng cao nhận thức về an toàn thông tin cũng như kỹ năng viết mã an toàn

• Nghiên cứu các hướng tấn công mới có thể ảnh hưởng hệ thống sản phẩm và dịch vụ của công ty

Tóm gọn lại thì nhóm này chuyên tìm lỗ hổng và kỹ thuật tấn công mới. Đây là công việc của tôi và tôi thấy đây là công việc thú vị nhất trong ngành .

Ở Mỹ thì thông thường thì chỉ có các hãng có phần mềm và dịch vụ lớn như Facebook, Google, Microsoft, Oracle, v.v. hay các tập đoàn tài chính ngân hàng lớn mới có đội ngũ tại chỗ để đảm nhiệm công việc này. Các công ty nhỏ thường chỉ thuê dịch vụ của các công ty tư vấn. IBM và Big Four đều có cung cấp dịch vụ tư vấn này. Dẫu vậy nếu được chọn lựa thì tôi sẽ chọn làm cho các công ty chuyên sâu như Matasano, iSec, Leviathan, Gotham, IOActive, Immunity, v.v.

Ở Việt Nam thì thị trường việc làm cho người làm an toàn sản phẩm có vẻ ảm đạm hơn. Cho đến nay tôi biết chỉ có một vài công ty ở Việt Nam là có nhân viên chuyên trách lĩnh vực này. Các công ty khác (nếu có quan tâm đến an toàn thông tin) thì hầu như chỉ tập trung vào an toàn vận hành. Các công ty tư vấn an toàn thông tin ở Việt Nam cũng không tư vấn an toàn sản phẩm, mà chỉ tập trung tư vấn chung chung về các quy trình và tiêu chuẩn an toàn thông tin.

2.2 An toàn vận hành (operations security)

Công việc chính của nhóm này là đảm bảo sự an toàn cho toàn bộ hệ thống thông tin của doanh nghiệp, với ba nhiệm vụ chính:

• Ngăn chặn: đưa ra các chính sách, quy định, hướng dẫn về an toàn vận hành; kiện toàn toàn bộ hệ thống thông tin, từ các vành đai cho đến máy tính của người dùng cuối; cấp và thu hồi quyền truy cập hệ thống; quét tìm lỗ hổng trong hệ thống, theo dõi thông tin lỗ hổng mới và làm việc với các bên liên quan để vá lỗi, v.v.

• Theo dõi và phát hiệ: giám sát an ninh mạng.

• Xử lý: phản hồi (incident response) và điều tra số (digital forensics) khi xảy ra sự cố an toàn thông tin, từ tài khoản của nhân viên bị đánh cắp, rò rỉ thông tin sản phẩm mới cho đến tấn công từ chối dịch vụ.

Đây là công việc khó nhất, nhưng lại ít phần thưởng nhất của ngành an toàn thông tin.

Tương tự như trên, chỉ có các hãng lớn của Mỹ mới có đội ngũ tại chỗ để phụ trách toàn bộ khối lượng công việc đồ sộ này, nhất là mảng xử lý và điều tra. Đa số các công ty chỉ tập trung vào ngăn chặn và sử dụng dịch vụ của bên thứ ba cho hai mảng còn lại. Các hãng như Mandiant, Netwitness hay HBGary cung cấp dịch vụ điều tra các vụ xâm nhập và có rất nhiều hãng khác cung cấp dịch vụ giám sát an ninh mạng.

Ở Việt Nam thì thị trường việc làm cho người làm an toàn vận hành tương đối phong phú hơn so với an toàn sản phẩm. Các công ty và tổ chức tài chính lớn đều có một vài vị trí chuyên trách về an toàn vận hành. Đa số người làm về an toàn thông tin ở Việt Nam mà tôi biết là làm trong lĩnh vực này. Dẫu vậy hầu như chưa có ai và công ty tư vấn nào làm về phản hồi và điều tra sự cố.

2.3 Phát triển công cụ (applied security)

Công việc chính của nhóm này là phát triển và cung cấp các công cụ, dịch vụ và thư viện phần mềm có liên quan đến an toàn thông tin cho các nhóm phát triển sản phẩm sử dụng lại.

Nhóm này bao gồm các kỹ sư nhiều năm kinh nghiệm và có kiến thức vững chắc về an toàn thông tin, viết mã an toàn và mật mã học. Họ phát triển các thư viện và dịch vụ dùng chung như phân tích mã tĩnh – phân tích mã động (static – dynamic code analysis), hộp cát (sandboxing), xác thực (authentication), kiểm soát truy cập (authorization), mã hóa (encryption) và quản lý khóa (key management), v.v.

Đây là dạng công việc dành cho những ai đang viết phần mềm chuyên nghiệp và muốn chuyển qua làm về an toàn thông tin. Đây cũng là công việc của những người thích làm an toàn sản phẩm nhưng muốn tập trung vào việc xây dựng sản phẩm hơn là tìm lỗ hổng.

Rõ ràng loại công việc này chỉ xuất hiện ở các công ty phần mềm lớn. Ở các công ty phần mềm nhỏ hơn thì các kỹ sư phần mềm thường phải tự cáng đáng công việc này mà ít có sự hỗ trợ từ nguồn nào khác. Ở Việt Nam thì tôi không biết có ai làm dạng công việc này không.

2.4 Tìm diệt mã độc và các nguy cơ khác (threat analysis)

Ngoài an toàn sản phẩm ra thì đây là một lĩnh vực mà tôi muốn làm. Công việc chính của nhóm này là phân tích, truy tìm nguồn gốc và tiêu diệt tận gốc mã độc và các tấn công có chủ đích (targeted attack). Mã độc ở đây có thể là virút, sâu máy tính, hay mã khai thác các lỗ hổng đã biết hoặc chưa được biết đến mà phần mềm diệt virút thông thường chưa phát hiện được. Các loại mã độc này thường được sử dụng trong các tấn công có chủ đích vào doanh nghiệp.

Tôi nghĩ rằng sau hàng loạt vụ tấn công vừa rồi thì chắc hẳn các công ty lớn với nhiều tài sản trí tuệ giá trị đều muốn có những chuyên gia trong lĩnh vực này trong đội ngũ của họ. Ngoài ra các công ty chuyên về điều tra và xử lý sự cố như Mandiant, HBGary hay Netwitness mà tôi đề cập ở trên đều đang ăn nên làm ra và lúc nào cũng cần người. Các công ty sản xuất phần mềm diệt virút dĩ nhiên cũng là một lựa chọn.

Ở Việt Nam thì tôi nghĩ hầu hết doanh nghiệp vẫn chưa thấy được nguy cơ đến từ các cuộc tấn công có chủ đích, thành ra họ sẽ không tuyển người chuyên trách vấn đề này. Tôi cũng không biết có công ty tư vấn nào ở Việt Nam chuyên về điều tra và xử lý sự cố hay không. Tôi nghĩ lựa chọn khả dĩ nhất cho những người thích mảng công việc này là các công ty phần mềm diệt virút.

Tuy nhiên cũng cần lưu ý rằng trong vài năm gần đây ở Việt Nam còn xuất hiện những loại mã độc nhắm vào đông đảo người dùng máy tính bình thường. Vấn nạn này có lẽ sẽ còn kéo dài trong nhiều năm tới và lẽ đương nhiên “phe ta” lúc nào cũng cần thêm những chiến sĩ lành nghề như anh TQN. Thành ra dẫu triển vọng nghề nghiệp không sáng sủa cho lắm, nhưng tôi rất hi vọng sẽ ngày càng nhiều người tham gia vào việc phân tích các mã độc nhắm vào người dùng máy tính ở Việt Nam. Đối với tôi họ là những người hùng thầm lặng, chiến đấu đêm ngày với các “thế lực thù địch” để bảo vệ tất cả chúng ta.

3 Học như thế nào?

Đa số những bạn viết thư cho tôi đều đang học đại học ngành CNTT và tất cả đều than rằng chương trình học quá chán, không có những thứ mà các bạn muốn học. Tôi nghĩ đây là một ngộ nhận.

Hối tiếc lớn thứ nhì trong sự nghiệp học tập mấy chục năm của tôi là đã không học nghiêm túc khi còn là sinh viên (hối tiếc lớn nhất là tôi đã không nghỉ hẳn, nhưng đó là một câu chuyện dài khác). Tôi cũng đã nghĩ rằng chương trình học ở đại học là lạc hậu và không cần thiết. Bây giờ nhìn lại thì tôi thấy nội dung và cách dạy của từng môn học thì đúng là lạc hậu (chỉ có mấy môn triết học Mác-Lênin là bắt kịp ánh sáng thời đại), nhưng toàn bộ giáo trình đại học vẫn cung cấp được một cái sườn kiến thức rất cần thiết cho một kỹ sư an toàn thông tin.

Ở đại học người ta có cách tiếp cận top-down, nghĩa là dạy từ đầu đến cuối những kiến thức nằm trong chương trình. Điều này dễ dẫn đến tình trạng là người học phải học những kiến thức mà họ không thấy cần thiết. Nếu chương trình học cũ kỹ và không có nhiều thực hành, hoặc người dạy không chỉ ra được bức tranh toàn cảnh, vị trí hiện tại của người học và bước tiếp theo họ nên làm là gì thì người học sẽ dễ cảm thấy rằng họ đang phí thời gian học những kiến thức vô bổ.

Trong khi khi đi làm thì cách tiếp cận là bottom-up, nghĩa là lao vào làm, thấy thiếu kiến thức chỗ nào thì học để bù vào chỗ đó. Lúc này tôi hoàn toàn chủ động trong việc học và tôi cũng hiểu rõ tôi cần học cái gì và tại sao. Điều thú vị là mỗi khi truy ngược lại nguồn gốc của những kiến thức tôi cần phải có, tôi thường thấy chúng nằm trong chương trình đại học.

Ví dụ như tôi muốn luyện kỹ năng dịch ngược mã phần mềm (reverse code engineering – RCE) thì tôi thấy rằng tôi cần phải có kiến thức về tổ chức và cấu trúc máy tính. Hoặc nếu tôi muốn học về mật mã học thì tôi phải học lý thuyết tính toán, mà khởi nguồn là lý thuyết automata. Nhưng tại sao trước đó tôi cũng đi làm nhưng không thấy được những lỗ hổng kiến thức này? Tôi nghĩ là do tôi làm không đủ sâu. Ví dụ như nếu bạn suốt ngày chỉ lập trình PHP thì bạn sẽ không thể hiểu được tại sao phải nắm vững tổ chức và kiến trúc máy tính. Hoặc giả như công việc của bạn là sysadmin thì cũng sẽ rất khó để bạn thấy được tại sao cần phải học lý thuyết automata.

Những gì tôi nói lan man ở trên có thể tóm gọn lại thế này:

• Học dựa theo chương trình đại học. Nếu bạn đang học đại học các ngành công nghệ thông tin, khoa học máy tính hay toán tin thì nên tập trung vào việc học các môn trong trường. Các học liệu trong phần 4 cũng được soạn theo các đại học lớn trên thế giới.

• Học kiến thức căn bản thật vững (cái gì là căn bản thì xem phần 4), những món còn lại khi nào cần (căn cứ vào nhu cầu công việc) thì hẵng học.

• Tìm dự án lề (side project) mà bạn thích để làm để có thể nhanh chóng nhận ra những mảng kiến thức còn thiếu.

• Thời điểm tốt nhất để học một cái gì đó là khi bạn đang là sinh viên. Thời điểm tốt thứ hai là ngay bây giờ!

Các lớp mà tôi liệt kê trong phần 4 đa số là của đại học Stanford. Bạn không cần phải đến tận nơi, ngồi trong lớp mới có thể học được. Tôi thấy trong nhiều trường hợp thì bạn chỉ cần đọc lecture notes, sách giáo khoa mà lớp sử dụng rồi làm bài tập đầy đủ thì vẫn sẽ tiếp thu đủ kiến thức. Một số lớp mà tôi liệt kê dưới đây được dạy miễn phí rộng rãi trên Coursera.Bạn có thể tham khảo chương trình SCPD nếu muốn học chung với các sinh viên Stanford khác. Đây là chương trình học từ xa thông qua video. Buổi sáng lớp diễn ra thì buổi chiều bạn đã có video để xem. Thi cử như các sinh viên chính quy khác và điểm phải trên B mới được học tiếp. Đây là chương trình mà tôi theo học. Điểm thú vị là mỗi học kỳ bạn chỉ cần lấy một lớp, nhưng Stanford vẫn sẽ cho bạn xem video của tất cả các lớp khác.

Ngoài Stanford và Coursera ra, bạn cũng có thể tham khảo các lớp trên Udacity, OCW và MITx. Khi tôi đang viết những dòng này thì MIT và Harvard công bố dự án edX. Chúng ta đang sống trong một thời đại cực kỳ thú vị! Bây giờ chỉ cần bạn chịu học thì muốn học cái gì cũng có lớp và học liệu miễn phí. Nhưng mà học cái gì bây giờ?

4 Học cái gì?

Có ba món quan trọng cần phải học: lập trình, lập trình và lập trình! Để làm việc được trong ngành này, bạn phải yêu thích lập trình. Không có cách nào khác. Thề luôn!

Tôi dành khá nhiều thời gian tìm hiểu giáo trình khoa học máy tính của các trường đại học lớn trên thế giới và tôi thấy tất cả các môn học đều có phần bài tập là lập trình. Học cái gì viết phần mềm cho cái đó. Học về hệ điều hành thì phần bài tập là viết một hệ điều hành. Học về mạng thì viết phần mềm giả lập router, switch hay firewall. Cá nhân tôi cũng thấy rằng lập trình là cách tốt nhất để tiếp thu kiến thức một môn học nào đó, biến nó thành của mình. Nói cách khác, lập trình là một cách mã hóa tri thức khá hiệu quả.

Ngoài ra nhìn vào mô tả công việc ở phần 2, bạn cũng có thể thấy kỹ năng lập trình quan trọng đến dường nào, bởi hầu hết các vấn đề và giải pháp của an toàn thông tin là đến từ phần mềm. Rõ ràng muốn tìm lỗi của phần mềm thì bạn phải hiểu được phần mềm thông qua mã nguồn trực tiếp hay trung gian của nó. Rất có thể bạn sẽ không phải lập trình hàng ngày, nhưng bạn phải viết được những công cụ nhỏ hay những thư viện hỗ trợ cho công việc và các lập trình viên khác.

Vậy làm thế nào để lập trình giỏi? Câu hỏi này làm tôi nhớ đến câu chuyện cười về ông lập trình viên không thể ra khỏi phòng tắm vì trên chai dầu gội có ghi hướng dẫn sử dụng là “cho vào tay, xoa lên đầu, xả nước và lập lại”. Từ khóa trong câu chuyện này là “lập lại”: muốn giỏi lập trình thì cách tốt nhất là lập trình nhiều vô!

Nhưng mà lập trình bằng ngôn ngữ gì bây giờ? Đây là câu hỏi dễ làm cho các lập trình viên oánh nhau nhất . Cá nhân tôi thấy rằng người làm an toàn thông tin bây giờ cần phải thông thạo C, x86 Assembly, Python (hoặc Ruby) và JavaScript. Tôi có nói lý do tại sao trong phần giới thiệu sách tiếp theo.

Lập trình

• Brian Kernighan, Dennis Ritchie, The C Programming Language (2nd Edition): kinh điển và phải-đọc cho tất cả những ai muốn học C! Linus Torvalds từng nói rằng “[...] all right-thinking people know that (a) K&R are _right_ and (b) K&R are right“. Tôi đã từng rất sợ C (vì nghĩ nó phức tạp), và cuốn này giúp tôi không còn sợ nữa.

• Randal Bryant, David O’Hallaron, Computer Systems: A Programmer’s Perspective: cuốn này được dùng cho lớp CS107. Đọc cuốn này và làm bài tập của lớp CS107 sẽ rèn cho bạn kỹ năng lập trình C và x86 Assembly. Sau khi đọc cuốn này, bạn sẽ biết tại sao có lỗi tràn bộ đệm và cách khai thác chúng. Tôi rất thích các chương nói về x86 và sự liên kết giữa các công cụ như preprocessor, compiler và linker.

• David Hanson, C Interfaces and Implementations: muốn mau “lên cơ” bida thì phải thường xuyên xem người khác chơi để mà học “đường” mới. Tương tự, muốn giỏi lập trình thì phải thường xuyên đọc mã của những cao thủ. David Hanson là một cao thủ C và cuốn sách này sẽ chỉ cho bạn nhiều “đường” mới trong việc sử dụng C. Tôi thích các bài tập của cuốn sách này. Tôi nghĩ chỉ cần luyện các bài này là đủ để trở thành một lập trình viên C hạng lông.

• Justin Seitz, Gray Hat Python: Python Programming for Hackers and Reverse Engineers: cuốn này sẽ giúp bạn sử dụng Python để viết những công cụ nho nhỏ mà bất kỳ ai làm an toàn thông tin cũng sẽ phải viết một vài lần trong đời.

• Douglas Crockford, JavaScript: The Good Parts: JavaScript là ngôn ngữ thống trị WWW. Nếu bạn muốn làm an toàn (ứng dụng và trình duyệt) web thì bắt buộc phải thành thạo ngôn ngữ. Cuốn sách rất mỏng này của tác giả JSON giới thiệu đầy đủ những vấn đề mà người làm an toàn ứng dụng cần phải biết về JavaScript. Cuốn này có thể dùng làm sách giáo khoa thay cho cuốn “Javascript: The Definitive Guide” trong lớp CS142 (xem bên dưới). Đọc cuốn này tôi mới hiểu closure là gì và bản chất prototypal của JavaScript.

• Sẽ đọc: những cuốn được giới thiệu ở đây.

Hệ điều hành

• Abraham Silberschatz, Peter Galvin, and Greg Gagne, Operating System Concepts, 8th Edition Update: cuốn này là giáo trình của lớp CS140. Tôi nghĩ không cần đọc cuốn này, chỉ cần đọc notes và làm bài tập (viết các phần khác nhau của một hệ điều hành!) là đủ. Đây là một lớp nặng. Tôi theo đuổi lớp CS140 này giữa chừng thì phải dừng lại do không có đủ thời gian.

• Intel Software Developer Manuals: tôi thấy nên đọc tài liệu của 80386 trước, rồi sau đó hẵng đọc tài liệu của các CPU mới hơn.

• Red Hat, Introduction to System Administration: tôi rất thích chương nói về “philosophy of sysadmin” của cuốn này và tôi nghĩ kỹ năng quản trị hệ thống là cực kỳ cần thiết khi muốn nghiên cứu các kỹ thuật tấn công/phòng thủ mới. Không thể làm an toàn vận hành nếu không có kỹ năng quản trị hệ thống.

• Sẽ đọc: Mark Russinovich, David Solomon, Alex Ionescu, Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7.

Mạng máy tính

• Richard Stevens, TCP/IP Illustrated Vol I: cuốn sách này quá nổi tiếng rồi nên tôi nghĩ không cần phải giới thiệu. Tôi chưa đọc Vol II, III nhưng nhất định sẽ tìm đọc trong thời gian tới. Lớp CS144 dùng một cuốn sách khác. Tôi chưa học lớp này, nhưng tôi thấy bài tập của họ khá thú vị.

• Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen Kent, Ronald W. Ritchey, Inside Network Perimeter Security, 2nd Edition: tôi thích cuốn này vì nó viết rất dễ hiểu về các vấn đề  và công cụ thường gặp trong an toàn mạng.

• Sẽ đọc: Fyodor, Nmap Network Scanning.

Sau khi đã có những kiến thức cơ bản ở trên, bạn có thể theo đuổi lớp CS155. Lớp này có trên Coursera với tên Computer Security. Song song với lớp CS155, bạn có thể tìm đọc các sách sau:

Tìm lỗi phầm mềm

• Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities: Kinh điển và phải-đọc! Cuốn này là kinh thánh của lĩnh vực an ninh ứng dụng. Tôi thích nhất phần nói về tràn số nguyên và những vấn đề của ngôn ngữ C trong cuốn này.

• Dafydd Stuttard, Marcus Pinto, The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws: cuốn này tập trung vào ứng dụng web. Tôi không đọc cuốn này kỹ lắm, mà chỉ thường dùng nó để tham khảo. Dẫu vậy tôi nghĩ nó là một cuốn giới thiệu tốt cho những ai mới bắt đầu.

• Michal Zalewski, The Tangled Web: cuốn này mới xuất bản gần đây nhưng đã ngay lập tức trở thành kinh điển! Cuốn này đúc kết quá trình nghiên cứu về an ninh web trong vài năm trời của một trong những hacker xuất sắc nhất thế giới. Tôi nghĩ chỉ cần đọc cuốn này là bạn đã có thể bắt đầu tìm lỗ kiếm tiền được rồi. Cuốn này và cuốn ở trên được dùng làm sách giáo khoa của lớp CS142.

• Sẽ đọc: Tobias Klein, A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security

Dịch ngược mã phần mềm

• Eldad Eilam, Reversing: Secrets of Reverse Engineering: mặc dù có rất nhiều người viết về RCE nhưng tôi thấy đây là cuốn duy nhất hệ thống hóa được các bước quan trọng cần phải làm khi cần dịch ngược mã của một tệp chương trình nào đó.

• Chris Eagle, The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler: IDA Pro là công cụ tốt nhất để làm RCE và đây là cuốn sách tốt nhất về IDA Pro. Nắm vững C và x86 Assembly thì chỉ cần đọc cuốn này là bạn có thể bắt đầu RCE các phần mềm phức tạp.

• Tham khảo các tài liệu về dịch ngược mã phần mềm của lớp PenTest của đại học NYU.

• Sẽ đọc: Christian Collberg, Surreptitious Software: Obfuscation, Watermarking, and Tamperproofing for Software Protection: Obfuscation, Watermarking, and Tamperproofing for Software Protection

• Sẽ đọc: Michael Sikorski, Andrew Honig, Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software

Điều tra số (digital forensics)

• Brian Carrier, File System Forensic Analysis: Brian Carrier là tác giả của bộ công cụ forensic nổi tiếng The Sleuth Kit. Cuốn này đã giúp tôi “khai quật” được một đoạn video bị xóa lưu trong một máy camera quay lén các máy ATM.

• Sẽ đọc: Cory Altheide, Harlan Carvey, Digital Forensics with Open Source Tools

Mật mã hóa

• Niels Ferguson, Bruce Schneier, Practical Cryptography: tôi có nhiều kỷ niệm đẹp với cuốn này . Hầu hết các kết quả làm việc của tôi trong vài năm vừa rồi là nhờ vào việc đọc cuốn này. Tôi chép lại đây giới thiệu rất hay của một người bạn: “The best security books, you can read “inside out”, taking any recommendation on what to do and looking for people to do the opposite to find flaws. “Firewalls and Internet Security” was like that. So was “Practical Unix Security”, and so is TOASSA. This is that book for crypto. It’s also the one book on crypto you should allow yourself to read until you start actually finding crypto flaws.“

• Jonathan Katz, Yehuda Lindell, Introduction to Modern Cryptography: Principles and Protocols: đây là sách giáo khoa của lớp CS255. Lớp này là lớp Cryptography trên Coursera.

• Sẽ đọc: Adam Young, Moti Yung, Malicious Cryptography: Exposing Cryptovirology

Chú ý đây là những cuốn sách tập trung vào công việc hàng ngày và sở thích của tôi — nói cách khác, còn thiếu nhiều sách của các mảng công việc khác. Dẫu vậy tôi nghĩ những cuốn sách này sẽ giúp bạn có được một kiến thức nền tảng vững chắc để từ đó theo đuổi các nghề nghiệp khác nhau trong ngành an toàn thông tin. Trong thời gian tới tôi sẽ cập nhật thêm những cuốn sách mà tôi đang và sẽ đọc. Nếu bạn biết sách nào hay thì hãy giới thiệu cho tôi.

Ngoài ra trong các sách mà tôi vừa liệt kê không có cuốn sách toán (và lý thuyết khoa học máy tính) nào cả. Tôi nghĩ bạn sẽ tự có câu trả lời cho câu hỏi “Có nên học toán hay không?” khi bắt đầu học mật mã. Về hai mảng này thì tôi rất thích lớp “Great Ideas in Theoretical Computer Science” của Scott Aaronson và cuốn “A Computational Introduction to Number Theory and Algebra” của Victor Shoup. Thích đến nỗi tôi phải viết đoạn này chỉ để nhắc đến chúng . Tôi cũng đã từng dành ra nhiều tháng để đánh vật với Introduction to the Theory of Computation của Michael Sipser. Nhưng thôi, tôi không muốn giới thiệu sách toán nữa vì tôi rất dốt món này!

5 Bắt đầu nói nhảm và hết

Phew! Không ngờ là tôi cũng viết được cho đến đây (hi vọng là bạn vẫn đang đọc!). Tôi định viết dông dài về thái độ học tập này nọ, nhưng thôi bài đã dài và nhiều thông tin rồi, nên tôi chỉ nói ngắn gọn thế này:

Cái mà tôi vừa “vẽ” ra là một con đường. Thú thật là tôi không biết đích đến của nó là gì — tôi chỉ biết rằng hành trình mà tôi đã đi qua (và hi vọng là những chặng đường sắp tới) đã mang đến cho tôi rất nhiều niềm vui — niềm vui của một con người đi khám phá thế giới, chinh phục những thử thách, để rồi chia sẻ những câu chuyện hay ho với tất cả mọi người.Mỗi ngày tôi đều dành thời gian đọc sách, làm bài tập, viết mã hoặc chứng minh một cái gì đó. Không ai bắt tôi phải làm những chuyện đó. Có những thứ tôi học cũng không (hoặc chưa) có liên quan gì đến công việc. Tôi học chỉ vì tôi thích và tò mò. Tôi học vì tôi muốn hiểu thêm những thứ mà tôi cho là hay ho. Tôi học vì tôi muốn đi mãi, đi mãi, đi đến tận cùng những cái mà người ta viết trong sách, để xem ở đó có gì hay không.

Hôm rồi tôi đọc một mẩu chuyện về Richard Feynman, trong đó có đoạn kể về lúc Feynman bị bệnh gần đất xa trời, ông tâm sự rằng, “[I'm going to die but I'm not as sad as you think because] when you get as old as I am, you start to realize that you’ve told most of the good stuff you know to other people anyway”. Đương nhiên những gì tôi biết làm sao mà “good” bằng những gì Feynman biết, nhưng dẫu sao thì tôi cũng sẽ học theo Feynman: có biết chuyện gì hay ho thì kể cho nhiều người khác cùng biết. Bài này là một chuyện như thế.

Happy hacking!

(cảm ơn đại ca M. đã đọc và sửa bản nháp của bài này)

$20,000 for qualifying vulnerabilities that the reward panel determines will allow code execution on our production systems.

$10,000 for SQL injection and equivalent vulnerabilities; and for certain types of information disclosure, authentication, and authorization bypass bugs.

Up to $3,133.7 for many types of XSS, XSRF, and other high-impact flaws in highly sensitive applications.

3.000 Mỹ kim cho một lỗ hổng XSS, quá ngon! Với số lượng ứng dụng khổng lồ của Google, việc tìm được những lỗi như XSS hay XSRF, vốn không đòi hỏi kiến thức hay kinh nghiệm gì cao siêu cả, là không quá khó. Thực tế là kể từ khi chương trình này bắt đầu cho đến nay, đã có hơn hai trăm người gửi lỗi và được Google thưởng cho hơn 460.000 Mỹ kim. Nhưng chưa có con sãi nào đến từ Việt Nam cả!

Nếu không săn lỗ thì đi viết app cũng được.

Năm 24 tuổi, cô gái này đi “đến thăm, động viên đội ngũ cán bộ, công nhân đang thi công … chỉ đạo Ban quản lý chu đáo các vấn đề liên quan đến việc làm lán, trại, chỗ ở cho công nhân để anh em yên tâm làm việc và đảm bảo sức khỏe“.

Thiệt là hậu sinh khả uý.

Có rất nhiều cách tính mã băm chuyển chuỗi ký tự thành số nguyên dài 32 bits. Các sách giáo khoa thường nói đến mã băm đa thức (polynomial hash codes). Ví dụ, với một chuỗi bytes s = s[0]...s[k-1] với chiều dài k ta có thể dùng hash code sau:

trong đó thường được chọn là một số nguyên tố. Hàm hashCode() strong trong lớp string của Java dùng mã băm đa thức với . Một lợi điểm của mã băm đa thức là nó có thể tính đương đối nhanh được dùng luật Horner:

Dịch ra C++ (đảo thứ tự các bytes lại cho đơn giản) là

uint32_t poly(string s, uint32_t base) {
    uint32_t ret = static_cast<uint32_t>(s[0]); // assumes s.length() > 0
    for (size_t i=1; i<s.length(); ++i) {
        ret += base*ret + static_cast<uint32_t>(s[i]);
    }
    return ret;
}

Nếu base là 33 hoặc 31 thì ta có thể thay base*ret bằng base + (base << 5) hoặc (base << 5) - base: nhanh hơn nhiều. Do đó, 33 và 31 thường được giới thiệu dùng.

Một hàm khác cũng thường được gợi ý thì thay phép nhân với một base bằng một phép shift đi vài bits, ví dụ 7 bits:

uint32_t shift7(string s) {
    uint32_t ret=0;
    for (size_t i=0; i<s.length(); ++i) {
            ret = (ret << 7) | (ret >> 25); // cyclic shift
            ret += static_cast<uint32_t>(s[i]);
    }
    return ret;
}

Năm 97, Bob Jenkins viết một bài báo trên tạp chí kỹ thuật Dr. Doob có liệt kê ra khá nhiều hàm phổ dụng cùng với các lợi điểm, yếu điểm của chúng. Sau đó đến khoảng 2006 ông ta cập nhật bài báo này với một số hàm mới. Đáng lưu ý là các hàm sau đây:

• Hàm FNV (viết tắt của Fowler–Noll–Vo). Hàm này có vẻ như được dùng rất phổ biến trong các phần mềm hiện đại. (Ví dụ, dùng để cải tiến fragment cache của Twitter.) Điều có liên quan đến blog này là chữ Vo thuộc về bác Võ Kiềm Phong của AT&T lab. Bác Phong cũng là đồng tác giả của thư viện SFIO, và nhiều hàm thư viện Unix khác.
• MurmurHash
• Và một vài hàm của Jenkins và của Paul Hsieh

FNV hash bản 32-bit có thể viết như sau:

uint32_t FNV32(string s)
{
    static const uint32_t FNV_PRIME_32  = 16777619;
    static const uint32_t FNV_OFFSET_32 = 2166136261;

    uint32_t hash = FNV_OFFSET_32, i;
    for(int i = 0; i < s.length(); i++) {
        hash  = hash^(s[i]);  // hash = hash XOR s[i]
        hash *= FNV_PRIME_32; // hash = hash * (fixed prime)
    }
    return hash;
}

Tôi download một tự điển nhỏ của phần mềm ispell, gồm khoảng 47 nghìn từ tiếng Anh thông dụng, và thí nghiệm với vài biến thể của các hàm băm trên. Kết quả như sau:

HC Name             Total # colliding values   Max bucket size
FNV32               0                           0
poly31              22                          1
poly33              22                          1
poly37              22                          1
poly7               2276                        18
poly91              19                          1
shift5              27                          2
shift7              56                          1
sum                 45579                       175
xoring              560                         2

Có thể thấy FVN32 rất tốt. Chúc mừng bác Võ! Kết quả này cũng tương tự với 3 bộ từ khác gồm gần 100 nghìn từ mà tôi đã thử. Chất lượng của một hàm băm nằm ở xác suất đụng độ và cả tốc độ của hàm băm. Trong thí nghiệm trên tôi chưa đo tốc độ.

Thiệt ra đây không phải câu hỏi phỏng vấn (có nơi nào phỏng vấn mà hỏi những câu dạng này không nhỉ?) mà là của một anh đồng nghiệp hỏi tôi hôm nay. Tôi thấy nó thú vị và thích hợp với những ai đang theo học lớp crypto của Stanford nên gửi lên đây.

Bài giảng cho lớp cấu trúc dữ liệu. Bạn nào rảnh đọc thì góp ý giùm, nhất là phần C++.

Bài trước: Cây nhị phân và cây tìm kiếm nhị phân
Bài sau: bảng băm.

In the previous lecture we have discussed binary search trees (BSTs) and several basic results such as the number of BSTs with n keys and the height of a random BST with n node. Perhaps the most important result is that in a BST the three basic operations — search, insert, and delete — take O(h) time where h is the height of the tree (at the time an operation is performed). Since the average height of a random BST is O(log n) (with a small variance), these operations are pretty fast on average. However, the run-time in the worst case could be bad.

Exercise: come up with a sequence of n inserts such that the tree height is .

In this lecture, we describe several schemes for maintaining BSTs such that the height of the tree is (about) logarithmic in the number of nodes. One of the main ideas is to ensure that for each node in the tree the height of the left sub-tree and the height of the right-subtree are roughly equal. For a visual illustration of three of the trees described in this lecture, you can make use of the Java applet on this page.

1. AVL Trees

AVL Trees are probably the earliest balanced BST, proposed by two Russians (Soviet) G. M. Adelson-Velskii and E. M. Landis in 1962. The main idea is intuitive: we call a node balanced if its two subtrees have heights differ by at most 1. A BST is an AVL tree if all nodes are balanced. This property is called the AVL property. There are two things we have to do to turn this idea into a theoretically sound data structure:

1. Prove that if a tree is an AVL tree, then its height is O(log n) where n is the number of keys in the tree.
2. Show how to do insert and delete in O(log n)-time while maintaining the AVL property.

1.1. AVL property implies logarithmic height

Theorem: an AVL tree on n nodes has O(log n) height.

Proof. Let be the maximum height of an AVL tree with nodes. We want to show that where is some constant. It turns out that proving the contra-positive is a little easier. Let be the minimum number of nodes in an AVL tree with height , we will derive a lower bound for in terms of , which will then lead to an upper bound of in terms of .
For simplicity, we will count all of the NULL pointers as leaves of the tree. Thus, a BST is a full binary tree: each non-NULL node has 2 children. It is not hard to see that and . Now, consider an AVL tree with height with the minimum possible number of nodes . Then, it must be the case that one of the sub-trees of the root has height with nodes and the other sub-tree has height with nodes. Thus, we have the following recurrence:

Define , then we have , , and

Because , , the third and fourth Fibonacci numbers, and beause obeys the same recurrence as the Fibonnaci recurrence, we conclude that . Consequently,

where is the golden ratio. Taking log on both sides of the inequality, we obtain . Since is the minimum possible number of nodes in any AVL tree with height , we conclude that for any AVL tree on nodes with height , we have as desired.

1.2. Maintaining the AVL property

After an insert (using the same algorithm as in a normal BST), some subtree might be 2 taller than its sibling subtree. We thus will have to readjust the tree to rebalance it. One important property to note is that the only nodes which might become unbalanced after a new node v is inserted are the nodes along the path from v back up to the root of the tree. Because, those are the nodes whose heights might be affected by the insertion.

To keep track of which nodes are balanced or not, we will add an extra field to each node called the balance field, which is defined to be the height of the left subtree minus the height of the right subtree of that node.

    struct AVLNode {
        // can also use static const instead of enum
        enum { LEFT_HEAVY = 1, BALANCED = 0, RIGHT_HEAVY = -1};
        int balance;
        Key key;
        Value value;
        AVLNode* left;
        AVLNode* right;
        AVLNode* parent;

        AVLNode(const Key& k, const Value& v)
        : key(k), value(v), parent(NULL), left(NULL), right(NULL),
          balance(BALANCED) {}

        std::string to_string() const {
            std::ostringstream oss;
            oss << key << "(" << balance << ")";
            return oss.str();
        }
    };

We want a node’s balance to be 1, 0, or -1. After inserting a node v into the tree, let a be the first node on the path from v back to the root that is unbalanced. Note that a‘s balance factor has to be 2 or -2. Let b be the ancestor of v which is the child of a. Note that v‘s parent cannot be unbalanced after v‘s insert, and thus a has to be at the very least v‘s grandparent. Node b might be v‘s parent.

We look for a by moving up the tree from v, readjusting the nodes’ balance fields along the way. If we don’t find a then we are done, no rebalancing needed. If we do find a, then there are four cases to consider: the right-right case, the right-left case, the left-left case, and the left-right case.

Below is the picture for the right-right case, which should be self-explanatory:

We readjust the tree by doing a left rotation about node a as shown in the picture. For the right-left case, we perform a double rotation: imagine doing a right-rotate about node c first to bring b up, and then a left-rotate about node a to bring b one more step up. Note that the new node can be in either T2 or T3 in the following picture.

The left-left and the left-right cases are symmetric to the above two cases. A very important point to notice is that after doing the rotation (double or single), we no longer have to fix the balance fields of nodes further up the tree!

Exercise: argue why after a single or double rotation, all nodes higher up in the tree are balanced.

Here is a simple interface for AVL tree:

/**
 * *****************************************************************************
 *  AVLTree.h: a simple implementation of the AVL Tree
 *  Author:      Hung Q. Ngo
 * *****************************************************************************
 */
#ifndef AVLTREE_H_
#define AVLTREE_H_

#include <iostream>
#include <sstream>

template <typename Key, typename Value>
class AVLTree {
public:
    AVLTree() : root(NULL) { }

    void  inorder_print()  { inorder_print(root); std::cout << std::endl; }
    void  preorder_print() { preorder_print(root); std::cout << std::endl; }
    void  postorder_print() { postorder_print(root); std::cout << std::endl; }

    bool  insert(Key, Value);
    bool  find(Key key) { return search(root, key) != NULL; }
    const Value& get(Key);
    const Value& minimum();
    const Value& maximum();
    bool  remove(Key);
    void  clear() { clear(root); }

private:
    // The node is similar to a BSTNode; use parent pointer to simplify codes
    // A tree is simply a pointer to a BSTNode, we will assume that variables of
    // type Key are comparable using <, <=, ==, >=, and >
    // we do not allow default keys and values
    struct AVLNode {
        enum { LEFT_HEAVY = 1, BALANCED = 0, RIGHT_HEAVY = -1};
        int balance;
        Key key;
        Value value;
        AVLNode* left;
        AVLNode* right;
        AVLNode* parent;

        AVLNode(const Key& k, const Value& v)
        : key(k), value(v), parent(NULL), left(NULL), right(NULL),
          balance(BALANCED) {}

        std::string to_string() const {
            std::ostringstream oss;
            oss << key << "(" << balance << ")";
            return oss.str();
        }
    };

    AVLNode* root;
    AVLNode* successor(AVLNode* node);
    AVLNode* predecessor(AVLNode* node);
    AVLNode* search(AVLNode*, Key);

    void rebalance(AVLNode*);
    void right_rotate(AVLNode*&);
    void left_rotate(AVLNode*&);

    void inorder_print(AVLNode*);
    void preorder_print(AVLNode*);
    void postorder_print(AVLNode*);

    void clear(AVLNode*&);
};

#include "AVLTree.cpp" // only done for template classes

#endif

And here is the implementation of the insertion strategy just described.

/**
 * -----------------------------------------------------------------------------
 *  insert a new key, value pair, return
 *    true if the insertion was successful
 *    false if the key is found already
 * -----------------------------------------------------------------------------
 */
template <typename Key, typename Value>
bool AVLTree<Key, Value>::insert(Key key, Value value) {
    AVLNode* p   = NULL;
    AVLNode* cur = root;
    while (cur != NULL) {
        p = cur;
        if (key < cur->key)
            cur = cur->left;
        else if (key > cur->key)
            cur = cur->right;
        else
            return false; // key found, no insertion
    }

    // insert new node at a leaf position
    AVLNode* node = new AVLNode(key, value);
    node->parent = p;
    if (p == NULL) // empty tree to start with
        root = node;
    else if (node->key < p->key)
        p->left = node;
    else
        p->right = node;

    // readjust balance of all nodes up to the root if necessary
    rebalance(node);
    return true;
}

/**
 * -----------------------------------------------------------------------------
 *  left rotate around node c
 *                       c             b
 *                      / \           / \
 *                     C   b  -->    c   B
 *                        / \       / \
 *                       A   B     C   A
 * adjust parent pointers accordingly
 * -----------------------------------------------------------------------------
 */
template <typename Key, typename Value>
void AVLTree<Key, Value>::left_rotate(AVLNode*& node) {
    if (node == NULL || node->right == NULL) return;

    AVLNode* c = node;
    AVLNode* b = c->right;
    AVLNode* p = c->parent;

    // first, adjust all parent pointers
    b->parent = p;
    c->parent = b;
    if (b->left != NULL) b->left->parent = c;

    // make sure c's parent points to b now
    if (p != NULL) {
        if (p->right == c) p->right = b;
        else p->left = b;
    }

    // finally, adjust downward pointers
    c->right = b->left;
    b->left  = c;

    node = b;                // new local root
    if (root == c) root = b; // new root if necessary
}

/**
 * -----------------------------------------------------------------------------
 *  right rotate around node c
 *                       c             b
 *                      / \           /  \
 *                     b   C  -->    A    c
 *                    / \                / \
 *                   A   B              B   C
 * adjust parent pointers accordingly
 * -----------------------------------------------------------------------------
 */
template <typename Key, typename Value>
void AVLTree<Key, Value>::right_rotate(AVLNode*& node) {
    if (node == NULL || node->left == NULL) return;

    AVLNode* c = node;
    AVLNode* b = c->left;
    AVLNode* p = c->parent;

    // first, adjust all parent pointers
    b->parent = p;
    c->parent = b;
    if (b->right != NULL) b->right->parent = c;

    // next, make sure c's parent points to b
    if (p != NULL) {    // make sure c's parent points to b now
        if (p->right == c) p->right = b;
        else p->left = b;
    }

    // finally, adjust the downward pointers
    c->left  = b->right;
    b->right = c;

    node = b;                // new local root
    if (root == c) root = b; // new root if necessary
}

/**
 * -----------------------------------------------------------------------------
 *  node points to the root of a sub-tree which just had a height increase
 *  we assume the invariance that node's parent is not unbalanced, which
 *  certainly holds for the first node that got inserted
 *  the 'balance' field of the parent may not be correct and we have to
 *  adjust that too
 * -----------------------------------------------------------------------------
 */
template <typename Key, typename Value>
void AVLTree<Key, Value>::rebalance(AVLNode* node) {
    AVLNode* p = node->parent;
    if (p == NULL) return;

    // first, recompute 'balance' of the parent; node got a heigh increase
    if (p->left == node)
        p->balance++;
    else
        p->balance--;

    // if there's no grandparent or if the parent is balanced then we're done
    AVLNode* gp = p->parent; // the grand parent
    if (gp == NULL || p->balance == AVLNode::BALANCED) return;

    // if we get here then the parent p just got a height increase
    // next, see if the grand parent is unbalanced
    if (node == p->left) {
        if (p == gp->left) {
            if (gp->balance == AVLNode::LEFT_HEAVY) {
                // this is the LL case
                //        gp(+2)          p (0)
                //       /   \           /  \
                //      p(+1) B  -->   node  gp (0)
                //     / \                  / \
                //   node A                A   B
                p->balance = gp->balance = AVLNode::BALANCED;
                right_rotate(gp);
                return;
            }
        } else { // p == gp->right
            if (gp->balance == AVLNode::RIGHT_HEAVY) { // the RL case
                // this is the RL case
                //        gp(-2)               node(0)
                //       /   \                 /   \
                //      A    p(+1)    -->     gp(x) p(y)
                //           / \              /\   / \
                //         node D            A  B C   D
                //         / \
                //        B   C
                //  computing the new balance is a little trickier, depending on
                //  with of B & C is heavier
                switch (node->balance) {
                case AVLNode::LEFT_HEAVY:
                    p->balance  = AVLNode::RIGHT_HEAVY;
                    gp->balance = AVLNode::BALANCED;
                    break;
                case AVLNode::BALANCED: // only happens if B & C are NULL
                    p->balance  = AVLNode::BALANCED;
                    gp->balance = AVLNode::BALANCED;;
                    break;
                case AVLNode::RIGHT_HEAVY:
                    p->balance  = AVLNode::BALANCED;;
                    gp->balance = AVLNode::LEFT_HEAVY;
                    break;
                }
                node->balance = AVLNode::BALANCED;
                right_rotate(p);
                left_rotate(gp);
                return;
            }
        }
    } else { // node == p->right
        if (p == gp->right) {
            if (gp->balance == AVLNode::RIGHT_HEAVY) {
                // this is the RR case
                //        gp(-2)              p(0)
                //       /   \               /  \
                //      A   p(-1)    -->  gp(0) node
                //           / \          / \   / \
                //          B  node      A   B
                p->balance = gp->balance = AVLNode::BALANCED;
                left_rotate(gp);
                return;
            }
        } else { // p == gp->left
            if (gp->balance == AVLNode::LEFT_HEAVY) {
                // this is the LR case
                //        gp(+2)          node(0)
                //       /   \            /   \
                //     p(-1)  D   -->   p(x)   gp(y)
                //     /  \             /\     / \
                //    A    node        A  B   C   D
                //         / \
                //        B   C
                //  computing the new balance is a little trickier, depending on
                //  with of B & C is heavier
                switch (node->balance) {
                case AVLNode::LEFT_HEAVY:
                    p->balance  = AVLNode::BALANCED;
                    gp->balance = AVLNode::RIGHT_HEAVY;
                    break;
                case AVLNode::BALANCED: // only happens if B & C are NULL
                    p->balance  = AVLNode::BALANCED;
                    gp->balance = AVLNode::BALANCED;;
                    break;
                case AVLNode::RIGHT_HEAVY:
                    p->balance  = AVLNode::LEFT_HEAVY;
                    gp->balance = AVLNode::BALANCED;;
                    break;
                }
                node->balance = AVLNode::BALANCED;
                left_rotate(p);
                right_rotate(gp);
                return;
            }
        }
    }

    rebalance(p);
}

Insertion as desribed above runs in time O(log n) because it involves one pass down and one pass up the tree’s height. Also, we use the node structure which has a parent pointer to simplify the code. We do not need parent pointers, but without them we will then probably have to use a stack to move up after an insertion.

Removing a node from an AVL tree has two steps:

• The first step is done in the same way as a normal BST. If the node has at most one child then we splice it. Let v be its child (or NULL). If the node has two children, we find its successor (which is the minimum node on the right subtree) and splice the successor, put the successor’s payload in the node’s payload. In this case, let v be the successor’s other child (which could be NULL).
• In the second step, we fix the balances of all nodes from v up to the root and perform rotations accordingly. The strategy is exactly the same as that in the insertion case with one key difference: we might have to do more than one single/double rotations, all the way up to the root. In this case, the subtree rooted at v just lost 1 from its height.

  Consider, for instance, the case when v is the left child of its parent. We will have to rebalance at v‘s parent if it was already right-leaning. Let u be v‘s sibling. If u is left leaning then we do a double rotation. Otherwise, a single rotation at the parent node will suffice. Then, we repeat the strategy if there is an overal height reduction at the parent node.

Exercise: complete the AVLTREE::remove() function.

2. Red-Black Trees

Red Black trees were proposed by Rudolf Bayer in 1972, and refined by Leonidas J. Guibas and Robert Sedgewick in 1978. Guibas and Redgewick presented the coloring scheme and the name RB tree sticks. RB trees are found in many practical search structures. C++’s std::map and std::set are typically implemented with a red-black tree, so are symbol tables in many operating systems and other languages.

One way to describe the intuition behind a RB tree is as follows. In a perfectly balanced tree all the paths from a node to its leaves have the same length. However, this property is way too strong to be maintainable. Hence, we will design a balanced BST by keeping a “skeleton” of black nodes which have the aforementioned property of a perfectly balanced tree. At the same time, we cut the tree some slack by allowing some other nodes to be red, positioned at various placed in the tree so that the constraint is looser. However, we cannot give the red nodes too much freedom because they will destroy the balance maintained by the black skeleton. Thus, we will enforce the property that red nodes can not have red children. This way, red nodes are positioned scatteredly throughout the tree giving the “right” amount of slack while keeping the tree mostly balanced.

Rigorously, a red-black tree is a BST with the following properties:

• (Bicolor property) All nodes are colored red or black
• (Black root and leaves) The root and the leaves (the NULL nodes) are colored black
• (Black height property) For every internal node v, the number of black nodes we encounter on any path from v down to one of its leaves are the same. This number is called the black height of v. Note that the black height of a node does not count the node’s own color.
• (Black parent property) A red node must have a black parent. Or, equivalently, every red node must have two black children. This is the property that ensures the sparsity of red nodes.

Here is an example of what a RB tree looks like.

2.1. RB trees have logarithmic heights

Consider any RB tree T. Suppose we lump together every red node with its parent (which must be black); then, we obtain a tree T' which is no longer a binary tree. The tree T' will be a (2,4)-tree (or 2-3-4 tree), where each internal node has 2, 3, or 4 children. If the RB tree shown above is T, then its 2-3-4 counterpart is

Let h be the height of T and h' be the height of T'. Also, let n be the number of keys in T. First of all, we claim that the number of black leaves (squares in the pictures) is exactly n+1. This is because the RB tree is a full binary tree and from that we can prove this claim by induction. (Sketch: if the left subtree of the root has a keys and the right subtree has b keys, then there are totally a+b+1 keys in the tree and (a+1)+(b+1) leaves by the induction hypothesis.)

Now, due to the 2 to 4 branching factors, the number of leaves varies between 2h' and 4h': . By the black parent property, the height of T' is at least half the height of T. Hence,

2.2. How to maintain the RB properties

After an insert. We will always color the newly inserted node red, unless it is the root in which case we color it black. Call the newly inserted node z.

If z or its parent is black, then there is nothing to do. All properties are still satisfied.

Now, suppose z‘s parent is red. Then, we have the double red problem. We fix this problem by considering the following cases.

• If z‘s uncle is red, then we recolor z‘s parent and uncle black, grandparent red (it had to be black before), and consider the grandparent the new z. We potentially have a new double red problem but it is now higher up in the tree. If z‘s grand parent is the root then we color it black and we are done. The following picture illustrates this case.

  

• If z‘s uncle is black then there are two subcases which can be resolved with either a single rotation or a double rotation as seen in the following pictures.

  

  

After a delete. When we delete a node from a BST, we either splice it or splice its successor. Let z be the children of the node that got spliced. If we spliced a red node, then we’re done; there is nothing to fix. Suppose we spliced a black node. In this case, we will violate the black height property of all ancestors of z (except for the trivial case when z is the root or when z‘s parent is the root).

Conceptually, if z was allowed to have “double blackness” then the black height property is not violated. Note that z‘s sibling cannot be a leaf node; thus, the sibling must have two children. We consider three cases as follows.

• z‘s sibling is black with a red child. In this case, we do a single or double rotation and color that child black. In essence we give that red child one of z‘s “blackness”. The fact that z is double black also indicates that the subtree rooted at z is a little short on height; and, the fact that the sibling’s side has a red node means that side has extra height to spare. Overall, a rotation toward z‘s side makes sense. The following pictures illustrate the two sub-cases:

  

  

• z‘s sibling is black with both black children and the parent is red. In this case, we color the sibling red, parent black, and we are done:

  

• z‘s sibling is black with both black children and the parent is black. In this case, we color the sibling red, parent double black, and move the double black problem up the tree.

  

• Finally, if z‘s sibling is red we perform a single rotation, give the sibling the parent’s color, and the parent red color. As z‘s new sibling is black, we are back to one of the previous cases.

  

3. (2,4)-Trees

A (2,4)-tree, also called a 2-3-4 tree was invented by Rodolf Bayer in 1972. It is a special case of B-trees and multiway search trees. So let’s talk about a multiway search tree first.

In a multiway search tree, nodes no longer are restricted to having 2 children and holding one key. Nodes can hold multiple keys. A d-node is a node that holds d-1 keys and have d children. Let K1 ≤ K2 ≤ ... ≤ Kd-1 be the keys stored at this node. And, let v1, v2 … vd be the d children pointers. Then, in a multiway search tree, for every d-node, it must hold that the keys of the vi subtree is in between Ki-1 and Ki as shown in the following picture. (We implicitly understand that K0 is minus infinity and Kd is plus infinity.)

Here’s an example of a multiway search tree.

Searching in a multiway search tree is straightforward: to search for key K, we find the index i such that Ki-1 < K < Ki and follow link vi.

Exercise: Similarly, you should think of the algorithms for finding the maximum, minimum, successor, and predecessor.

Exercise: Does a pre/in/post-order traversal of a multiway search tree make sense? How about a levelorder traversal? How do you write codes for a levelorder traversal of a multiway search tree?

A (2,4)-tree is a multiway search tree with two additional properties:

• Size property: all internal nodes in the tree are 2-, 3-, or 4-nodes. In particular, every internal node holds 1, 2, or 3 keys.
• Depth property: every leaf of a (2,4)-tree are at the same depth, called the depth of the tree.

Here is a sample (2,4)-tree:

3.1. A (2,4)-tree has logarithmic height

First, we show that the number of leaves of a (2,4)-tree is precisely n+1 where n is the number of keys stored in the tree. This holds for any “branching trees”, which are trees in which every internal node has at least 2 children. So, we prove this fact for branching trees. The proof is by induction on the height of the tree.

If the tree has height 0 then the root is a leaf which stores no key. If the tree has height 1 then this is certainly the case because when the root is a d-node it has d children (which are leaves) and stores d-1 keys. If the tree has height at least 2, again suppose the root is a d-node. Let be the number of keys stored in the d subtrees of the root. Since all sub-trees of the root are also branching trees, by the induction hypothesis the total number of leaves is where is the total number of keys in the entire tree. Here, we used the fact that the root stores keys.

Next, let be the height of a (2,4)-tree, by the same reasoning as in the RB tree case we have which implies .

3.2. How to maintain the (2,4)-tree properties

We will assume that we do not store duplicate keys.

After an insert. We insert a new key into a (2,4)-tree in the following way. We search for it in the tree. If the new key is found then we do nothing because duplicate keys are not allowed. If the new key is not found, then we will end up at a leaf node. Let v be the parent of that leaf node. We insert the key into the correct relative position in that node v.

Prior to the insertion of the new key, if v was a 2-node or a 3-node, then we are OK because after the insertion of a new key v is at worst a 4-node. However, if v was already a 4-node then we have the overflow problem we need to resolve. The solution is intuitive: we split the node into two, bring a middle key up one level as shown in the following picture:

In the worst-case, the updates are propagated up to the root and we have an increase in tree height

The run time is proportional to the height of the tree which is logarithmic, and both the size property and the depth property are still satisfied.

After a delete. To delete a key from a (2,4)-tree, we use the strategy similar to that of the BST case. If the key is at the lowest level, we simply remove it. If the key is at some node higher up, we find the successor key which is the left most key on the right subtree (of the key to be removed), replace the key with its successor, and remove the successor.

The problem occurs when we try to remove a 2-node (which is at the lowest level, next to the leaves): the problem is called an underflow problem. To solve the underflow problem, we consider the following cases.

• If the node to be removed has an adjacent sibling which is a 3-node or a 4-node, we perform a “transfer” as shown in the following picture, which hopefuly is self-explanatory:

  

• If the node to be removed has only one adjacent sibling which is a 2-node, or has 2 adjacent siblings both of which are 2-nodes, then we perform a fusion as shown in the following picture:

  

  The fusion might cause an underflow at the parent node, in which case we repeat the process:

  

  The fusion may propagate all the way up to the root, in which case we have a height reduction of the tree.

4. Splay trees

Splay trees are a self-adjusting binary search trees invented by Dan Sleator and Bob Tarjan in 1985. It does not require any additional field in each node such as color or balance. All operations have amortized cost O(log n). In addition, frequently accessed nodes are closer to the root.

In a splay tree, insertion, deletion, and search are done exactly in the same way as in a normal BST, with one additional splay(c) step, where c is a node to be defined later.

4.1. Splaying

To “splay” a node c, we perform O(height of tree) baby steps. Each of these baby steps is either a zig-zig, zig-zag, or zig defined as follows.

• zig-zig is performed when c has a grandparent and its side (left or right) with respect to its parent is the same as its parent’s side with respect to its grandparent.

  

• zig-zag is performed when c has a grandparent and it is on a different side of its parent than its parent is with respect to the grandparent.

  

• zig is performed when c‘s parent is the root.

  

To splay a node c, we repeatedly perform the baby steps until the node is floated up all the way to the root. The cost of splaying is proportional to the height of the splayed node.

4.2. Which node to splay and why it works

After a search, we splay the node whose key is found; or, if the key is not found then we splay the last non-NULL node seen in the search.

After an insert, we splay the newly inserted node.

After a delete, we splay the child of the spliced node.

The main question is, why does this work, even just on average? It is conceivable that the tree will become so unbalanced that its height is and thus a search might take linear time. How can we then say that on average an operation takes logarithmic time? Let’s actually construct a sequence of insertions and such that a later search takes linear time. Suppose we insert the keys 1, 2, …, n in that order. After each insertion, the key ends up on the right node of the root, and a zig operation brings it up top.

Insert 1:
1
Insert 2:
1                  2
 \    -- zig -->  /
  2              1
Insert 3:
  2                3
 / \  -- zig -->  /
1   3            2
                /
               1
and so on

Now, after n insertions as described, when we search for key 1, we will have to take about n steps to get down to the left-most branch, and then about n/2 splaying baby steps to bring 1 up all the way to the root. Overall, we spent cn units of time where c is some constant. What is going for us is that the price we paid for all of the previous insertions were also some constants. And thus, when we distribute the total cost over n+1 operations we will still have a small cost per operation.

For example, if each of the inserts took d units of times, then the total price we pay per operation is which is a constant! We will transfer this intuition into an (amortized) analysis by giving each operation a budget of “dollars.” Then, we show that the money left in the accounts of all the nodes plus the new dollars are always sufficient to pay for any of the operations. If an operation costs less money, we will deposit the residual amount to the accounts to pay for future and potentially more expensive operations.

4.3. Analysis

Define the “size” of a node v, denoted by n(v), in a splay tree to be the number of keys in its subtree. And, call the “rank” of a node, denoted by r(v), the value log2(2n(v)+1). Note that the ranks and the sizes will change over time.

Let P be an operation to be performed: search, insert, or delete. Let cost(P) denote the cost of performing P. Our strategy is to make a “deposit” D(P) (in “miliseconds”, or “dollars”) for operation P in such away that the deposit plus what ever amount of “money” we still have in the tree is sufficient to pay for the cost of the operation. Our ultimate objective is to prove that

If each operation P has a deposit of D(P) = c*log(n) dollars, then the splay tree “bank” will always have sufficient fund to pay for all operations. In particular, the amortized cost of search, insert, and delete in a splay tree is O(log n)

The splay tree bank is organized as follows. The bank maintains a strict accounting policy:

The invariant: Every node v in the tree will have an account that has dollars in it.

We will make sure that each operation P on the tree deposits an amount D(P) sufficient for the invariant to hold. The invariant certainly holds when the tree is empty, i.e. when it has only 1 NULL node whose rank r(v) = 0.

Let r(T) denote the total amount of money the bank T (i.e. a splay tree) possesses, called the banking reserve:

In order to maintain the invariant after an operation P is performed on the tree, we must make sure that the deposit D(P) is sufficiently large so that

where T' is the tree resulted from performing operation P on T. In other words, we want the variation in bank reserves to be small relative to the newly deposited amount:

Thus, in order to determine how much D(P) should be, we need to determine the variation after each pair of operations: P = insert + splay, P = delete + splay, P = search + splay. For example, an insert changes the tree from T to Tin, and then the splaying changes the tree from Tin to T'. And, because

we can assess the variations separately instead of assessing the variations for each pair insert + splay, delete + splay, and search + splay.

In what follows, let T' be the tree after an operation was performed (search, insert, delete, splay, or baby step), and T be the tree before the operation.

After a delete: r(T') can only be smaller than r(T) because the ranks of all nodes from the deleted node up to the root are reduced. Hence, in this case r(T') - r(T) ≤ 0.

After a search: r(T')-r(T)=0.

After an insert: suppose we just inserted node at depth , and is the path from up to the root of the tree. Then, the difference in bank reserve amounts is

where is the rank of node after the insertion. Also, let be the size of node after the insertion. Then, , , and so on, up to . Thus, for every . Consequently,

After a splay: since a splay operation consists of many baby steps, let us estimate the banking reserve difference after each baby step. Please refer to the pictures above in the following derivation. We will use the fact that, for any two real numbers ,

(*)

Because, the inequality is equivalent to which is equivalent to .

• zig-zig: after zig-ziging node c up two levels, from inequality (*) we can see that . The banking reserve difference can then be bounded by:
  

  The last inequality follows from the fact that and .

• zig-zag: after zig-zaging node c, from inequality (*) we know . Thus, the difference can be bounded by
  

• zig: in this case,
  

In conclusion, after a zig-zig or zig-zag, the banking reserve difference is at most , and after a zig the difference is at most . Now, when we splay node at depth all the way to the root, there will be baby steps all of which are zig-zig or zig-zag except for possibly the last step.

Let be the rank of before any baby step is done, be the rank of after the th baby step for . Then, the net banking reserve difference is at most

Now, recall the inequality

that we wanted to maintain after each pair search + splay, insert + splay, and delete + splay. We need to determine the deposit D(P) to be made for operation P.

Consider first the pair P = search + splay. Let d be the depth of the splayed node. Then, the cost of this operation is proportional to d; and, by a change of currency we can assume that it costs exactly d dollars. We have shown that the net banking reserve difference after search + splay is bounded by

Hence, if we deposit an amount we would have enough to cover the cost plus the extra banking reserve needed. Note that .

The analysis for the pair delete + splay is similar.

For insert + splay, the net difference is

and thus a deposit is also sufficient.

5. Experimental performance analysis of balanced search trees

We have analyzed some of the most important balanced BSTs. They perform well theoretically by ensuring that each operation takes logarithmic time (worst-case or on average). With theoretically identical performance like this, we do not have a good basis for picking which data structure to use in a real-world problems. In such case, the only choice is to implement them all and see which one fits best for the problem at hand.

Fortunately, Ben Pfaff has done an set of experiments like that. Here’s the report. There are many interesting conclusions drawn from the experiments; the following is probably more relevant to this course:

We found that in selecting data structures, unbalanced BSTs are best when randomly ordered input can be relied upon; if random ordering is the norm but occasional runs of sorted order are expected, then red-black trees should be chosen. On the other hand, if insertions often occur in a sorted order, AVL trees excel when later accesses tend to be random, and splay trees perform best when later accesses are sequential or clustered.

For node representation, we found that parent pointers are generally fastest, so they should be preferred as long as the cost of an additional pointer field per node is not important. If space is at a premium, threaded representations conserve memory and lag only slightly behind parent pointers in speed.