Messages posted by: MrNothing

Có một lý do khởi động lại là nhiệt độ chip/hdd lên quá cao. Dùng phần mềm check nhiệt độ theo dõi xem nhiệt độ nó có lên quá 70 độ không?

Lời khuyên là:
Bỏ chơi game đi smilie

.
Nếu chơi game thì nguồn 400W e là ko đủ. Lên 550 hoặc 600 đi. Loại công suất thực ấy!

Bạn ơi bạn tìm hiểu và tự trả lời các câu hỏi của bạn đi đã. Sau đó sẽ có người trả lời xem bạn hiểu đúng hay chưa.

Vì giá nó rẻ nên bạn mới thấy nhiều người mua thôi.

Lenovo có mấy dòng Thinkpad thì ổn. Hình như dòng SL410 ngon hơn mấy dòng SL400 hay dòng thinkpadE
Mấy cái mới ra lò gần đây thì chất lượng đi xuống.

Hôm rồi định mua laptop Lenovo. Con đầu mở ra có điểm chết trên màn hình. Con 2 mở ra thì tèo pin.

Với mức 10-12 triệu có thể mua Asus bảo hành 2 năm.

Haiz. Mất niềm tin vào lenovo. Dành niềm tin cho dell và toshiba vậy. Mình thích dòng Dell xuất thị trường Mỹ. HP cũng được, mỗi tội chạy hơi nóng.

Kết nhất mấy em Dell Latitude bảo hành 3 năm. Giá tầm 21 triệu.

Theo mình nghĩ thì nó chính là mô hình PKI. Public key được verify bởi CA rồi.

Tự code đi. Anh ko cần hậu tạ.

Làm một chương trình client-server qua socket. Gửi nhận xác thực user nào đó. Đặt nó là mặc định, Strinh mặc định, tự sinh hú hoạ câu hỏi rồi xác thực.
Đơn giản nữa thì làm Window form MFC thôi smilie

Nếu không code được thì bảo thầy sang năm em làm lại cũng được.

Hay là thuê ai code hộ đi smilie

. 100$ nhá smilie

Nếu thế thì cái OTP của bạn giả sử là một ma trận m*n, mỗi số trong ma trận này có p byte
ví dụ bảng
table_otp ()
11 22 33
44 55 66
77 88 99
12 13 14

là ma trận biểu diễn cho m=4, n=3, p=2.

Trong database gồm có table_user có các trường: Username, fixed_password, OTP_String,challenge

Cái OTP_ID này là một string để biểu diễn ma trận m*n. Bạn hoàn toàn có thể biểu diễn cái OTP String là 112233445566778899121314.

Bạn xem muốn lấy vị trí (i,j) trong cái table_otp ở trên thì lấy ra trong OTP_String như thế nào?

Sau khi xác thực xong với fixed_passsword, Chương trình server sẽ tự động sinh ra một challenge ví dụ ở dạng ((1,2),(3,3)) nghĩa là lấy số hàng 1, cột 2, ghép với số hàng 3, cột 3 sẽ là OTP. Server sẽ đưa ra thông báo bạn cần nhập số ố hàng 1, cột 2, ghép với số hàng 3, cột 3. Bạn tìm được cái OTP này không? Server sẽ xác thực giá trị nhập vào và so sánh với giá trị có được từ OTP_String.
Ví dụ đây là một cái Internet Banking với OTP là một cái thẻ.
http://t2.gstatic.com/images?q=tbn:aZhCsVWidLwLNM:http://phone4vn.com/public/help/html/IBWooriHelp_files/image007.jpg

OTP kiểu này còn dễ hơn là phải code HOTP.

Mình gửi bạn một đoạn Project demo HOTP mà mình viết. Bạn check hòm thư nhé. Mình cũng quên là đoạn code đó cho Pocket PC hay Win32 rồi. Có gì bạn tra code rồi lấy các thư viện để viết lại. HOTP là một chuẩn cho OTP. Có gì bạn google thêm nhé.

1. Public Key của .Net sinh ra có dạng
Code:

<RSAKeyValue><Modulus>Modulus value</Modulus><Exponent>exponent value</Exponent></RSAKeyValue>

Convert sang java:
Code:

BigInteger modulus = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("Modulus value in .net")), 16);
BigInteger exponent = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("exponent value in .net")), 16);
RSAPublicKeySpec rsaPublicKeySpec = new RSAPublicKeySpec(modulus, exponent);
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
RSAPublicKey publicKey = (RSAPublicKey) keyFactory.generatePublic(rsaPublicKeySpec);
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
cipher.init(Cipher.ENCRYPT_MODE, publicKey);

2. Private key của .net có dạng:
Code:

<RSAKeyValue><Modulus>Modulus value </Modulus><Exponent> Exponent value</Exponent><P> P value</P><Q> Q value</Q><DP>dp value</DP><DQ>dq value</DQ><InverseQ>inverseq value</InverseQ><D>d value</D></RSAKeyValue>

Convert sang java private key:

Code:

BigInteger modules = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("modules value")), 16);
BigInteger exponent = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("exponent value")), 16);
BigInteger p = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("p value")), 16);
BigInteger q = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("q value")), 16);
BigInteger dp = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("dp value")), 16);
BigInteger dq = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("dq value")), 16);
BigInteger inverseQ = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("inverseq value")), 16);
BigInteger d = new BigInteger(ISOUtil.hexString(Base64.decodeBase64("d value")), 16);
RSAPrivateCrtKeySpec rsaPrivateKeySpec = new RSAPrivateCrtKeySpec(modulus, exponent, d, p, q, dp, dq, inverseQ);
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
RSAPrivateKey privateKey = (RSAPrivateKey) keyFactory.generatePrivate(rsaPrivateKeySpec);
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
cipher.init(Cipher.DECRYPT_MODE, privateKey);

Sorry, đã giải quyết xong smilie

Thanks bác ZOrrO đã nhắc nhở, hôm mà mình vội quả chỉ kịp post cái này, Tí nữa sẽ mình sẽ update luôn!

Mình đang gặp một vấn đề cần giải quyết gấp.

Để convert public key từ java sang .net thì có ở đây:
http://www.codeproject.com/KB/security/porting_java_public_key.aspx

Tuy nhiên chiều ngược lại convert public key từ .net sang java thì chưa tìm thấy.
Tất nhiên là có thể làm ngược lại quá trình từ java sang .net.

Bác nào có biết giải pháp cho quá trình này thì cho mình ý kiến với.

Bạn Cuncon201 nhầm HOTP thì phải.
Theo tớ biết thì HOTP dùng HMAC_SHA1 đồng bộ dựa theo Counter

Client có một cái token sinh mã OTP= HMAC_SHA1(Key, Counter_Client)
Server xác thực dựa vào OTP=HMAC_SHA1(Key, Counter_Server).

Vấn đề chỉ là đồng bộ counter của Client và Server. Giá trị counter là 32 bits.

Giả sử Counter_Client hiện tại là Counter_server+a, Với a< w=10 chẳng hạn (cửa sổ đồng bộ)

Client gửi OTP hiện thời, server sẽ kiểm tra xem cái OTP Client gửi nằm trong khoảng từ
OTP=HMAC_SHA1(Key, Counter_Server+1) đến OTP=HMAC_SHA1(Key, Counter_Server+w)
sẽ phát hiện cái HMAC_SHA1(Key, Counter_Server+a) là bằng với cái client gửi. Coi như xác thực đúng client. Cập nhật lại Counter_server= Counter_server+a.
Lúc này 2 bên client và server có cùng giá trị counter. Tại sao lại có +a. Giá sử Client lỡ nhấn a lần phím sinh pass thì sẽ bị đi quá giá trị đồng bộ. w=10 chỉ giới hạn cửa sổ cho phép đồng bộ. Lỡ tay nhấn nút nhiều lần quá thì sẽ không xác thực được nữa. Có thể đồng bộ lại counter trên server bằng cách nhập hai số OTP liên tiếp từ client, counter_server sẽ chạy liên tục đến khi có 2 giá trị liên tiếp bằng giá trị nhận được từ client!

Chắc không phải kavo đâu bạn à. Tớ nghĩ do thằng yahoo. Tớ dùng 4 con XP cài bản 8. Dạo này nó chăm chỉ nhiệt tình bảo tớ update lên bản mới lắm. Nhưng tớ không thích bản mới. 4 con máy của tớ có cả con mới cài, cũng bị lỗi vậy.
Kệ cửa sổ yahoo ban đầu. Mở cửa sổ yahoo khác thì chạy vô tư.
Bản 9 chạy vô tư không bị như vậy!
Tớ kết luận liều là nâng cấp lên bản 9 đi là ngon ngay!

1. Post một mã nguồn virus độc lên, người khác copy sử dụng, phát tán lây lan. Một ngày nào đó toàn bộ máy tính ở VN đều chết, thiệt hại vô cùng. Ai chịu trách nhiệm?
2. Mấy đứa em mình cứ suốt ngày anh ơi cài hộ em máy tính, diệt hộ em virus, giúp em word, excel,.... Làm gì có đủ thời gian lo cho tất cả chúng nó! Câu trả lời hay nhất vẫn là mô tả hiện tượng, lên mạng tìm kiếm xem người ta làm thế nào. Khoanh tay ngồi chỉ nó mấy bước cơ bản, để tự tìm hiểu vẫn là hay nhất! Cứ làm hết hộ chúng nó thì chúng nó vẫn mãi chả biết gì lúc nào chúng nó cũng lôi ra hỏi thôi! Tự mình tìm hiểu thật kĩ đi đã! Thử chưa được thì thử tiếp! Có thế kiến thức mới lên được!

Những kẻ vớ vẩn đi khỏi hva thì không tiếc!

Cơ mà các bác vào đây thảo luận cũng chả để làm gì! Ai hiểu rồi thì vẫn hiểu, ai cố tình không hiểu thì để họ tự hiểu! Không tự hiểu được thì giải thích cũng vô ích! Dạo này được mấy bác rảnh rỗi kiện tụng phá hoại kinh quá!

Câu hỏi như là giáo viên ra bài kiểm tra cho học trò ấy. Hỏi một chút mà nhiều quá!
Em chưa học bài, teacher trình bày luôn cho em với ạ! Cảm ơn Teacher boy8x_kma!
Ở đây các bro toàn chơi kiểu bạn trình bày trước rồi người ta góp ý thôi! Không chơi kiểu ra bài kiểm tra thế này smilie

Anh Google anh trả lời thế này http://www.google.com.vn/search?hl=vi&q=security+access+token&btnG=T%C3%ACm+v%E1%BB%9Bi+Google&meta=&aq=f&oq=

Giao thức của bạn StarGhost vẫn chưa đủ rồi. Nếu salt chỉ loanh quanh luẩn quẩn ở các hàm cơ bản thì khó. Phải đưa lên dạng hàm một chiều one way function cơ, như x và g^x.
Cái 4 còn vi phạm lỗi lớn là gửi đi password.

Coi lại cái SRP nhé mrro:

1. Nó tấn công server rồi đổi file đó với file chứa password của nó. Giả mạo client là hoàn toàn được.
2. Client lưu trữ password để tính ra x, server lưu g^x. Đây chính là cơ chế của Elgamal Public Key. Cái này hay ở chỗ là với Elgamal public Key thì x phải lớn, còn ở đây mọi thứ được tính qua hàm hash function x= hash(username,s,o) nên password p có thể nhỏ. và còn điều này nữa:
tớ nghe lén nhé: tớ có A, có B, có salt s, có I=username, nhưng tớ muốn verify password bằng vét cạn thì không có a. Bài toán phải giải là Diffie Hellman Problem (Discrete logarithm). Vì vậy không vét cạn được password khi password yếu.

Tuy nhiên vẫn có vấn đề với password yếu:
Attacker tấn công server và có salt và v=g^x, trong khi x=hash(username,salt,p). Nếu password yếu, tớ hoàn toàn vét cạn được và dùng v, verifier để verify p mà tớ dự đoán. Vì ở đây tớ không giải bài toán ngược của bài toán một chiều. Tớ giải đúng theo chiều xuôi. Hoàn toàn offline.

Password vẫn phải đủ mạnh thôi+ bảo mật cả phía client và server!
Tuy nhiên cơ chế trên khá hay để bảo vệ password mạnh. Khi server bị tấn công thì vẫn không bị dò ra password.

Nhưng với password mạnh pw có n bít. Attacker không vét cạn được thì tớ chơi ngay Elgamal.
Elgamal:User giữ pw, Server giữ g^pw. Muốn tìm pw cũng phải vét cạn.
SRP: Ở trên từ pw===>x===>v=g^x. Quá trình vét cạn vẫn như trên.
2 bài toán khó như nhau nhỉ? Tất nhiên thời gian tính g^x từ x là lâu hơn tính g^pw từ pw. nhưng nó cũng không đáng kể! Coi như bài toán SRP khó hơn tí nhưng về độ phức tạp cơ bản là như nhau!

Đây chỉ là một dạng trá hình của Elgamal mà thôi!

(Tạm thời phải vét cạn vì chưa có giải thuật cho Diffie Hellman Problem- hi vọng sẽ không có, nếu có thì thiên hạ lại phải nghĩ ra các giải thuật mới với độ phức tạp khó hơn)

Cái 5,6 thì không có vấn đề hiện nay nhé.
Cái 7: Thông tin lưu trên server để verify. Nếu có thể public được thì nó chính là dạng public key rồi. Server chứa một cái gì đó public dùng để verify một cái gì đó private từ client. Như là mô hình Digital Signature của Public Key.

Mấy kiểu salt thì vẫn bị lỗi 7 thôi.

Còn nếu dùng public key cho phía client. Server tất nhiên chỉ lưu client public key hoặc public key của thằng kí lên certificate của client. Sẽ chuyển sang dạng tấn công client/server lấy private key và password cho private key.

RFC 2945 wrote:

The server stores user credentials as 5-tuples of the form:
{<username>, <password verifier>, <salt>, g, N}
<salt> = random()
x = SHA(<salt> | SHA( <username> | ":" | <raw password> ) )
<password verifier> = v = g^x % N
N = prime modulus; g = generator

#Trong giao thức chuẩn thì họ dùng thừa số 1 thay cho thừa số 3 ở trên.

Tấn công server lấy file chứa bộ {<username>, <password verifier>, <salt>, g, N} rồi giả mạo client thì sao nhỉ? hoặc đổi file này nữa?

@mrro: tớ sửa rồi nhé smilie

. Thanks!
Thực ra cái trò PU, PR trên để giải quyết tình trạng weak password (lời này của bác Steven M.Bellovin). Nhưng tớ thấy nó cũng vui nên mới nêu ra.

Chứ để dùng cho các cái quan trọng thì nên dùng strong password. Để mọi người khỏi băn khoăn là mình dùng password 6 kí tự mà vẫn bị crack là sao. Để 10 ký tự attack cả tháng thì 6 kí tự vét cạn nhanh hơn. Tớ thấy giờ đa phần họ yêu cầu password là 8 kí tự đổ lên gồm cả kí tự hoa và số!

Tại mình quy ước viết E(PU, sk||nonce) là mã hóa dưới dạng Public Key PU nên dễ hiểu nhầm, sorry!

mrro wrote:

1. Đâu có bạn, strong password protocol thì phải giải quyết được vấn đề verifier không phải lưu trữ plaintext-equivalent password. Vẫn có protocol làm được đó, bất chấp nhìn vào database của verifier cũng không thể tìm được password. Thậm chí mục tiêu họ đặt ra còn là thứ mà verifier lưu trữ là thông tin public luôn. Mình không nhớ là có protocol nào làm được hay không.

1. Theo tớ hiểu ý bạn bạn nói đến cái dùng để xác thực có thể được public, thì phải khó tạo ra cái cần được xác thực. Tớ thấy nó cơ chế có vẻ giống với public key! Như kiểu server lưu PU, client có PR ấy nhỉ?

mrro wrote:

Vẫn có protocol làm được đó, bất chấp nhìn vào database của verifier cũng không thể tìm được password

Có ví dụ cho cái này không mrro?Cơ chế cho nó là gì nhỉ?
3. Bob tạo ra PU_Bob nữa smilie

.

Code:

1. Alice tạo (PR_Alice,cPU_Alice), và gửi Bob:M1= Symmetric_encryption(pw,PU_Alice)
2. Bob tạo (PR_Bob, PU_Bob), và gửi Alice: M2= Asymmetric_encryption(PU_Alice, PU_Bob)
3. Alice gửi Bob: M3=Asymmetric_encryption(PU_Bob, sk||nonce)
4. Bob gửi Alice: M4=Symmetric_encryption(sk,nonce)

@mrro: đã sửa

2. Session key của các cái trước đó được mã hóa bằng PU mà. Không có PR thì sao giải mã ra session key.

@mrro: Đúng bác Steven M.Bellovin đấy. Đỉnh ghê smilie

Dù có strong protocol cỡ nào cũng bị attack thì đúng (nghe lén, Key logger, offline guessing password, replay, man in the middle,...). Khi attacker có hết cả các thứ mình có thì tèo là chắc rồi. Hoặc chơi như choc_ là sửa code của client/server application hoặc cái thư viện đi kèm thì chắc chắn cũng tèo.

Nhưng một giao thức bảo mật tốt thì bản thân nó phải đủ mạnh đã, ít nhất cũng phải chống được các tấn công cơ bản.

(Như bài mrro làm với codegate Diffie Hellman: mình cũng đồng ý là nếu có một giao thức đang có vulnerabilities thì việc sửa nó cho nó hoàn thiện hơn thì rất khó, chưa chắc đã hoàn thiện hơn mà độ phức tạp tính toán lại cao lên nữa, có khi còn mắc thêm những lỗi khác)

Dù sao với password không cũng chỉ là giao thức 1 yếu tố. Giờ thì người ta chơi 2 yếu tố, hoặc hơn, xác thực qua nhiều tầng, và có thể có thêm các cơ chế kiểu one time password hoặc các kiểu xác thực qua nhiều con đường khác. Nhất là với các giao thức e-commerce như internet banking.

về ý kiến của mrro:
1. Lấy pass qua con đường khác thì thôi khỏi nói smilie

, chết chắc rồi
2. Nếu mất pass thì chỉ lộ PU, chứ không lộ PR.
3. Đồng ý. Biết session key sk và nonce thì chỉ việc vét cạn pw tìm xem PU nào tương ứng có E(PU_dự_đoán,sk||nonce)= E(PU_thật,sk||nonce), tuy nhiên kiểu gì chả có cơ chế vượt qua cái này, sửa protocol 5 một tí là xong.

@mfeng: Không có cơ chế để verify PU đâu bạn ạ. Ra PU_dự_đoán nhưng cũng chả biết sk với nonce là bao nhiêu mà verify.
Alice có thể gửi tin nhắn kèm theo ID: ví dụ M1= Alice, E(pw, PU).

Giao thức này còn dễ dàng bị DoS nữa. Vì message dành cho integrity và authentication nằm ở bước cuối cùng.

Bob cứ nhận được tin nhắn là giải mã và send lại cho Alice. Alice thì cứ giải mã xong trả lại cho Bob. Khi đó Bob mới giải mã kiểm tra nonce xem có đúng không!

Không phải tớ nghĩ ra đâu bạn StarGhost ạ!

Protocol này ra đời đã 17 năm rồi smilie

.
Tớ không muốn nêu tên protocol ra vì như vậy sẽ không hay. Cứ để ra ý tưởng thế rồi phân tích vui hơn!

Ở Step 1 bạn StarGhost băn khoăn là làm sao Bob hiểu thông tin gì chứa trong PU. Alice và Bob dùng chung một cơ chế giải thuật đã thông báo từ trước chẳng hạn. Nếu thiết kế PU không tốt thì sẽ lộ pass. Ví dụ không nên gửi E(pw, X,PU) với X là một thông tin mà attacker có thể biết như timestamp, ID của Alice hoặc Bob vì khi đó Attacker có thể vét cạn pw để tìm ra pw.

Mặc định là PU chỉ chứa đúng cái public key. ở đây gọi là public key nghĩa là nó tuân theo cơ chế public key chứ không phải là ai cũng biết để verify password giữa 2 người. Public Key PU chỉ 2 thằng Alice và Bob biết với nhau lúc trao đổi thôi.

Còn câu p/s:
1. ý tưởng hay đó là dùng Public Key để che dấu password. Giải thuật của mfeng với các giải thuật khác như salt là lộ pass.
2. Một suy luận tự nhiên đó là độ bảo mật cao hơn thì chỉ có 2 trường hợp, một là đề xuất ra giải thuật tốt hơn (phát minh mới), hai là độ phức tạp tính toán tăng lên smilie

. Ở đây bạn StarGhost nghĩ nó rơi vào trường hợp nào smilie

Còn nếu như nghe lén đường truyền mà không dò ra pass thì vác cái camera, hay keylogger theo dõi xem user nó gõ gì là xong, đỡ phải nghe lén đường truyền.

@Starghost: Mình nhớ nhầm từ "totient" mới đúng smilie

. Lỗi quá

. Toàn nhớ nhầm từ potiential! Thanks!
http://en.wikipedia.org/wiki/Totient
N=p*q, p,q nguyên tố khác nhau thì hàm đó là totient_function(N)=(p-1)*(q-1), số các số nhỏ hơn N và nguyên tố cùng nhau với N. Chính vì thế RSA mới hoạt động.

@rockyspk
Known_hosts là các server ta đã biết, authorized_keys mới là các client ta đã tin. Bồ vẽ ra một tờ giấy 2 cột. 1 cột là client, /ssh/, /.ssh/ của client một cột server với /ssh/ và /.ssh/ của server. Known_hosts nằm ở đâu. authorized_keys nằm ở đâu. Khi connect thì public key của server đi vô đâu? public key của client không đi vào known_hosts của server đâu.
identity của client đi vào authorized_keys của server với con đường copy và cat chứ không qua kết nối login ssh đâu.
Khi client bị hỏi bằng password khi nó không được xác thực bằng identity của nó trong authorized_keys. Password ở đây là pass login của user trên server.

Khi bạn đang là một user khác muốn dùng identity của user kia ở phía client có thể sẽ bị hỏi passphrase của cái private key đó! Hoặc chỉ đúng client đó mới dùng được cặp Public Key/ Private Key của nó.
Identity của client cũng là một cặp Public Key/ Private Key. Public Key đóng vai trò như là chứng minh thư. cái này mới được add vào authorized_keys của server này.
Mọi thông tin gửi lại cho client được mã hóa qua public key của client nên chỉ client có quyền với private key giải mã được!

Bạn thử copy cặp id_dsa và id_dsa.pub của client sang cùng thư mục của một máy client khác. Ngoài ra add nó vào authorized_keys xem thế nào smilie

. (Khi generate id_dsa bằng lệnh của ssh thì nhớ đặt 2 pass phrase cho 2 thằng client là khác nhau )

Khi client connect tới server mà server lại có public key khác (nó so với entry của server đang kết nối đến có sẵn trong known_hosts của client để biết khác hay không) thì chương trình ssh client sẽ cảnh báo là "public key thằng server đã bị thay đổi. Cẩn thận bị lừa. Có tin được không?" Tin thì chọn yes. Không tin thì thôi! (Kiểu là sao mặt thằng server này sao lại khác cái mặt mình đã nhớ nhỉ?)

Đồng ý với bác myquartz!

SSH xác thực certificate server qua RSA, DSA finger print chứ không theo kiểu CA trong SSL.
Em chỉ đem SSL ra demo là với hệ public key nó làm kiểu gì. Đặc biệt SSL mô tả được rõ nhất quá trình xác thực+ sinh session key.
SSL cũng không nhất thiết phải xác thực với client certificate. Với server certificate có thể tạo ra secure tunnel. Còn sau đó dùng cái secure tunnel này để xác thực client bằng password chẳng hạn.

Trong EAP methods có cái gọi là TTLS và PEAP là 2 cái dùng server certificate tạo secure tunnel sau đó dùng các phương pháp khác để xác thực client.

Thường khi remote cứ nhìn thấy nó hỏi yes cái certificate hay và add vào ko thèm check rsa finger print luôn chả sợ man in the middle gì cả smilie

. Cách tốt nhất là ghi lại finger print hoặc copy cái public key đó add luôn vào known_hosts của client.

Cho 3 ngày cơ mà smilie

Thiếu Key Generation và đi kèm với nó là khái niệm Euler's totient function.
Encryption và Decryption chưa trình bày tử tế. Lại còn thiếu Digital Signature nữa chứ!

Client nhận server public key sau khi click yes nó được lưu vào known_hosts của client.

Server: Đây là public key của tao, mày chấp nhận không, chấp nhận thì ghi vào know_hosts của mày đi. Nhớ mặt tao nhé. Lần sau mày sẽ không bị hỏi có chấp nhận không.
Client: Ok, tao tin mày, coi như tao đã biết mặt mày, lần tới gặp lại thể nào tao cũng nhận ra.

Lần tới server gửi PU của nó, client check trong known_hosts của nó, so sánh thấy trùng nhau thì ok.

Client muốn connect tới server mà không bị hỏi pass thì public key của client phải nằm ở server:/.ssh/authorized_keys
Copy client identity id_dsa.pub hoặc id_rsa.pub lên server rồi "cat" nó vào authorized_keys của server.

ý nghĩa là:
Client: Ê cu thẻ ra vào của tao đây!
Server: À thẻ thằng này có trong authorized_keys, ok vào đi ku!

trong thư mục server:/ssh/ là public key và private key của server
Ví dụ có id_dsa và id_dsa.pub, id_rsa và id_rsa.pub là identity của server
ơ thế còn ssh_host_dsa_key.pub và ssh_host_dsa_key, lại còn cả ssh_host_key và ssh_host_key.pub
ssh_host_rsa_key.pub và ssh_host_rsa_key
? mấy cái này là cái gì? dsa và rsa ý nghĩa là dùng giải thuật nào đấy. Như kiểu tiếng Lào tiếng Thái đấy.

Mấy file đó có ý nghĩa gì? xem ssh_config và sshd_config.

cẩn thận id_dsa.pub của client được copy lên .ssh của server mà lại quên chưa xóa thì nó là của client đấy.
Các Identity của server nằm ở thư mục hiện /ssh/ chứ ko phải thư mục ẩn /.ssh/. Xem thêm các file config

Dùng client connect đến server sau đó xem trong know_hosts của client có chứa cái entry nào trùng với cái file .pub nào trong thư mục ssh trên server.

Nếu chỉ dùng E (PU, M) thì trong M phải có thông tin thằng gửi smilie

. Thằng nào gửi? Có toàn vẹn(integrity) không? Ở đây cần digital signature của client nếu nó dùng public key.

Còn không xác thực bằng pass thì nó sinh session key na ná SSL protocol.

Với môi trường mà chỉ cần server broadcast messages tới clients ko cần bí mật chỉ cần E(PR của server, M+hash(M)) là đủ (chống replay attack có thể thêm time stamp vào). Nơi nhận dùng PU của server để giải mã.

Mô tả RSA thế kia là chưa đủ. Chả khác gì PKI không mà còn chưa đủ. Còn Elgamal nữa. Lại còn EC và Pailler cũng là Public Key, chưa kể thiên hạ còn bịa ra một số loại khác nữa!

Hiểu PKI, RSA, Egamal đi, có lợi cho cậu chứ ko cho tớ đâu!

# đã chỉnh thành Euler's totient function theo comment của bác Starghost

Bài tiếp theo trình bày RSA. Khi chưa hiểu hệ Public Key thì chưa hiểu được SSL. Hiểu 1 hệ Public Key đi đã.

Em đừng hỏi với giả sử là em nói đúng hay em nói sai. Sai tự khắc người khác chỉnh cho hoặc để em tự ngẫm. Em có phải lãnh tụ đâu mà người ta cứ chăm chăm chỉ chỗ đúng sai của em. Khi nào em hiểu RSA và SSL khắc sẽ biết đúng hay sai. Chứ tớ hay giải thích khó hiểu lắm.

Tại sao nếu client gửi E(PU_server,M, E(PR_client, hash(M))) thì tin này vừa có xác thực người gửi, vừa đảm bảo tính toàn vẹn?

Biết Public key tự khắc biết 2 bên cần gì để trao đổi với nhau!
Anh nhớ cái hình của anh về SSL, nó phân biệt khóa nào của client khóa nào của server bằng hướng với màu của khóa rồi!

Server hay Client có thể tạo ra mấy cặp khóa cơ. nó chọn khóa nào là trong bước client_hello (thông báo là client có thể dùng được các phương thức mã hóa nào- Không phải là tất cả các client server đều có cùng version như nhau) sau đó server trả về cipher suite (các giải thuật mà server nó chọn- và cả client và server đều có khả năng thực hiện). Dựa trên cipher suite thì mới biêt nó dùng _dsa hay _sha hay dùng loại bao nhiêu bít,...). Chứ Client dùng giải thuật X, server dùng giải thuật Y thì khác gì mình tán gái nói tiếng Việt em ấy trả lời bằng tiếng Thái lan đâu!

Client_hello: Ê cu server, tao nói được tiếng Hàn, Nhật, Thái, Lào, Việt Nam
Server_hello: Ok, vậy tao với mày nói chuyện bằng tiếng Lào nhé, đây là certificate (có chứa public key) của tao bằng tiếng Lào.

...
Nhớ là cái certificate chứa public key. Và nó được xác thực bởi 1 thằng bên trên smilie

. Tại sao cần vậy?

...

Ở đây cũng vậy: Tớ và cậu phải có cùng ngôn ngữ là public key thì mới nói chuyện được với nhau chứ không có tớ nói đằng cậu hiểu nẻo thì sao.
...
Nhớ trình bày hệ Public Key, RSA trước khi trả lời các thứ khác! Câu hỏi của em là OpenSSH với Public Key mà. Trước hết phải hiểu Public Key là cái gì đã.

Thêm 3 ngày nữa trình bày PKI và RSA nhé smilie

. Post vào một cái hình và trình bày smilie

.

1. Key generation
2. Encryption
3. Decryption
4. Digital Signature

In cái này ra rồi đọc cho ngấm smilie

http://en.wikipedia.org/wiki/RSA
khi nào cậu chưa trình bày xong PKI và RSA thì tớ chưa trả lời tiếp! Yên tâm trình bày xong hiểu và nhớ lâu lắm. Khéo lại em hiểu rồi, các anh khỏi cần trả lời.

Bài tiếp theo bạn trình bày giao thức RSA. Elgmamal rồi SSL nhé.
Viết từng bước một! Tại sao private key có pass phrase?

rockyspk wrote:

Public key của server gởi về chính là public key của client đã đưa lên server (nó nằm trong thư mục /home/tenuserclientdo/.ssh ở SERVER)
Server gởi public key về như là một sự thách thức kiểm tra chứng thực với client (public key server gởi về + private key nhằm mã hóa random number)

Còn ai nói public key đó là server thì em chịu, vì mới vào tìm hiểu, mong anh thông cảm!

Ai bảo public key server gửi về chính là public key của client đã đưa lên server?

Đọc lại SSL lần nữa. Nghĩ cho kĩ rồi mai trả lời! Mới tìm hiểu thì nghĩ cho kĩ hơn. Phân tích từng bước của SSL protocol. Đọc lại cả Public Key Infrastructure với RSA và Elgamal nữa!

chưa chuẩn nên cần chỉnh! (Đừng có ép các bro chỉnh như thế. Chỉnh từng chữ mệt lắm).
Cứ đọc tự ngấm đi! Không ngấm đọc lại.

Giải hóa là gì??? Dùng từ phổ thông tí không dùng từ địa phương.
server dùng private key giải mã thôi.

Server dùng private key của nó + public Key của client
Client dùng private key của nó+ public key của client.

Câu hỏi:
Thế nào là public key infrastructure? nó gồm có các algorithm nào?
Vì sao nó khó bị phá?
Có các hệ public key infrastructure nào phổ biến?
Public Key của server dùng để làm gì? Ai xác thực cho nó? nó bảo nó là Server? Ai tin được?

tại sao nhiều clients có thể cùng kết nối đến SSH server?

Bạn đọc thử giao thức SSL xem sao.
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://en.wikipedia.org/wiki/File:Ssl_handshake_with_two_way_authentication_with_certificates.svg

Client và server phải gửi cho đối tác public key của mình. Sau đó đối tác phải verify cái Key đó bằng xác thực lên trên tiếp (Đúng theo cơ chế xác thực của public Key cho tới root CA)

có 2 trường hợp
1. Xác thực client bằng password:
Server gửi về public key. Đồng ý thì chấp nhận (Quá trình này nếu mình tin tưởng thì thường chả bao giờ xem cái key đó đúng hay sai? Ai chứng thực? Cứ nhìn hash MD5 của nó rồi chấp nhận- mà chẳng thèm check xem cái hash MD5 đó có đúng không<-- cẩn thận bị attack chỗ này). Sau lần này mình chấp nhận thì lần tới nó sẽ không hỏi nữa nếu đã lưu vào bộ nhớ known_hosts
Sau khi chấp nhận rồi thì mọi thứ được gửi với public key và các giải thuật mã hóa nó support+ trao đổi khóa phiên (ngó qua SSL)
2. Xác thực bằng client public key. Thêm vào authorized_keys của phía server.
Khi client connect tới server, nó gửi public key của nó. PIN CODE hay pass phase này nhập lúc nào??? Client có Public Key và Private Key. Chương trình muốn chạy được thì nó phải load Private Key của client vào trong chương trình. Private Key mới có PIN CODE.
Tại sao cần Private Key. Server gửi thông tin mã hóa qua Public Key của client. Vì thế phải dùng Client Private Key để giải mã.

Cách nhập Pin Code của client private key:
- Chương trình đã quản lí sẵn cái private key rồi, khi load nó tự động
- chương trình hỏi PIN CODE cho private key.

Server khi chạy nó biết public key của nó ở đâu hoặc nó load sẵn vào chương trình, cứ khi nào có client nào connect đến là nó send public key của nó!

Thì bét ra muốn người trả lời tử tế, nhất là các bác bận rộn, thì câu hỏi nên rõ ràng và chi tiết một chút. Trừ mỗi bác Google hỏi gì cũng trả lời!
Không lẽ hỏi tôi muốn chế tạo một cái máy cắt cỏ thì các bác ấy phải giảng giải cho bạn từ cái ốc vít đến cái bánh xe à (Cầm tay dắt đi từ A đến Z, rồi sẽ lại hỏi vì sao lại thế và vì sao lại thế). Quá trình tự đọc sẽ học được nhiều hơn.

Ít nhất cũng phải cụ thể

DDoS dạng gì? chả lẽ mọi dạng?
Để làm gì? Mục đích đạt được cụ thể là gì! Chứ bảo DDoS thằng hàng xóm chơi thì ai trả lời?

Người ta trả lời không phải vì cái "Đa tạ nhiều!"
====

Thử mấy cái này:

Tool nào thu thập dữ liệu? tool nào replay?
Google: DDos Attack case study or DDos tools.

# tớ chưa thử bao giờ smilie