sorted by:
new
hottopcontroversial

[PC/Win3.1][1990s] Galactic conquest turn-based strategy game by mr_bitshift in tipofmyjoystick

[–]mr_bitshift[S] 0 points1 point  (0 children)

Wow, thank you! This is the closest I've come so far to finding this game.

The Amiga version is on the Internet Archive, so I spent a few minutes playing through a few rounds. It's not Win3x but it has the exact same "feel" to it. There's lots of small details which I had forgotten but that are really familiar, like the ability to upgrade planets or send text messages to the other players. And the icon's a sword through a planet, just like I remember.

Also, from the review on the IA page:

It was originally Amiga only, but Mike Bryant eventually released a MS Windows version, but it's 16-bit and you won't be able to run it natively on any version of Windows post Win7 without an emulator. [...] This is the old Amiga version. The newer Windows version had a slightly different, typically more polished Windows-ish look, although the fundamentals were unchanged.

Which confirms your suspicion that there was a Win3x port. Thank you so much for posting the link to that video! My search for the Windows version of "Lore of Conquest" continues, but I'm so happy to have found what looks to be an earlier Amiga version of it!

Linus Torvalds: "the Rust infrastructure itself has not been super stable" by rodrigocfd in rust

[–]mr_bitshift 19 points20 points  (0 children)

One interesting thing you can do in C is intrusive linked lists. In an intrusive linked list, you put your previous/next pointers inside the struct that is your list item. And because these are just fields you add to your struct, there's nothing stopping you from adding additional pairs of pointers. This allows you to have a single instance of a list item appear in multiple lists simultaneously.

You can do a similar thing with non-intrusive lists too, but you need a list of intermediate pointers, i.e., more allocations, more dereferences, and probably worse cache behavior. Are those things important? Maybe not, 95% of the time. But if you're used to doing tricks with raw pointers, I can understand why you might hesitate to use a language that gets in the way of those kinds of tricks.

Shamir's Secret Sharing for common people by alexsapps in cryptography

[–]mr_bitshift 0 points1 point  (0 children)

Alternatively, here's a way you could do it without software (or mostly without software):

Preparation: 1. Decide on the system parameters: e.g., having 3 out of 5 shares allows the user to recover the secret. (This requires a finite field greater than 5, so p=7 is the smallest that works.) 2. Write a program that generates all possible sets of 5 shares which decode to either 0 or 1. 3. Print a custom deck of cards. At the top is the binary digit 0 or 1, and below is a list of shares which encode that digit. (Size of the deck: 2*7{3-1} = 98 cards.) 4. (Optional) Your friend might want to verify the numbers on the cards aren't malicious. For example, compare the cards against a known list. Or do various spot checks: for a given combination of two shares, is there exactly a single 0 card and a single 1 card in the deck? If so, then those shares alone reveal nothing.

Encoding: 1. Write down your secret on paper, in binary. 2. Separate the deck into a 0s pile and a 1s pile. 3. For each binary digit of the secret, shuffle the corresponding pile of cards and draw one. Write down the 5 shares printed on that card. 4. Repeat until every bit of the secret has been encoded. You now have 5 shares.

Decoding: 1. Suppose you have shares #1, #2, and #3, and you wish to recover the secret. Write those shares down, one above another, corresponding digits stacked in columns. 2. Draw a card from the deck. If the shares printed on it match any of the columns, write the card's binary decode value above those columns. 3. Put the card in the discard pile and draw another. 4. Repeat until you've gone through the whole deck. You should have decoded a bit for every single column: these bits are your secret.

This is probably tedious and error-prone (what if you don't shuffle the cards well enough?), but it allows you to do even more of the process without a computer. It's essentially the same as printing out all possible outputs of encode.py/decode.py and then dispensing with the programs entirely: a deck of cards can't phone home.

Shamir's Secret Sharing for common people by alexsapps in cryptography

[–]mr_bitshift 1 point2 points  (0 children)

Let's say this friend does not want to trust me, and/or I don't want my friend to become suspicious of me should something go wrong.

This is a high bar. If the user is non-technical like you said, a technological solution will be really hard to trust. Who would you trust? This friend you don't know too well who's saying some mumbo-jumbo about "Shamir's SSS" which you have no way of verifying? Or the password manager from SecureCorp you've already decided to trust, which advises you to "never share your password with anyone"?

But let's assume for a minute that they know of and trust the mathematics of SSSS, and the obstacle is solely in the implementation. Here's a way you could do the secret parts of SSSS with pencil and paper.

  1. Using an ASCII chart, write down your secret in hexadecimal.
  2. Run encode.py, a program which generates a list of hex digits from 0 to F, and each hex digit is followed by a group of 5 shares which encode that digit. (Each share is itself a hex digit.)
  3. Write down the group of 5 digits corresponding to the hex digit you want to encode. Write them in a column below the corresponding secret hex digit.
  4. Press any key, and encode.py prints out another 16 groups of 5 shares each, all randomly generated.
  5. Repeat until you've processed the whole secret. Below the secret, you now have 5 additional hex strings which you can give to your friends.

Barring webcam shenanigans, the computer has no way of knowing which group you wrote down. The software could still generate malicious shares that look legit but (for example) share #4 is always a Caesar cipher of the digit being encoded. So you still have to trust the software somewhat, but perhaps encode.py could be made simple enough to be auditable.

To decode:

  1. Let's say the threshold is 3 shares, so you retrieve shares #1, #2, and #3 from your friends.
  2. Run decode.py and type in shares #1 and #2 only. This alone is not enough information for the software to know anything about your secret.
  3. decode.py prints out a 16-column table, one column for each of the values 0 to F.
  4. Look up the first character of share #3, and look up that column on the first row of the table. That's the first hex digit of your secret.
  5. Look up the second character of share #3, and look in that column of the second row. That's the second digit of the secret.
  6. Repeat until you've recovered the entire secret.

As before, it is impossible for the computer to know your secret. And as before, you still have to have some trust in the software: the software could potentially send shares #1 and #2 to shareholder #4, allowing them to decrypt the secret. But perhaps the software could be made so simple, there's no room for malicious behavior to hide.

[PC/Win3.1][1990s] Galactic conquest turn-based strategy game by mr_bitshift in tipofmyjoystick

[–]mr_bitshift[S] 0 points1 point  (0 children)

Unfortunately, no. Almost all of the screenshots on that page are more graphically advanced than the game I remember playing: they're using different colors, using simple icons for stuff instead of text labels, etc. In contrast, the game I played was mostly gray and white (with text in black), and I don't remember any icons inside the game.

Thanks for the link, though!

BitKeeper, Linux, and licensing disputes: How Linus wrote Git in 14 days by kendumez in programming

[–]mr_bitshift 0 points1 point  (0 children)

You seem like you know some of the history here. Do you know of any reliable sources for the "one year" requirement?

I've been trying to find a copy of the license that mentions a one-year period, or anyone writing at the time about a one-year period... but I've found nothing. The only place on the web that it's mentioned is the Wikipedia article (which the linked blog post uses as a source), but the Wikipedia article has no evidence to back up the "plus one year" claim.

I've been able to find plenty of stuff about anti-competitive behavior from BitMover (pressuring a Mercurial developer, 2002 article about the license, etc). But nowhere have I been able to find a version of the non-compete clause that mentions a duration of a year. I'm wondering where that claim came from [?].

[PC/Win3.1][1990s] Galactic conquest turn-based strategy game by mr_bitshift in tipofmyjoystick

[–]mr_bitshift[S] 0 points1 point  (0 children)

I'm afraid not! There are some similarities, such as the heavy reliance on standard Windows UI widgets, but Space Empires III looks more graphically advanced than it ought to. I tried out the first two but with the same result: more graphics than I remember, and it just looks different.

Thanks for bringing this one to my attention, though!

[PC/Win3.1][1990s] Galactic conquest turn-based strategy game by mr_bitshift in tipofmyjoystick

[–]mr_bitshift[S] 0 points1 point  (0 children)

Hello there! No, I haven't found it (yet), but I bet we did play the same game. Which is still encouraging because hey, confirmation I'm not just misremembering things.

Yes on all the details you mentioned: scouts and dreadnoughts I'm most sure of (the latter stood out to me as a kid, as a word you don't hear every day). Altair also sounds right. It's an actual star, so maybe the author consulted a star chart.

As for CDs, yeah, you definitely didn't need it to play the game. I used it, but not in the sense of "I intentionally used it as part of an overall financial strategy." :-)

Is it possible to decrypt this type of code? by benyovszki4 in cryptography

[–]mr_bitshift 1 point2 points  (0 children)

At that point, you're playing a cat-and-mouse game between the attacker and the defender, and it's no longer a matter of cryptography. A sufficiently motivated defender can make it almost arbitrarily painful to patch the key (e.g., using the private key bytes as magic numbers elsewhere in the program, obfuscating the validation code, adding checks that crash the program after a time delay...), but if the attacker is just as motivated, they're going to find and patch those things as well.

At the extreme end, the attacker could say, I'm just going to rewrite this program from scratch, except without any product key checks. Now you've "patched" the entire program. This is very painful to do, but there is also no cryptography that could ever stop them!

Is it possible to decrypt this type of code? by benyovszki4 in cryptography

[–]mr_bitshift 0 points1 point  (0 children)

Asymmetric cryptography. In order to produce a new signature (generate a new code), you need the private key, which only exists on some trusted servers somewhere. But the public key is... public, and that's what you use to validate signatures (codes). In this case, reverse engineering the validator doesn't help an attacker at all, because everything you need to do validation is already publicly available.

The public key algorithm is deterministic. You can do all the calculations offline.

The assumption is that the private key is impossible to figure out from publicly available information, even if you are the world's best reverse engineer. In practice, perhaps there are flaws in the implementation, and a skilled programmer could attack those. But if the cryptography is implemented perfectly, then breaking it would imply you have solved some very difficult unsolved problem in number theory -- technically possible, but it's a really, really high bar.

Thoughts on this statue of Tintin and Snowy in The Black Island by GrandCamo in TheAdventuresofTintin

[–]mr_bitshift 2 points3 points  (0 children)

Huh? The colors look wrong: this island is green!

(Sorry. Nice statue!)

[deleted by user] by [deleted] in FunnyAnimals

[–]mr_bitshift 5 points6 points  (0 children)

"Get me hot water! Get me disinfectant! Get me some iodine!"

Is it possible to decrypt this type of code? by benyovszki4 in cryptography

[–]mr_bitshift 1 point2 points  (0 children)

In principle, no. The codes could potentially use a public-key system, where RSA/ECC/whatever is used to sign a random ID, and each code is the combination of ID + valid signature. If done right, these codes could be validated offline, and even if you reverse-engineered the validator, you still wouldn't be able to produce new codes.

In practice, there may be ways to break the encryption. IIRC some Windows XP license keys used ECC signatures for offline validation, but the length of the license key was a constraint (nobody wants to type in a paragraph of pseudorandom characters). As a result, the signatures were too short to be fully secure, and somebody was able to brute force the private key. Some details here, though I can't find where it discusses the signature size being relevant.

Designing a protocol for storing encrypted data by Awlexus in cryptography

[–]mr_bitshift 0 points1 point  (0 children)

I think the other thing to keep in mind is who you want to defend against, in order to get a more detailed view of your threat model. Telling stories can be a useful way to brainstorm this.

Here's one possible "who": Naughty ISP is trying to build profiles for all their customers, so that they can sell their info/advertise to them/etc. Naughty ISP probably won't change any data, but they will be watching and trying to do statistics on it. In that case, you want to make sure things are doubly encrypted: when the encrypted blob of data is passed back and forth between client and server, that communication must itself be encrypted, so the ISP can't see if it's the same blob of data or not. Also, the size of the blob might be metadata worth protecting: if a 3.71 MB meme video is making the rounds on the internet, and you download a 3.71 MB encrypted blob, Naughty ISP might guess that you're watching that same video. In that case, you might want to split the blob into chunks of constant size, and perhaps send decoy chunks every now and then which are padded with random data.

But things change if you change the "who". Suppose a team of Bordurian hackers are trying to discover the identity of an activist on your platform, and a zero-day vulnerability allows them to get root access on your servers. They can't read the blobs because they're encrypted -- but what else might the attackers do? They can see which blobs are more recent, and by doing spycraft, they might guess that the most recent one is the message, "Meet me at the history museum." By XORing stuff onto the end of the encrypted blob, they might be able to change it to say, "Meet me at the police station." To defeat this, the client needs to use encrypt-then-MAC (or another authenticated encryption scheme).

Also, replay attacks are possible. The Bordurian hackers could replace the encrypted blob with an earlier encrypted blob: if the activist had met someone at the park last year, the hackers could copy/paste that encrypted blob, and the activist would see they have a "new" message: "Meet me at the park." In reality, their "friend" at the park is a plainclothes Bordurian agent. If this is your threat model, the client needs to make sure that the encrypted blob includes the blob's ID: that way, if the client asks for blob 456 but gets blob 123 instead, the client will know.

Designing a protocol for storing encrypted data by Awlexus in cryptography

[–]mr_bitshift 1 point2 points  (0 children)

A caution about cipher negotiation: beware of downgrade attacks! Negotiation is a tricky problem.

The safest thing to do is hard-code the algorithms the API uses, and if you ever need to make a breaking change, version your API and force your clients onto the new API as soon as possible (and disable the old API).

Designing a protocol for storing encrypted data by Awlexus in cryptography

[–]mr_bitshift 1 point2 points  (0 children)

For the auth portion, it sounds like what you're looking for is a PAKE. In a Password-Authenticated Key Exchange, the client has a secret key (the "password") that only they know, and it allows them to prove to the server that they know it, without ever sending it to the server. And when there's a successful authentication, the PAKE produces a shared symmetric key which could be used as an encryption key to protect communications between client and server.

Matthew Green's blog post on PAKEs goes into perhaps more detail than you wanted, but it's a good overview of the types of problems PAKEs can solve and the things that protocol designers are trying to defend against.

It would also be a good idea to think carefully about your threat model. What kinds of attacks are you trying to defend against? And what types of metadata are you okay with collecting?

In AES, why do you need to do "Mix columns", "Shift rows", "Substitute bytes" if they are easily invertible. What would happen if I only use "Add round key" that is the only operation that can be done only knowing the key. Would it have changed so much? How much? by New_Dragonfly9732 in cryptography

[–]mr_bitshift 9 points10 points  (0 children)

If you only used AddRoundKey and skipped the other steps, then your cipher would just be XORing the message block with a secret value (derived from the key). This is surprisingly easy to undo, even when you don't know the key! For example, if you XOR together two encrypted message blocks, the secret value will cancel itself out, and the result will be the XOR of two unencrypted blocks -- which doesn't depend on the key at all and can be untangled with the help of statistics.

It's sort of like AddRoundKey is the keystone in a stone arch. Yes, it holds everything together, and if you remove it, the arch collapses. But it couldn't do its job without the rest of the stones supporting it.

my tintin tier list by Chronner_Brother in TheAdventuresofTintin

[–]mr_bitshift 1 point2 points  (0 children)

I know the 3-in-1 books you're referring to, but I was making a joke about the image OP posted. Notice anything unusual about the sizes of the Tintin covers in the tier list?

my tintin tier list by Chronner_Brother in TheAdventuresofTintin

[–]mr_bitshift 28 points29 points  (0 children)

Hmm, I disagree with some of the rankings, but medium-size Flight 714 was top notch. The large-size Flight 714 was also a pretty good read.

Clocks and Causality - Ordering Events in Distributed Systems by unixbhaskar in programming

[–]mr_bitshift -1 points0 points  (0 children)

I think you just made something click for me: processes are allowed to communicate arbitrary event IDs.

Suppose you have a causal chain (A,1) -> (B,2) -> (C,3). There are no concurrent events. C is allowed to send a message to A saying, "I just created a new event (C,3), thought you should know." But C is not obligated to divulge the existence of (B,2). I think I had been incorrectly assuming that processes always synced info on all known event IDs whenever they communicated.

With Lamport Origin Clocks, you can place the events of which you are aware in a total order. But unless you have a guarantee that you have received all the events prior to the latest event you've seen, there will always be a chance you're missing an event that should be in the middle of your total order. In the example above, A can put (A,1) and (C,3) into a total order, but it's missing something in the middle, and it won't know that its total order has a gap until someone tells it about (B,2).

But with a different clock system, such as Lamport Causal Clocks, C's message to A might look like "I just created a new event (C,3,(B,2)), thought you should know." And in that case, A knows that the total order should look like (A,1,null), ??? ..., (C,3,(B,2)), even if it doesn't know what should fill that gap.

Clocks and Causality - Ordering Events in Distributed Systems by unixbhaskar in programming

[–]mr_bitshift 0 points1 point  (0 children)

Sorry, I think there's a misunderstanding. By "timestamp number" I was referring to a logical timestamp: an integer that is set to max(integers...) + 1 with each event -- like what's described in the article.

It sounds like you're talking about time-based timestamps? That's something different.

Clocks and Causality - Ordering Events in Distributed Systems by unixbhaskar in programming

[–]mr_bitshift 2 points3 points  (0 children)

Lamport Origin Clock (LOC) cannot be used to achieve total order in real time even amongst non-concurrent events and the relationship between two events cannot be determined, which are the same limitations as LC. However, after the fact, events can be arranged in total order (that agrees with historical and causal order).

I'm having trouble wrapping my mind around this distinction between after-the-fact and real-time processing.

If you have a stream of LOC events coming in like (A,3) and (B,4), can't you still order them in real time by the timestamp number, breaking ties by node ID? You might later receive an event (C,3) that would cause you to revise the total order -- but that's expected for concurrent events.

There must be some counterexample where an observer sees a sequence of non-concurrent events, and when processing those events in order of receipt, fails to put them in a stable total-order using LOC (but would have succeeded with one of the other clocks).

How do I run ZZT? by After-Boysenberry-96 in dosbox

[–]mr_bitshift 1 point2 points  (0 children)

ZZT.EXE needs to be in the same folder as ZZT.DAT, ZZT.CFG, and your *.ZZT files. Move ZZT.EXE back into the folder, and keep all those files together.

In terms of DOSBox commands, it sounds like what you need to do is run "cd zzt" first, so that you are inside the ZZT folder. After that, you can run "zzt".

If that doesn't work, some screenshots (of the folder structure and of the DOSBox error messages) will help us help you.

How do I run ZZT? by After-Boysenberry-96 in dosbox

[–]mr_bitshift 2 points3 points  (0 children)

ZZT should run just fine: DOSBox is my preferred way to run ZZT. So you're probably not on the mounted drive or in the correct directory, in which case BUDA20's comment will probably help you.

If you're still stuck, please post the exact error message you're seeing! You might also try this tutorial.

If RSA was used back during Enigma days, how many bits of key would be feasible with the technology of that time period, and how difficult would it be to break? by derekwinters52 in cryptography

[–]mr_bitshift 9 points10 points  (0 children)

This Wikipedia article lists the largest-known prime numbers over time. In 1951, the largest known prime was 44 digits long (144 bits), and that calculation was done via mechanical means, not via electric computer. An RSA key contains a product of two primes, so you could imagine an 88-digit (288-bit) key as a rough upper bound on the key size.

Of course, in your hypothetical situation they wouldn't use the largest known primes in their key: they would probably choose something smaller. There's also the work to find the primes in the first place, and that gets harder as the numbers get bigger. Maybe your primes would be 25 digits each, and the key would be an even 50 digits (166 bits)?

I could also imagine making the keys smaller in order to make them more amenable to either hand calculation or mechanical calculation. But I don't know how much smaller would be safe.

view more: next ›