banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: gamar  XML
Profile for gamar Messages posted by gamar [ number of posts not being displayed on this page: 0 ]
 
đọc về chữ ký tay là sao, hài quá ...

thông thường digital signature có 2 tác dụng:
- bảo đảm tính vẹn toàn của dữ liệu (data integrity)
- bảo đảm tính xác thực của người gửi (authentication)

Chẳng hạn Alice lúc đầu sẽ hash dữ liệu rồi dùng pri key của mình để encrypt dữ liệu. Sau đó gắn phần mã hoá này vào dữ liệu original rồi gửi cho Bob. Bob khi nhận được, đầu tiên sẽ dùng pub key của Alice để decrypt cái phần mã hoá, nếu giả mã được thì chứng tỏ được tính xác thực của Alice. Sau đó hash cái original dữ liệu gửi kèm theo và so sánh nó với cái hash sau khi giải mã, nếu giống nhau thì sẽ chứng minh đc tính vẹn toàn của dữ liệu luôn.

conmale wrote:
Em bị bối rối giữa ACK number và SEQ(UENCE) number rồi. Một TCP segment là một chuỗi thông tin chưa hoàn tất nên nó phải giữ ACK number nguyên thuỷ để đến chặng cuối, khi chúng được nhập lại và đưa lên tầng giao thức ở trên (từ TCP lên HTTP chẳng hạn) chúng mới thực sự được hoàn tất và được đầu nhận có thể nhận đủ. 


nhưng thật ra ko cần số ACK bên client vẫn có thể demultiplex data đc dúng ko anh ... dựa vào seq nummer với data length là đủ rồi ...

namnx wrote:

Mình lại không nghĩ như vậy. Trên thực tế thì những tác vụ như vậy cũng chẳng đáng kể gì. Để chính xác hơn, khi nói đến viêc thực hiện các tác vụ tính toán, chúng ta nên dựa trên "độ phức tạp thuật toán". Các tác vụ trên đều có độ phức tạp tuyến tính O(n).
 


Mình chả rành cái này lắm, chả biết có phải O(n) thật không nhưg bạn cho hỏi n ở đây bằng bao nhiêu hả bạn smilie ?

mrro wrote:

bạn có học qua lý thuyết số thì sẽ thấy việc chứng minh này rất dễ dàng. giải thích cái này dài dòng, nằm ngoài nội dung của chủ đề này, nên mình không viết ra ở đây.
 

uhm mình cũng nghĩ cái này chứng minh toán học và bắt buộc phải thỏa mãn điều này thì mới đảm bảo tính chất an toàn của hệ thống mã khóa công khai. Có điều chứng minh dễ hay không, và nó có tùy thuộc vào từng loại thuật toán không thì mình không biết smilie ...

mrro wrote:

gamar wrote:

Ngược lại nếu muốn dùng 1 cert và chỉ cần 1 CSR thì sẽ set cặp public/private key duy nhất cho tất cả các server (liệu chỗ này mình chỉ cần set public key thôi là đủ không nhỉ, vì thuật toàn mã hóa public key sẽ tự tìm ra private key tương ứng)...
 

he he he nếu mà cái chỗ màu đỏ đúng thì còn gì hệ mã khóa công khai nữa bạn. ngược lại thì đúng, nghĩa là có private key thì sẽ tính được public key, nhưng mà nhìn vào public key không thể nào tính được private key.
 

smilie chỗ này mình kết luận linh tinh quá, nếu mà từ public mà suy ra được private thì đúng là chả cần khóa làm gì cả hehe

mrro wrote:

liệu biết (n, d) có thể tính được e hay không? Đương nhiên lúc này e phải thỏa mãn những tính chất khi người ta chọn e trong thực tế, ví dụ như e phải rất nhỏ.
 

từ (n,d) suy ra e thì chắc chỉ có bruteforce và trong trường hợp này bruteforce chắc cũng thua smilie. Tuy nhiên có private rồi thì kiểu gì cũng có public, cần gì phải tìm ra làm gì nữa smilie

thangdiablo wrote:

Vì lúc này khi client truy cập (đăng nhập user name + password) nguyên đống thông tin này sẽ được mã hóa bằng session key và session key lại được mã hóa bằng public key (cert) của Server. Và cert này sẽ được CA kiểm định xem có an toàn hay không. Nếu nó đi tới Server A thì server A có private key để mà giải mã.
 


nếu mình không nhầm thì ở đây thangdiablo hỏi về chiều ngược lại so với giải thích của mrro.
Còn đoạn mà mrro nói sẽ giải thích chỗ "... Và cert này sẽ được CA kiểm định xem có an toàn hay không " (mặc dù không hẳn là được CA kiểm định vì CA chỉ "ra tay" khi user muốn biết info revoked của 1 cert xác định)

thangdiablo wrote:

Các server khác không có private key thì sẽ ứng xử thế nào smilie hehe
 

Còn chuyện private key của server thì mình nghĩ server nào cũng có public/private key của nó cả. Thế nếu mà mỗi server có cặp key riêng thì không thể nào dùng 1 cert được (mình có câu hỏi, làm sao các bạn chứng minh được là không tồn tại 2 cặp key: public1/private1 và public2/private2 sao cho public1=public2 và private1!=private2 ?)

Ngược lại nếu muốn dùng 1 cert và chỉ cần 1 CSR thì sẽ set cặp public/private key duy nhất cho tất cả các server (liệu chỗ này mình chỉ cần set public key thôi là đủ không nhỉ, vì thuật toàn mã hóa public key sẽ tự tìm ra private key tương ứng)...
thanks ban WinDak về câu trả lời

WinDak wrote:

Cái này nó còn phụ thuộc vào 1 entry của page table tốn bao nhiêu diện tích nữa.
 

ok, nếu thế thì số lượng page chính là số lượng entry trong page table

WinDak wrote:


Ngoài ra thì có phải page table đc lưu ở trong main memory và nằm ở trong phần kernel ?
 

Page table cũng có thể được "page" lần nữa, và chỉ chứa 1 phần trong physical memory thôi
 

bạn cho hỏi nếu chỉ chứa 1 phần trong physical memory thì phần còn lại sẽ nằm ở đâu ? Sẽ nằm ở trong disk -> được tạo ra khi OS khởi động và xóa đi khi OS kết thúc ?

mình kô rành lắm chỉ có vài suy nghĩ thôi, nếu có sai sót các bạn cho ý kiến ...

*nix nói chung cũng là 1 HDH giống như windows, mac os dùng cho máy tính hay thậm chí là symbian,... dùng cho mobilfone. Kiểu gì thì kiểu thì 1 HDH cũng thường rơi vào 3 lớp chính là monolithic kernel, hybrid kernel hay microkernel.

Do cấu trúc của 3 lớp khác nhau nên dẫn đến ưu điểm của linux là có tốc độ xử lý nhanh do trong linux 1 process khi cần thiết có thể dùng 1 system call để access kernel mode ~> 2 mode switches trong khi với microkernel 1 process khi chạy cần communication với server nên sẽ có 1 context switch. Ngoài ra các monolithic kernel cũng dễ phát triển và đơn giản hơn so với các microkernel

1 ưu điểm nữa của các HDH *nix hay unix-like là do việc phân chia quyền (multiuser) được kiểm soát chặt chẽ nên cũng an toàn hơn nhiều so với Windows, 1 OS khi ban đầu phát triển chủ yếu nhằm đáp ứng single-user và không đi sâu để hỗ trợ network hay security
Các bác cho em hỏi 1 câu cơ bản trong operating system:

Bình thường các OS sử dụng virtual memory để dịch 1 virtual address sang 1 physical address. Việc map này được hỗ trợ bởi 1 page table.

Như thế có nghĩa là virtual memory sẽ được chia ra thành nhiều page và số lượng page chính là độ lớn của page table ?
Chẳng hạn 1 máy 32-bit có page table 32kByte --> page size = 2^32/(32*1024)

Em suy luận như trên có đúng ko các bác ?

Ngoài ra thì có phải page table đc lưu ở trong main memory và nằm ở trong phần kernel ?

Thanks.
up up
có bác nào có ý kiến không
thanks smilie

bằng chức về địa chỉ AS có chứa youtube:
http://www.circleid.com/posts/82258_pakistan_hijacks_youtube_closer_look


Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item), started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.
 


hay ở đây




--> cái 208.65.152.0/22 có chứa Name Server để dịch ra địa chỉ đích của youtube (74.125.x.x) ???
--> làm cách nào mà chỉ cần gửi 1 update BGP cho 208.65.153.0/24, tất cả truy cập vào youtube bị chuyển hướng về cái AS ở Pakistan ?

Vì mình nghĩ nếu muốn chuyển hướng các truy cập như thế, thì phải thay đổi trong DNS Server để ngay từ bước dịch DNS sang IP, IP của youtube sẽ bị làm lệch đi hướng khác ... ???



Mọi người cho mình hỏi ...

cách đây hơn 1 năm có 1 vụ khi Pakistan Telekom gửi 1 Update Paket của BGP với nội dung dùng để thay đổi Path đi tới Subnet 208.65.153.0/24 (đây là 1 subnet nhỏ nằm trong subnet 208.65.152.0/22 của youtube). Từ đó tất cả những request đáng lẽ được gửi đến youtube bị thay đổi chạy đến cái Provider ở Pakistan này. ---> youtube đơ

sau đấy mình có thử kiểm tra lại trong datbase của WHOIS thì thấy IP của youtube là 74.125.x.x. Cái lạ ở đây là tại sao Subnet cua youtube là 208.65.152.0/22 trong khi IP Adress thì lại là 74.125.x.x ?

có bạn nào giải thích giúp mình dc kô ?

thanks
thanks anh conmale,

như thế có nghĩa là domain tương ứng ip thế nào chỉ đơn giản phụ thuộc vào các records A của IP Addr đấy trong các DNS Server.

trong ví dụ như của hva thì có thể suy ra dc là hva xài proxy có ip 72.232.199.28 smilie ?

p/s: em tìm dc câu trả lời rồi smilie
các bác cho em hỏi ...

như thế nào mà 1 domain name lại có thể được map tới bởi nhiều IP address khác nhau ?

theo những gì em biết thì, 1 domain name thường đại diện cho 1 webserver. Và 1 webserver thì thường được đánh 1 IP Address bởi Network Admin. Từ đó suy ra 1 domain name tương ứng 1 IP Address.

Vậy nếu 1 domain name tương ứng nhiều IP Address thì có thể có 1 khả năng là:
Webserver đó có nhiều interface và mỗi interface đc đánh 1 IP Address (mục đích có thể để tăng Throughput ... ?)
--> 1 domain name có thể ứng với nhiêu IP address.

Các bác thấy giải thích như vậy có chính xác không ?

neverwon wrote:

2.2. Địa chỉ trong mạng LAN. Địa chỉ này có tính "không phublic", tức là không thể nhìn thấy từ mạng public. Tuy nhiên, khác với địa chỉ private, một địa chỉ trong mạng LAN có thể được thiết lập một cách tùy hứng, miễn là nó thuộc thuộc lớp A, B và C (tức là giá trị thập phân của octet đầu tiên khác 127 và không lớn hơn 223 - và dĩ nhiên là vẫn phải tuân theo chuẩn IPv4). Có thể xem như IANA không quan tâm đến địa chỉ gán cho thiết bị trong mạng LAN!!!
 


bạn có thể nói cho mình là bạn có kêt luận này từ đâu ra không ?
Việc IP trong LAN được config tùy ý thì mình rõ nhưng tại sao phải thuộc lớp A,B,C và tại sao octet lại phải khác 127 (IP của lớp A,B,c chạy từ 0.0.0.0 đến 223.255.255.255)
có bạn nào có ý kiến về vấn đề phân chia bandwith trong 1 LAN ko ?
sao mính không thấy ai trả lời cả smilie
có bác nào có ý kiến về đè tài này ko ?

mình xin sửa bài viết trước 1 chút là việc phân bổ băng thông hoàn toàn ko liên quan gì đế router vì băng thông mà mỗi máy nhận đc là theo giao thức TCP trên máy đó (do field window trong header và congestionc control của TCP thực hiện)

vì thế nếu 3 máy cùng tốc độ download thì ko sao
nhưng nếu có máy đột xuât có thể down dc nhiều thì tự động số lượng paket đến máy này sẽ chiếm đa số trong buffer của router -- paket đến các máy khác có khả năng bị dropped, suy ra tốc độ down các máy khác sẽ bị chậm đi đáng kể.

Qua đây có thế (theo phỏng đoán của mình) ko có cách nào điều chỉnh hay giới hạn bandwith ở router mà mình phải trực tiếp có 1 phẩn mềm hay chương trình trên những máy cần đc giới hạn (liệu có phức tạp ko nhỉ vi nếu đc thì ctrinh này phải chặn các ACK từ máy truyền đi để ACK này ko đc gửi ra network interface qua đó mới làm giảm tốc độ down ở máy đó đc)

Còn 1 khả năng nữa là phát triển 1 protocol mới ứng dụng ở router cho việc phân bổ băng thông smilie

mong các bác cho ý kiến thêm và cả góp ý nếu trong lập luận của mình có chỗ sai smilie
nếu mà bạn truy cập trực tiếp bằng IP thì DNS hay domain chẳng đóng vai trò gì cả (bạn nói chuyện vơi ng Lào bạn mới cần phiên dịch, chứ ban nói với mình bạn có cần phiên dịch ko smilie)...
trong trường hợp của bạn nếu vào IP 72.232.x.x mà chạy qua IP 220.231.x.x thì đúng như bạn qtra004 nói là do url wwwection.
các bác cho em hỏi 1 câu:

member như thế nào, có điều kiện gì thì mới dược vào 1 số group như Elite member, Researcher, Ky thuat vien ...

Thanks smilie
ping chả vào cổng nào cả ...
ping chỉ kiểm tra xem cái host mà bạn ping vào có liên lạc được hay không thôi.
trường hợp của bạn thuannghich thì ping thoải mái chí có điều không vào dc trang web chủ thôi
nhân nói về chia sẻ băng thông các bạn cho mình hỏi rõ hơn 1 chút:

chẳng hạn bây giờ nhà bạn có 3 máy (tạo thành 1 LAN nhỏ) kết nối ra internet qua 1 router.
1) Thế thì việc bandwith được chia cho 3 máy như thế nào là tùy theo váo thời điểm đấy tốc độ download của 3 máy thế nào đúng ko ?
2) Nói cách khác, 3 máy cạnh tranh bandwith internet theo tốc độ download ở mỗi máy. Và máy nào đang download với tốc độ cao thì sẽ giành đc nhiều bandwith nhất ?
3) việc chia bandwith này là do router làm ???
4) Trong trường hợp xấu nhất, sẽ có máy sẽ chỉ download dc rất chậm hoặc thậm chí ko download dc ?

nếu mình không nhầm thì tất cả việc phân bổ bandwith này là do phương thức TCP quy định với field recive window trong header của tcp segment và hoạt động của TCP congestion control ?

bạn nào chắc chắn có thể kiểm chứng lại xem mình suy nghĩ có chính xác ko ?
nếu cái máy ở IP 72.232.160.165 không phải webserver kô mở cổng 80 thì ko kiểu gì bạn vào được cả
có khả năng là khi bạn cài Fedora không set cài grub vào MBR cho nên ở MBR vẫn của Windows --> sẽ tự động vào Win khi được khởi động
có khả năng là khi bạn cài Fedora không set cài grub vào MBR cho nên ở MBR vẫn của Windows --> sẽ tự động vào Win khi được khởi động
 

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|