mras0 · HackerTrans

7 maanden geledendiscuss

There already exist cross-compilers (e.g. http://sun.hasenbraten.de/vbcc/ and various amiga-gcc versions). vAmos is more for the case where you want to use an Amiga-native compiler (say SAS/C http://pjhutchison.org/tutorial/sas_c.html) but work on Linux/Windows.

mras0

7 maanden geledendiscuss

Amiga Forever is a distribution of software (Amiga ROMs and OS disks) and a full system emulator: CPU, custom chips (graphics/sound/..) etc. It allows you to emulate various Amiga systems completely.

vAmos is just CPU and an embedded ROM/OS replacement that does just enough to run (some) AmigaOS command line programs. The primary use case is for cross-development (running Amiga compilers/tools, testing simple stuff, etc.) without having to boot a full system emulator for each command and better integration with e.g. host-side Makefiles.

With the vAmos=WINE analogy, Amiga Forever=VirtualBox/VMWare.

mras0

9 maanden geledendiscuss

Size optimizing assembly code finds use in a variety of places. Demoscene for size constrained things is one of them, but also "hacking"/exploits and of course "whitehat" stuff (patches / compiler optimization etc).

mras0

9 maanden geledendiscuss

I understand what you're getting at, but in this case even I (who know what most things on that page means) struggle to understand why it was submitted. Are we looking for the 0E opcode? New optimization opportunities?

Genuinely asking, for this post did you click on the link and say "yeah, I got the point" or did you involve an LLM? If you did, what did you ask it? I'm asking because I want to get better at LLM use (Another example post (and prompt) where you've used this, that's also fine)!

mras0

9 maanden geledendiscuss

The link is to an opcode map with strange abbreviations with no apparent explanation. Asking "What am I looking at?" without doing any research (with a LLM or otherwise) is entirely reasonable.

mras0

9 maanden geledendiscuss

Not sure why you're being downvoted. You need a to know quite a bit of esoteric knowledge to parse this beyond knowing x86 opcodes (even x86 assembly).

It's more or less the same information you get from the intel manuals (specifically appendix 2A of https://www.intel.com/content/www/us/en/developer/articles/t...). There you can also see what e.g. "Jb" means (a byte sized immediate following the instruction that specifies a sign-extended relative offset to the instruction).

One-byte opcodes here differs from 2 byte opcodes (386+ IIRC) prefixed by a 0F byte and even more convoluted stuff added later.

mras0

12 maanden geledendiscuss

No, it's due to the construction of bcrypt - it ends up using the password more or less directly as the key for blowfish (the underlying cipher) which is why the limit is there. Check wikipedia for details.

mras0

12 maanden geledendiscuss

bcrypt is based on the blowfish cipher which "only" support keys up to 576 bits (72 bytes) in length (actually only 448 bits as spec'ed). Wikipedia has all the details.

mras0

vorig jaardiscuss

> moduli generated by OpenSSL will always have the high bit set

Correct for 1024, but...

    openssl genrsa 1023 | openssl rsa -text -noout

:)

Also just noticed that openssl rsa actually has a -modulus switch so you can make do with "cut -b9-"

mras0

vorig jaardiscuss

The standard format for RSA private keys is ASN.1 (https://www.rfc-editor.org/rfc/rfc8017#appendix-C) with the components encoded as INTEGERs. An INTEGER is always signed in ASN.1, so you need the leading 0 byte if the MSB of your positive number is set.

OpenSSL is just dumping the raw bytes comprising the value. Tools that don't show a leading zero in this case are doing a bit more interpretation (or just treating it as an unsigned value) to show you the number you expect.

mras0

vorig jaardiscuss

Not really the ethos of C(++), though of course this particular bug would be easily caught by running a debug build (even 20 years ago). However, this being a game "true" debug builds were probably too slow to be usable. That was at least my experience doing gamedev in that timeframe. Then again code holding up for 20 years in that line of biz is more than sufficient anyway :)

mras0

vorig jaardiscuss

Good luck! As the sibling comment mentions, Asm-Pro is IMO a good choice these though it requires KSv2+ (so you can't use it on an stock A500). I mostly use vasm for "larger" stuff though (http://sun.hasenbraten.de/vasm/) and cross-compile (though it can run on Amiga as well) / test in an emulator.

For a quick test/code loop nothing beats the Asm-* family - remember to save often and make backups though :)

mras0

vorig jaardiscuss

Update: a1=-1 is a bad choice of test value (0 is much better), as it won't show the issue if present! However, it doesn't change the outcome of the test on 060, but I would have noticed that 020 is affected as well (as also mentioned in the comments to the article).

mras0

vorig jaardiscuss

Rev5 "full" 060 (not EC/LC). Quick capture of crappy methodology: https://imgur.com/a/XwQ1Tnp (PCR with revision number is in d0)

mras0

vorig jaardiscuss

Have an Amiga w/ 060, and that instruction doesn't seem to modify any A registers. (Only did a very quick test of those exact instruction words)

mras0

2 jaar geledendiscuss

Thanks, understand what you mean. I probably botched the 1/4 probability thing, was thinking 4^-60 gives 2^-120 bit assurance (roughly, security margin in my mind), and an extra round would quadruple it, but doesn't work that way I realize.

mras0

2 jaar geledendiscuss

Thanks for the reply (and it definitely answers my original question). For both short-lived keys, and where production time matters it makes perfect sense. I was mostly thinking about the scenario where you're generating a key for e.g. a long-lived certificate (maybe even a CA) or high-stakes PGP stuff. Just seems like you'd want spend a few more seconds in that case.

mras0

2 jaar geledendiscuss

I don't pretend to understand all the involved math, but what I'm trying to say is that as far as I understand T rounds gives 4^-T probability that we've chosen a "bad" prime (really composite) per normal Miller-Rabin in the worst case. Doing ~5 rounds has been shown to be enough to choose a good prime candidate, under most (very probable!) conditions when we get it a random, and thus the argument is that that ~5 rounds is fine. We agree so far?

I'm just asking, why not run the conservative 60 round test, rather than ~5 when you're doing a very rare, one time, key generation? I understand that it's very unlikely to reject any numbers, but at least BSI thinks it's worth it for important keys.

If I understand the recommendation right, you wouldn't do 60 for a 2048 bit key and then 120 for 4096, rather 61 rounds would be enough for 4096 if 120 is alright for 2048.

mras0

2 jaar geledendiscuss

The BSI recommendation I linked says 60 times here (considering the worst case and the security level they're targeting). Just wondering why we'd want to do less for a (presumably rare) one-time operation.

mras0

2 jaar geledendiscuss

I happened to look at this recently, and while I understand the argument (but not the math) of having to do fewer Miller-Rabain rounds, why would you do so in PRACTICAL settings? Unlike ECC you're likely only generating long term keys, so shorter key generation time seems like a bad tradeoff. Composite candidates are going to be rejected early, so you're (with high probability) not doing expensive calculations for most candidates. My reading of [BSI B.5.2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...) confirms this.

Of course random bit flips could interfere, but other measures should thwart this in high-stakes environments (at least to some degree).