HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelfโ™ง 0
โ† Back to top all-time
pannous
xipher
C2015โ€“2015
pannous / xipher

xipher

๐Ÿ”’ Simple perfect xor encryption cipher ๐Ÿ”’

3Distinct people
3Mentions
0Explicit recommenders
63GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

๐Ÿ”’ Simple perfect xor encryption cipher ๐Ÿ”’

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7โ€“Nov 14 UTC ยท Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by hour3 dated mentions

Observed mentions: 2015-01-24 17:29:21 UTC to 2015-01-24 19:46:41 UTC.

012015-01-24 17:00:00 UTC to 2015-01-24 18:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJan 24, 17:002015-01-24 18:00:00 UTC to 2015-01-24 19:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 24, 18:002015-01-24 19:00:00 UTC to 2015-01-24 20:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 24, 19:00

Counts come from the repositoryโ€™s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 24, 17:002015-01-24 17:00:00 UTC2015-01-24 18:00:00 UTC110
Jan 24, 18:002015-01-24 18:00:00 UTC2015-01-24 19:00:00 UTC101
Jan 24, 19:002015-01-24 19:00:00 UTC2015-01-24 20:00:00 UTC101

What Hacker News says

3 sources
For one-time-pad encryption, both sides have a copy of the same secret key. The name says "one-time," because if a key is used to encrypt two different plaintexts, information will leak. In this implementation, the results of two encryptions may be based on the same bytes from the key file; not for all bytes, but for some. This is because it chooses bytes from the file (function generate_random_offsets() at https://github.com/pannous/xipher/blob/master/encrypt.c), then writes both the address of those bytes and the XOR'd value to the result of the encryption. There is no provision to avoid picking the same offsets/key-bytes from one encryption-run to the next, except that they are chosen at random. Because the format of the encrypted messages is very simple, it can be easily determined for two encrypted messages, which key-bytes they sha
Read the rest
re. Remedies: store between runs, remove 00 from file,define chunks in the file? It's not too difficult to avoid sharing the secrets between two encryption runs; it is not even necessary to chose the key-bytes from the file at random. One could just use the key-bytes in sequence, send the address of the first key-byte, and store the next available key-byte for the next run. When the shared key-file doesn't have enough random bytes, because it has been used for encrypting too many message, it can error out -- which it should, but this implementation will never do that.
In Show HN: Write (almost) perfect encryption in an hour

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.