Messages posted by: alice

Mnh đang kết nối 2 máy tính với nhau, dùng cáp chéo. PC1 (2card mạng, 1 nối vào modem ADSl, 1 nối vào PC2) cài ISA, Exchange và nó là server luôn. PC2 chỉ là máy con. PC1 mình đã cấp DHCP, DNS. Mình cũng tạo các access rule trong ISA de cap quyền cho tất cả các user như: DHCP request, DHCP reply, DNS server... Và PC 2 cũng dc cấp DHCP từ PC1. Nhưng máy PC2 vẫn ko vào được internet (mình đã thử các DNS, IP) Mình thử cho PC2 join vào domain nhưng vẫn không được (Ip cùng lớp mạng). Mình đang thắc mắc là không biết có phải do mình đang sử dụng internet thông qua truyền hình cáp nên gặp những vấn đề đó không. Có anh chị nào sử dụng qua, hoặc có kinh nghiệm chỉ giúp mình.

Bạn viết rõ ràng hơn một chút được không. ADSL là ADSL, cable là cable, "ADSL qua cable" là thế nào? Thế nào là "đã cấp DHCP"? Thế nào "đã cấp DNS"? Thế nào là "cấp quyền DNS server cho user"? Thế nào là "đã thử các DNS, IP"?

Một checksum là một dạng redundancy check, một cách đơn giản để bảo vệ tính toàn vẹn dữ liệu bằng cách dò lỗi. Nó làm việc bằng cách thêm vào những thành phần cơ bản của một message, điển hình là các bit xác nhận và lưu trong giá trị kết quả. Bất kỳ ai sau đó có thể thực hiện các hành động tương tự trên dữ liệu, rồi so sánh kết quả với checksum thực, để kết luận xem message là probably hay gián đoạn.

Hic hic, alice xin chữa lại các từ trên:

Một checksum là một dạng redundancy check, một cách đơn giản để bảo vệ tính toàn vẹn dữ liệu bằng cách dò lỗi. Nó làm việc bằng cách cộng những thành phần cơ bản của một message (điển hình là các bit cần xác nhận) với nhau, và lưu giá trị kết quả. Bất kỳ ai sau đó có thể thực hiện các hành động tương tự trên dữ liệu, rồi so sánh kết quả với checksum thực, và nếu hai tổng đó bằng nhau thì kết luận message có lẽ không bị hủy hoại.

lengoctoan wrote:

mình muốn học lập trình nhưng ko biết nên bắt đầu bằng ngôn ngữ nào?

Bạn muốn học lập trình (nói chung), hay là lập trình hệ thống? Hai việc đó khác nhau đó nha. smilie

)

lengoctoan wrote:

Mình thường thấy người ta bắt đầu bằng C, rồi lên C++ ko biết có đúng ko

Đúng, nếu học lập trình hệ thống.

Kiến thức về ASM cũng cần thiết, chắc còn cần thiết hơn C++.

prof wrote:

Trước tiên, hoàn toàn đồng ý với alice ở điểm ICV không phải là DS. ) Tuy nhiên, khi viết đoạn này, ý đồ của mình không nhằm so sánh DS và ICV. Mình tuy là kẻ *ngâm cứu* không chuyên về applied crypto. & its related stuffs nhưng cũng may mắn hiểu được sự khác biệt về phạm vi ứng dụng, và về bản chất của DS. Trong phạm vi bài này, mình sử dụng DS với mục đích giúp người đọc hiểu được những lợi điểm do ICV đem lại, kiểu như dùng một thuật ngữ đã quen thuộc để giải thích cho một thuật ngữ mới hơn. Có lẽ chúng ta đều biết DS có khả năng cung cấp tính xác thực (Authentication), tính toàn vẹn (Integrity), và tính chống phủ nhận (Non-repudiation). ICV trong AH Header cũng hội đủ các điều kiện để cung cấp 2 trong 3 khả năng này. Vì vậy, ở một khía cạnh hẹp & trực quan nào đó, ICV mang đặc điểm của DS.

Mình cũng đã từng gặp ở một số tài liệu khác, khi đề cập đến một intemediate device/application/middleware/..., người viết thường mượn thuật ngữ proxy server nhằm mục đích nói lên tính trung gian của đối tượng đang xét, mặc dù nếu khắt khe hơn, thì proxy server không thể là đối tượng mà họ đang bàn. Đó chỉ là một ví dụ khá *thô* về cách dùng thuật ngữ mà thôi. )

Anyway, có lẽ mình đã lạm dụng thuật ngữ DS này nên dẫn đến hiểu lầm. Prof sẽ chỉnh sửa lại đoạn này bằng việc bỏ đi thuật ngữ DS.

Ồ, alice thật có lỗi khi đã viết ở đó 1 câu bình cộc lốc. Thực sự, các bài viết của prof ở HVA vài năm nay đã chứng tỏ một kiến thức sâu rộng về cryptography và các ứng dụng của nó, còn lối diễn đạt dễ hiểu và phong cách tranh luận khiêm tốn đã thể hiện tính chuyên nghiệp rất cao. Một khi prof. prof tự đánh giá mình là người nghiên cứu "không chuyên" thì alice phải hoảng hốt tự nhận mình là kẻ "tà ma ngoại đạo" thui smilie

) . Nếu được viết lại, alice sẽ viết thế này:

"Sự ví von rất hay, đã làm cho giải thích thêm phần dễ hiểu. Tuy nhiên, nếu viết từ chữ ký trong "nháy nháy" và không mở ngoặc viết thêm phụ đề Anh ngữ digital signature (DS) thì thuật ngữ sẽ không bị "đụng hàng" và tính chất ví von sẽ được thể hiện rõ nét hơn nữa. :! smilie

) "

Khi tính chống phủ nhận (non-repudiability) đã được đề cập, luôn tiện nói thêm, nhóm giao thức IPSEC không có tính chất này. Đó không phải là một thiếu sót. Ngược lại, plausible deniability (tính phủ nhận được?) là cần thiết. Nhờ thế An và Bình có thể liên lạc với nhau mà sau này có thể "cãi bay chối biến" vì không để lại chứng cứ nào về sự liên lạc. Giám định viên tư pháp muốn tìm chứng cứ chống lại An cũng đành phải bó tay ngay cả khi Bình bội bạc với An. smilie

)

Plausible deniability là một trong những mối quan tâm khi thiết kế IPSEC và ở một chừng mực nào đó, đã được đảm bảo.

prof wrote:

alice wrote:

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?.

Chà, xem ra "người đọc" muốn mở rộng thêm vấn đề về tính tương thích giữa NAT và việc cố định cổng nguồn của IKE đây. Trường hợp này, có lẽ phải mời người tham khảo thêm RFC 3715 để biết chi tiết. ) Phải thừa nhận một điều là còn khá nhiều vấn đề giữa NAT và IPSec mà prof chưa thể nói hết. Bởi vậy, ngay từ đầu, mình chỉ dám đi sâu một chút, vì biết sẽ không đủ sức. Nếu alice hay bạn nào đó có thời gian, các bạn có thể bổ sung thêm những vấn đề mà mình chưa đề cập đến.

Ớ, RFC 3715 đâu có giải thích tại sao IKE cố định cổng nguồn đâu, chỉ nói ra điều đó thui muh smilie

). Một cách nghiêm túc, RFC này tổng kết 16 điểm không tương thích NAT -- nguyên văn: NA(P)T -- của nhóm giao thức IPSEC, đánh số từ a) đến p), trong đó có 9 điểm đầu tiên thuộc loại thâm căn cố đế (intrinsic). Việc cổng nguồn IKE cố định được prof lấy làm thí dụ, nếu alice hiểu không lầm, là điểm d), chỉ được RFC nêu ra như là một thực tế "ngời ngời như chân lý" thôi. Cho dù đó là thực tế, alice không nghĩ rằng nó hiển nhiên như một yêu cầu chuẩn định (normative).

Đó là điều mà trong bài trước alice đã muốn "nói rõ thêm một chút mà không biết nói thế nào". smilie

)

Còn việc mở rộng vấn đề ra một cách rõ ràng và đầy đủ, alice cũng không có nguyện vọng đó. alice biết mình không đủ qualified và mặt khác, nhất trí hoàn toàn với prof, RFC 3175 đã gọn ràng đến mức khó có thể trình bày lại vấn đề cho gọn gàng hơn. Không tương thích IPSEC với NAT là một "tổ kiến lửa" mà việc "chọc" vào nó là không thích đáng trong phạm vi của một bài tut. smilie

)

Thử lúc 4 giờ sáng giờ Hà Nội, từ một nơi ngoài nước VN (nhìn IP thì biết smilie

) ).

vnhacker.org cũng nhanh như hvaforum.net. Load 1 trang mất 1-2 giây.

Bài bổ sung của prof rất tốt, alice chỉ nghĩ có thể bài viết sẽ dễ hiểu hơn nếu thay đổi vài điểm về thuật ngữ. smilie

)

prof wrote:

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một chữ ký số (Digital Signature - DS) được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán DS nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.

Dùng từ ICV là đủ, tránh dùng từ DS. ICV nói chung không phải là DS và thực tế không phải là DS.

prof wrote:

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP thường được xem như là sự kết hợp của IPSec với NAT. ESP thường được sử dụng trong chế độ tunnel. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.

Chỗ IPSec màu vàng có vẻ khó hiểu. Đối tượng đang được giải thích là IPSEC. ESP là một phần của IPSEC. Sẽ không hợp lý lắm khi đem IPSEC để giải thích ESP.

Khi đưa TCP/UDP vào cuộc, cũng nên nói rõ hoàn cảnh sử dụng là ESP bao bọc TCP/UDP. Để phân biệt với hoàn cảnh UDP bao bọc ESP (NAT-T) mà loạt bài sẽ nói đến về sau.

prof wrote:

Trong chế độ Tunnel ESP, NAT hoàn toàn được tương thích vì toàn bộ gói tin nguồn bao gồm các thông tin về IP và thông tin ở tầng 4 được đóng gói và do đó không bị xử lý bởi NAT. Vì thông tin về IP, TCP header, TCP checksum không bị thay đổi trong chế độ Tunnel ESP nên gói tin sẽ được giải mã và thoả mãn tính toàn vẹn. Tuy nhiên, mặc dù ESP traffic trong chế độ Tunnel có thể tương thích với NAT, bạn sẽ gặp phải các vấn đề liên quan đến NAT khi thương lượng các tham số cho IPSec connection. Chẳng hạn, one-to-many NAT (thường được hiểu là PAT) sẽ sửa đổi tham số cổng nguồn của một outbound IKE packet, dẫn đến giá trị cổng UDP 500 dành cho IKE bị thay đổi, từ đó dẫn đến việc thất bại khi phân phối khoá cho các tham số của IPSec session.

Đoạn này có thể xem như có 2 phần:

Phần NAT màu vàng thứ nhất nói về tính tương thích của NAT với ESP. Ở đây nên làm rõ thêm từ NAT bởi một từ khác (thí dụ, basic NAT theo tự điển wikipedia), ngụ ý rằng ở đây chỉ có dịch địa chỉ mà thôi. Cũng nên nói rõ thêm NAT trong trường hợp chung (bao hàm PAT) với ESP trong chế độ tunnel là không tương thích bởi vì khác với TCP/UDP, ESP không có khái niệm "cổng". Như thế người đọc sẽ không phải thắc mắc đại loại như nếu ESP tunnel và NAT đã tương thích với nhau, tại sao phải dùng UDP bao bọc ESP để có NAT-T?

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ smilie

), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?.

prof wrote:

Một vấn đề còn đang tranh cãi nữa là khả năng xác thực của ESP. Như ta đã biết, ESP có khả năng cung cấp cơ chế xác thực, nhưng giá trị băm mà nó sử dụng được sinh ra dựa trên toàn bộ gói tin ngoại trừ phần IP header và phần authentication trailer. Điều này giúp cho ESP authentication tương thích với NAT, nhưng việc thiếu xác thực của IP header sẽ không đảm bảo được nguồn gốc của gói tin. May thay, trong hầu hết các cài đặt, việc kiểm tra tính xác thực cho phần payload của ESP cũng đủ để nói lên nguồn gốc của gói tin này!

Theo alice, cụm từ payload của ESP có lẽ sửa thành IP payload hoặc cụ thể hơn 1 chút thì ESP header mới đúng. Như chính prof đã nói, authentication trailer xác thực không những ESP payload mà còn cả ESP header, trong đó có SPI (security parameter index), từ đó dựa theo SAD (security association database) tra được địa chỉ IP của người gửi. Nói cách khác, với một chi phí tính toán thích đáng, cài đặt không cần phải xác thực IP header vẫn xác thực được địa chỉ IP nguồn của gói tin.

Cám ơn thangdiablo, prof, Mr. Khoai và các bạn khác vì một loạt bài lý thú. smilie

)

Bài thứ nhất của hatoroy nêu chất vấn, đã được phuongdong trả lời. Bài thứ hai hatoroy không nêu ra được tình tiết mới nào, không chỉ ra và thậm chí cũng hề cố gắng chỉ ra những điểm nào mà bạn chưa thỏa mãn trong bài trả lời của phuongdong, như vậy là chất vấn vô cớ.

Đứng trước một chất vấn vô cớ, không ai có nghĩa vụ phải trả lời. Thế nhưng conmale và nhất là Mr. Vampire đã chịu gánh lấy nghĩa vụ ấy. Để làm việc ấy phải hi sinh một phần bí mật cá nhân. Như vậy họ đã nhận phần thiệt về mình mà lại còn nhận một cách vui vẻ nữa chứ! Về lýmà nói, họ không phải chịu khổ như thế. Chẳng qua chỉ vì muốn vẹn cái chữ tình.

Alice vui mừng vì việc này đã được giải quyết êm đẹp. Nhưng Alice không mong muốn nhìn thấy bất cứ HVA member nào phải gánh lấy trách nhiệm trình bày lý lẽ trước những chất vấn vô cớ. Nhất là trong những vấn đề liên quan đến pháp luật như là vấn đề tác quyền, nơi chứng minh danh tính mà không phải xâm phạm bí mật thư tín, điện thoại, điện tín của công dân là một việc hết sức khó khăn.

Chào mọi người, alice xin phép nói ý kiến cá nhân.

Về bài của Mr. Vampire. Như phuongdong đã chứng minh, Mr. Vampire đã khẳng định mình là tác giả bài viết và cũng qua đó khẳng định mình chính là doikengheo ở HVA. Trừ phi doikengheo ở HVA, doikengheo@gmail.com hay một người nào đó khác nhận mình là tác giả tới đây tranh chấp với những chứng cứ rõ ràng, Mr. Vampire không cần phải lên tiếng khẳng định lại một lần nữa.

Về bài của moonlight123. Bài viết có nêu tên tác giả nhưng không nêu rõ lấy từ nguồn nào là vi phạm yêu cầu tôn trọng bản quyền qui định bởi điều I mục 5 nội qui HVA; có hình thức trình bày sơ sài hơn bài của Mr. Vampire; được đăng sau và có nội dung giống hệt như bài của Mr. Vampire như vậy là trùng lặp, vi phạm điều IV gạch đầu dòng thứ nhất nội qui HVA. Vì những lý do đó, alice đề nghị BQT chiểu theo nội qui HVA câu thứ 4 từ dưới đếm lên, xóa bài viết đó.

Kính,

Alice.

Cám ơn bạn viethoang_vn. Từ khóa "Đồng Nai" đã giúp alice tìm được 1 sản phẩm tên là Cổng an toàn thông tin trên công nghệ cách ly phi chuẩn (non-standard security portal, NSSP) của Sở KH Đồng Nai, tác giả TS. Phạm Văn Sáng, đoạt cúp vàng Giải thưởng Công nghệ thông tin - Truyền thông Châu Á - Thái Bình Dương (APICTA) 2006.

http://www.most.gov.vn/Muccd/Trangtindiaphuong/nam2006/mldocument.2006-11-07.8742343644/mlnews_view

http://www.hca.org.vn/tin_tuc/thoi_su/nam2006/thang11/giaithuongApicta

http://www.dongnai.gov.vn/thong_tin_KTXH/tin_noi_bat/tin_thuong_truc/mlnews.2006-11-06.0943200066?set_language=en&cl=en

Cả 3 link trên thực ra chỉ là 1 bài. Xin trích 1 đoạn:

Trong đó, Việt nam có sản phẩm "Cổng an toàn thông tin trên công nghệ cách ly phi chuẩn" của Sở KH&CN Đồng Nai là sản phẩm đạt giải nhất trong lĩnh vực an toàn thông tin, được tặng thưởng cúp vàng. Sản phẩm "Cổng an toàn thông tin trên công nghệ cách ly phi chuẩn" ( gọi tắt là NSSP) được nghiên cứu và phát triển lần đầu tiên ở Việt Nam, có những đặc điểm vượt trội so với các công nghệ đang được sử dụng. NSSP tạo ra một môi trường cách ly hoàn toàn về mặt giao thức TCP/IP giữa mạng nội bộ được bảo vệ với hệ thống Internet bên ngoài nhưng dữ liệu truyền giữa các mạng nội bộ qua Internet vẫn bình thường. Người dùng hoàn toàn làm chủ trong việc xây dựng và thiết lập các chính sách về an toàn thông tin cho hệ thống. Một trong những đặc điểm quan trọng của hệ thống là người dùng hoàn toàn làm chủ và quản lý khóa mã, các thuật giải mật mã cũng như cấu hình và quản lý hệ thống. Khóa mã và các giải thuật mật mã đã được thẩm định về chất lượng và được quản lý phù hợp với các quy định của nhà nước. Giao diện điều khiển cổng an toàn rất gần gũi với người dùng nên dễ dàng trong việc triển khai sử dụng và quản lý hệ thống.
Do NSSP đảm bảo việc cách ly hoàn toàn về mặt giao thức TCP/IP giữa mạng bên trong được bảo vệ (secure LAN) và mạng công cộng (Internet), mọi liên kết được tiến hành thông qua cổng an toàn có mã hoá, thuật toán mã giải mã do cơ quan có trách nhiệm cung cấp, vì vậy tính an toàn của cổng an toàn rất cao. Một máy ở mạng công cộng (không được bảo vệ) không thể truy cập vào mạng bên trong (được bảo vệ). Giảm thiểu mọi khả năng tấn công vào hệ thống và bảo vệ khỏi mọi cuộc tấn công khai thác dữ liệu từ bên ngoài. Ngoài ra trên cổng an toàn còn được hỗ trợ các công cụ phụ trợ khác để tăng thêm khả năng an toàn và kiểm soát hệ thống như :

- Sử dụng công cụ monitoring mạng (SM)

- Sử dụng công cụ phát hiện truy cập (IDS)

- Sử dụng công cụ VA…

- Các công cụ đánh giá rủi ro trên cơ sở phân tích mạng và đánh giá nhận thức về ATTT trên hệ thống thông qua các chính sách về ATTT và một số công cụ An toàn khác.

Để tiếp tục hoàn thiện sản phẩm, Sở KH&CN Đồng Nai đang phát động chương trình tấn công thử nghiệm nhằm có thêm sự góp ý của các chuyên gia trong cộng đồng an ninh mạng đặc biệt là các Hacker giỏi, tâm huyết muốn đóng góp sức lực cho ngành bảo mật chung của quốc gia.

Với ưu thế trên, cổng an toàn NSSP rất phù hợp với các mô hình bảo vệ hệ thống LAN tại các cơ quan như Tỉnh ủy, UBND, các cơ quan như công an, hải quan, xuất nhập cảnh, thông tin giao dịch trong hệ thống ngân hàng, các mô hình CA , e-office , video conferencing…và các hệ thống trọng yếu khác.

Theo những thông tin đó, alice gần như chắc chắn đây chính là sản phẩm mà alice quan tâm trong câu hỏi lúc đầu, chỉ hơi phân vân 1/ tác giả không phải là Nguyễn Quang Sáng, mà là Phạm Văn Sáng 2/ trong bài giới thiệu không thấy nhắc gì đến OPENVPN cả. Mong bạn viethoang_vn hay ai đó biết cung cấp thêm thông tin giải tỏa 2 mối phân vân này.

Xin cám ơn. smilie

)

Chào cả nhà. Gần đây alice nghe nói có một sản phẩm cơ yếu VN tên là "bộ cách ly mạng chuẩn" gì đó (không rõ tên chính xác) đoạt giải tại một hội chợ bảo mật quốc tế. Đã thử google với những từ cơ yếu, cách ly, encryptor, cryptographic device, thậm chí firewall, enclave,... mà chả tìm ra manh mối.

Ai biết gì về sản phẩm đó, xin chia xẻ thông tin:

- Tên chính xác của nó (nếu có tên tiếng Anh càng tốt).

- Ngoại hình (hộp, card PCI, PCMCIA, hay chỉ là phần mềm).

- Tác dụng của nó.

website của nhà sản xuất hay bất cứ tài liệu online nào liên quan cũng đều được hoan nghênh.

Cám ơn nhiều. smilie

)

Link này cũng giải đáp một phần câu hỏi của bạn: http://www.vbulletin.com/forum/showpost.php?p=649676&postcount=41

Đây có lẽ là một hàm băm mật mã (cryptographic hash function). Bạn có thể bắt đầu tìm hiểu từ đây: http://en.wikipedia.org/wiki/Cryptographic_hash_function

Nếu muốn tìm hiểu rõ thêm, bạn có thể tìm đọc sách trong thư viện HVA. Cuốn Mao có vẻ bao quát nhất, còn 2 cuốn Menezes, Schneier cũ hơn nhưng thiên về thực hành nhiều hơn và dễ đọc hơn.

Chỉ mất 20 giây, kẻ tấn công mở khoá được một máy tính Windows có cổng firewire (IEEE 1394). Chi tiết xâm nhập sẽ được một chuyên gia New Zealand trình diễn ngày 30/9/2006 tại một hội nghị có tên "Sydney's Ruxcon security conference".

Phương pháp phòng vệ duy nhất là tắt cổng firewire.

Nguồn: http://www.smh.com.au/news/security/security-conference-to-debut-windows-firewire-crack/2006/09/18/1158431640614.html

Bạn nghe âm thanh cao lên bất thường (giống như hát bằng giọng mũi), phải vậy không? Ở Intel mobo lỗi này thường gặp khi lỡ tay cài 1 driver hai lần (hoặc nhiều lần). Càng nhiều lần, âm thanh càng méo (càng cao). Bạn thử uninstall tất cả những phần mềm đã cài từ CD đi kèm mobo, rồi cài lại chúng xem sao.

Thật khâm phục năng suất và hiệu quả dịch thuật của bác conmale.

alice xin mạo muội góp vài sửa đổi vào bản dịch để bác xem xét. Đa số sửa đổi là lặt vặt, nên alice không nêu lý do. Tuy vậy cũng có vài sửa đổi nhằm đơn giản hoá bản dịch alice chưa dám chắc chắn.

Sau khi bác đã xét, bất kể accept hay reject sửa đổi đó, thì cũng làm ơn xoá luôn bài post này của alice. Thanks.

--------------------------------------------------
Phần 1:

1/ nhân nhượng -> chọc thủng / bẻ gãy / qua mặt. (Nguyên bản dùng từ break.).

2/ Sự thật này trước đây tiềm ẩn hình ảnh hacking như một việc làm đơn độc. Đây cũng là điều cấm kỵ của xã hội hacker chống những thể hiện (cho rằng) động lực thúc đẩy để làm việc đi từ niềm kiêu hãnh hoặc sự công nhận từ bên ngoài
-> Sự thật này trước đây bị lu mờ bởi hình ảnh hacking như một việc làm /hoạt động/ đơn độc, và cũng bởi trong thâm tâm các hacker chống lại những quan điểm cho rằng động cơ làm việc là niềm kiêu hãnh/sự hãnh tiến/ hoặc vinh quang/sự thèm khát vinh quang/

3/ tạo ơn -> tích đức. Xem karma, ở dưới.

Phần 2:

1/ hãy cẩn thận khi chọn -> hãy cẩn thận mà chọn

2/ tam giác thức -> lượng giác

3/ tích phân -> giải tích

4/ số học Boolean -> đại số Boole

5/ giới hạn thuộc về toán -> toán rời rạc

6/ lý thuyết giới hạn -> lý thuyết tập [hợp] hữu hạn

7/ thuật tổng hợp -> toán tổ hợp

8/ đồ thị -> lý thuyết đồ thị

9/ ô nhiễm cái karma của bạn -> thất đức /cắn rứt lương tâm/. Xem karma, ở dưới.

Karma (Phật giáo) = (a) đức (b) triết lý nhân quả. "Tích đức" (có những đóng góp mang tính xây dựng) thì hơn là hành động "thất đức" (đả kích hay chống phá Microsoft), khỏi lo sợ bị "quả báo" smilie

.

Liên quan tới RSA với số mũ công khai = 3 (hiện nay đã ít dùng) và chữ ký RSA định dạng PKCS#1 v.1.5 (hiện nay ít dùng), Daniel Beichenbacher tai hội nghị trù bị cho hội nghị mật mã quốc tế CRYPTO 2006 đã trình diễn một cuộc tấn công đơn giản đến kinh hoàng. Lợi dụng sơ hở của phần mềm bên kiểm tra chữ ký không kiểm tra kỹ độ dài và định dạng dữ liệu nhận được, kẻ tấn công có thể nối thêm một chuỗi bit "rác" (garbage) được tính rất dễ dàng -- chỉ cần bút chì và giấy -- sao cho kết quả là một luỹ thừa 3 mod N thích hợp, cho căn bậc 3 là một chữ ký hợp lệ, nhưng giả mạo.

OpenSSL bị đụng chạm bởi cuộc tấn công này. Xem http://www.openssl.org/news/secadv_20060905.txt

Nguồn: tin vỉa hè.

Siêu trộm wrote:

Ai biết đâu nà, người ta hỏi sao thì tui trả lời dzậy thôi . Nhưng mà tui thấy 2 bạn nói vậy cũng không đúng, giả sử cách tính lương (công thức) ko cố định, vậy thì làm theo cách của ChinhVn sao được chứ.

Bạn trả lời hoàn toàn đúng trọng tâm vấn đề rồi -- bạn ấy hỏi how chứ không hỏi when; ChinhVn với alice chỉ bàn thêm thui muh. smilie

)

À, còn stack, automata hay là parse trực tiếp -- cũng thế cả mà thôi. Cách nào quen tay thì làm theo cách đó.

alice thấy ý kiến của ChinhVn có vẻ thực tiễn hơn. Tiền lương tính theo luật lệ, chỉ áp dụng một (hoặc vài) công thức cố định. Cho phép người dùng nhập công thức tuỳ ý, e rằng chỉ tạo sự phức tạp, vô ích và phiền phức.

Con Rùa thì tuyệt đỉnh rồi, nhưng giá vẫn còn hơi chát. Alice cũng đang tính tới gần Tết xin cơ quan cấp cho 1 con, hoặc nếu không có thì mình tự tặng cho mình vậy. smilie

)

Bạn thử không cắm thanh RAM nào bật điện nó có kêu ầm lên không? Nếu kêu thì chắc là main còn tốt.

Vậy thì chờ đợi là thượng sách. AMD X2 mát hơn nhiều và ngốn ít điện hơn. Chỉ thua kém Intel rõ rệt ở vài ứng dụng số nguyên đặc biệt (như mã hoá AES), còn trong những mặt khác nói chung là hoà. FaL yên tâm đi, ở chỗ FaL, AMD X2 chắc chắn cũng sẽ xuống mức giá rất bình dân chỉ trong ngày một ngày hai.

Bce 6ydem хорошо. smilie

)

AMD cũng rẻ mà FaL.

alice vừa bỏ một con P4 2.4 GHz, làm một con X2 3800+ mới. Con này tương đương D 820 (nghe nói thế smilie

).

Thomas_Black wrote:

Vậy theo pác thì thế này:
Code:
char c[100], *s;
s = c;
Là có thể dùng s như một string[100] phải không?
Thanks pác.

Bạn có thể dùng s như c. smilie

Hi,

Có bài cache timing của D. J. Bernstein có lẽ gần với vấn đề bạn quan tâm.

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Vài tháng trước alice được đọc một bài khác nói về một kĩ thuật timing chỉ nhờ nghe trộm mà chọc thủng được SSH server, nhưng chịu chết không nhớ được đó là bài nào, chỉ nhớ mang máng hình như là ở Cryptology ePrint Archive http://eprint.iacr.org. Bạn thử tìm lại xem.

Nếu thấy gì hay thì tóm tắt lại cho mọi người cùng biết với nha. smilie

)

-----------
p/s. Nếu alice nhớ không lầm, compromise khi là transitive verb khó có thể dịch là thoả hiệp. smilie

)

Bốn chế độ chuẩn CBC, CFB, OFB, CTR có thể dùng mã hóa dữ liệu truyền qua mạng. Đối với dữ liệu lưu trữ trên đĩa, tình hình phức tạp hơn. Các sector được truy nhập ngẫu nhiên nên được xem như một thông điệp mã hóa độc lập. Do đó mỗi sector đĩa, nói chính xác hơn mỗi khối dữ liệu 512 bytes ghi vào một sector đĩa đều cần có một IV (initialization vector). Số hiệu sector không thể dùng làm IV vì nó không ngẫu nhiên. Nếu tạo IV ngẫu nhiên thì phải trích một phần sector để nhớ IV, dung lượng hữu ích của sector sẽ bị giảm. Như thế, để mã hóa dữ liệu lưu trữ trên đĩa, các chế độ chuẩn nói trên đều không thích hợp.

LRW (M. Liskov, R. Rivest, D. Wagner) là một đại diện tiêu biểu của các chế độ vận hành mới, thích hợp để mã hóa dữ liệu trên đĩa. Chúng đều xây dựng trên một ý tưởng tương tự như CTR nhưng tinh vi hơn, đó là dùng số hiệu sector dẫn ra một biến gọi là tweak, dùng nó xor với dữ liệu trước và sau khi mã hóa ECB.

Chúng đều có những tính chất bảo mật đáng mong muốn, kể cả tính chất bền vững trước những cuộc tấn công mạnh như là adaptive chosen ciphertext attack (reference). Trong số chúng, LRW đã được IEEE Security in Storage Working Group lựa chọn để chuẩn hóa bởi vài tính năng ưu việt -- tiềm năng xử lý song song lớn, tốc độ nhanh và hoàn toàn miễn phí.

Năm 2002, Liskov, Rivest và Wagner đã chứng minh rằng với H là một họ hàm hash vạn năng (reference) thích hợp, nếu mật mã nền ENCRYPT an toàn thì

y[i] = ENCRYPT(z, x[i] xor h(i)) xor h(i)

cũng an toàn.

Dựa vào đó, IEEE xây dựng chế độ vận hành LRW áp dụng cho AES (LRW-AES) như sau

y[i] = ENCRYPT(z, x[i] xor t[i]) xor t[i]

t[i] = t mul i

Trong đó t là khóa thứ hai (độc lập với khóa z), i là số thứ tự cụm dữ liệu tính từ đầu đĩa, mul là phép nhân (và xor là phép cộng) trong trường hữu hạn 2**128 phần tử. Những phép toán này có thể thực hiện rất nhanh trên bộ xử lý 32 bit và 64 bit.

Trên thực tế đa số ứng dụng mã hóa đĩa hiện nay vẫn dùng chế độ cổ lỗ sĩ CBC với IV là số hiệu sector. LRW mới chỉ được cài đặt trong vài phần mềm ứng dụng mã hóa đĩa (TrueCrypt, BestCrypt). LRW sẽ được tích hợp trong các ổ đĩa cứng thế hệ mới sau khi quá trình chuẩn hóa ở IEEE hoàn tất.