Điểm:1

Xác minh công khai rằng vé được cấp bởi cơ quan có khoảng 8 chữ số

lá cờ cn

Tôi đang xây dựng phần phụ trợ cho (các) ứng dụng web để chúng tôi có thể bán vé cho các sự kiện của mình. Các sự kiện dao động từ 100-700 khách.

Chúng tôi bán vé trực tuyến và chúng tôi muốn có thể quét vé ở lối vào. Điều này được thực hiện thông qua Mã vạch-128. Nhưng trong trường hợp không thể quét mã, người dùng có thể nhập mã và kiểm tra theo cách này. Vì vậy, mã không được dài hơn khoảng 12 chữ số.

Vì ở một số địa điểm, chúng tôi không có internet nên có thể tải xuống thứ gì đó như khóa công khai trước lễ hội.

Tôi đã nghiên cứu một chút và tìm thấy cái này. Mà dường như là một giải pháp tốt. Chỉ cần lấy các mã định danh kéo như id sự kiện và id đơn hàng (có thể băm chúng), ký tên và chỉ lấy 5 chữ số đầu hoặc 5 chữ số cuối của chữ ký và nối chúng vào chuỗi. Người xác minh sau đó có thể kiểm tra chữ ký. Nhưng điều này có nghĩa là xác minh phải giữ khóa riêng. Để tạo toàn bộ chữ ký và chỉ so sánh một phần của nó hoặc chữ ký đó rất dài. Tôi có đúng không? Tôi không thích điều này vì người xác minh phải độc lập với người bán.

Sau đó, tôi nghĩ: được rồi, hãy làm điều tương tự, lấy hai mã định danh và mã hóa chúng một cách bất đối xứng.Vì vậy, tôi có thể chia sẻ khóa riêng và chỉ khi phần thứ hai có thể được giải mã bằng khóa chung và khớp với phần đầu tiên thì vé mới hợp lệ. Các phương pháp mã hóa không đồng bộ mà tôi biết luôn tạo ra các tin nhắn rất dài. Vì vậy, vấn đề tương tự như trước đây.

Sau đó, tôi tìm thấy cái này mà có vẻ tốt. Nhưng tôi tự hỏi liệu FPE có quá dễ bị phá vỡ hay không vì tổng kiểm tra chỉ có từ 5 đến 8 chữ số và đó không phải là nhiều entropy.

Tôi có phải lo lắng về điều này không? Hay ai đó có một ý tưởng khác, tốt hơn? Kiến thức về mật mã của tôi rất hạn chế. Có lẽ tôi đã hiểu điều gì đó sai.

Điểm:0
lá cờ my

Mã hóa bảo toàn định dạng sẽ hoạt động tốt. Thay đổi tôi sẽ thực hiện là không sử dụng nó làm 'tổng kiểm tra' mà thay vào đó chỉ lấy số vé (có thể là giá trị từ 0 đến 699 chẳng hạn) và FPE mã hóa số đó dưới dạng số có 12 chữ số). Bằng cách đó, bạn không phải lo lắng về 'entropy giới hạn', bởi vì việc phá vỡ nó sẽ yêu cầu đoán khóa (nếu là 128 bit trở lên thì quá khó) hoặc đoán ngẫu nhiên và hy vọng bạn đánh đúng mã vạch - trong trường hợp đó, nếu bạn phát hành 1.000 vé hợp lệ (và do đó, chỉ các giá trị giải mã thành 0 đến 999 mới được chấp nhận), xác suất đoán đúng là $10^{3-12}$, nghĩa là, một phần tỷ - tỷ lệ cược không thực sự tốt.

Vấn đề duy nhất tôi có thể thấy với FPE là không có triển khai chung (điều này thật đáng tiếc - tôi tin rằng FPE là một công cụ hữu ích nói chung)

Tuy nhiên, có một giải pháp thay thế thường có sẵn và cũng sẽ hoạt động tốt - Mã xác thực tin nhắn (MẠC).

MAC hoạt động giống như một chữ ký, ngoại trừ việc không có các khóa ký và xác minh riêng biệt - thay vào đó, một khóa thực hiện cả hai thao tác. Bạn sẽ tạo một khóa ngẫu nhiên và đưa khóa đó cho cả người phát hành vé và máy quét vé (giống như trong ý tưởng FPE).

Những gì bạn cần làm là ghi ba chữ số đầu tiên của vé là số sê-ri 000-999 (hoặc 699 nếu bạn có 700 khách). Phần còn lại của các chữ số sẽ là MAC của ba chữ số đầu tiên, được chuyển đổi thành số thập phân (và được cắt bớt một cách thích hợp). Để xác thực vé, máy quét sẽ lấy ba chữ số đầu tiên và tính toán MAC (sử dụng khóa mà nó biết) và kiểm tra 9 chữ số cuối cùng.

Điều này mang lại cho bạn khả năng bảo mật giống như ý tưởng FPE và việc triển khai MAC luôn sẵn có. Tất nhiên, với một FPE, bạn không phải lo lắng về việc chuyển đổi mọi thứ thành số thập phân (FPE có thể làm việc trực tiếp với các giá trị thập phân); MAC tiêu chuẩn hoạt động ở dạng nhị phân và do đó, để biến chúng thành số thập phân, sẽ cần một số loại chuyển đổi cơ sở; tuy nhiên, mã chuyển đổi cơ sở đơn giản hơn nhiều so với mã FPE đang hoạt động.

Có một số loại MAC có sẵn; Tôi sẽ tránh xa MAC bằng IV và gắn bó với HMAC, KMAC và CMAC.

Một vấn đề cuối cùng để bạn xem xét (không liên quan gì đến câu hỏi của bạn): một cuộc tấn công rõ ràng sẽ là lấy một vé hợp lệ và chạy nó qua một máy photocopy và tạo ra một số vé sẽ xác thực. Nếu bạn có một máy quét duy nhất, bạn có thể dễ dàng ngăn chặn điều đó (bằng cách để máy quét ghi nhớ tất cả các số sê-ri mà nó đã thấy trước đó). Nếu bạn có nhiều và họ không thể giao tiếp, thì đó là một vấn đề lớn hơn.

Alex avatar
lá cờ cn
được rồi cảm ơn bạn đã trả lời rộng rãi! Tôi không thể ủng hộ vì tôi có quá ít nghiệp chướng. Và cảm ơn vì vấn đề bổ sung. Tôi đã nghĩ về điều này và nghĩ rằng tôi đã tìm ra một giải pháp tốt, giải pháp đó hiệu quả với chúng tôi. Nhưng với MAC, tôi sẽ gặp vấn đề tương tự như khi ký tên, tôi sẽ phải chia sẻ bí mật mà tôi không thích. Sẽ có một giải pháp khác. Bạn có nghĩ rằng nó có thể làm những gì tôi muốn
poncho avatar
lá cờ my
@Alex: thực ra, FPE sẽ chia sẻ cùng một vấn đề; nếu bạn không tin tưởng trình xác minh bằng khóa, nó sẽ không hoạt động. Mặt khác, bạn có thể tin tưởng người xác minh đến mức nào? Nếu bạn có thể tin tưởng người xác minh sẽ không tạo vé cho sự kiện này (nhưng bạn không muốn tin tưởng họ về các sự kiện khác), cách rõ ràng để làm điều đó là tạo khóa mới cho mỗi sự kiện - đối với máy quét, chỉ tải xuống chìa khóa cho sự kiện này...
Alex avatar
lá cờ cn
vâng, lần đầu tiên tôi nghĩ rằng có một cách không đối xứng để làm điều này. nhưng tôi chỉ tìm thấy một tờ giấy. Tôi nghĩ rằng tôi phải thỏa hiệp
fgrieu avatar
lá cờ ng
Điều này không đáp ứng yêu cầu _public_. Với ít hơn khoảng 70 chữ số thập phân (cho hoặc nhận), sẽ không có gì an toàn.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.