IRC channel logs
2023-05-07.log
back to list of logs
<mihi>Even when looking at LibreBoot supported hardware (without checking certification), the most recent model supported is the HP EliteBook Folio 9470m released in 2012... <mihi>(unless I missed one on the LibreBoot website) <mihi>which is about the age of my L530 (and I am considering to replace it this year). <stikonas[m]>Well, that is unavoidable future for libreboot on x86 <stikonas[m]>In 20 years getting librebootable x86 system might be as hard as getting computer from 1980ies today <stikonas[m]>Though I expect corebooted systems will be more common in 10 years than now <oriansj>stikonas[m]: well I got an IBM 5150 serial number 120 surprisingly easily; my bet in 20 years getting a librebootable x86 system will only be possible if we as a community pool together funds and build those systems from scratch <oriansj>Part of me wishes there was an organization which collected funds, designed systems and certified partner companies' products as RYF certified as they are built to the freely available spec. <oriansj>Odd there are no RYF certified RISC-V systems and the RYF certified PowerPC systems are all Server/Workstation power envelope <stikonas[m]>oriansj: if might be that at least some RISV-V systems are tainted with non free GPU drivers or WiFi firmware <stikonas[m]>Latter you can replace with some 802.11n based USB dongle (most likely you would need something using ath9k) <oriansj>or in the RISC-V unleashed, required nonfree fimrware to enable memory <oriansj>and a closed ISA does not guarantee a closed SoC either. <aggi>i hope for, ao486 to scale up, with decent hardware support from a linux-2.x kernel, including usb <aggi>currently, last time i checked on opencores.org, only usb1.x was fully documented with some hdl/verilog; not any later version <oriansj>hmmm, well one could live with less than high performance but that'll definitely make USB based installs quite slow. <aggi>some custom SeaBIOS was ported to ao486 already too, so that one is fully free/open down to hardware digital circuitry, depending on how FPGA and related tooling are qualified <aggi>j-core.org made notable progress too, with their turtle-board design; although this ISA is less common (and not supported with tcc) <oriansj>well if it it fits on an iCE40 FPGA or other Icestorm compatible FPGA, then probably quite free. <muurkha>if you only need low-speed HID devices you might be able to get away with less than even USB1.0 <aggi>i don't have any hope for any x86_64/ACPI/SMP/UEFI/>=USB2.x type system <muurkha>good luck finding an HDL synthesis toolchain that doesn't involve any C++ though <aggi>usb1.x; that was roughly 10Mbps iirc... it's not that bad <muurkha>you're probably going to have to write your own <muurkha>things like Migen don't involve any C++ but they generate Verilog, not netlists <aggi>that's why, z80/gigatron 8bit realm is appealing; the gigatron ttl can be soldered onto a breadboard, and the chips are documented sufficiently otherwise <aggi>if you need/want something practically usefull, with posix, networking, usb etc... ao486/fpga deployment seems the best to hope for, currently; or the j-core.org stuff <oriansj>aggi: there is no reason why someone couldn't do a 32bit processor with an old-school Pinout designed for breadboards <aggi>don't know, exactly when the computer-aided-design (CAD) overwhelmed the development of digital circuitry <aggi>i heard rumors, earlier i386 were designed with pencil and paper <aggi>another reason, to remain sceptical, with any of the more recent 64bit type systems; all their supply chains, both software and hardware, are fully entangled into the globalized, clusterf*** <oriansj>well the DEC Alpha's initial implementation was hand designed. <muurkha>it's not that hard to design an RV32I core <muurkha>there are certain things you have to multiply by 32 instead of 8 <aggi>did some reading about those DEC systems, their earlier 32bit ones, already provided general purpose 128bit data processing... most recent intel systems 40 years later do not <muurkha>32 stages of carry chain instead of 8 or 16. 3 levels of lookahead carry instead of 2 <muurkha>it doesn't really add any complexity to the design process <aggi>i suspect, it's related to the COCOM and 1984 SCPA protectionism of USA, to sanction particular technology <stikonas[m]>RV32I doesn't have many instructions, so it should be easier to implement compared to x86 <aggi>and nothing changed since then... recently there was some story, about lattice semiconductor, who introduced some relatively liberated FPGA things <muurkha>but it requires a fair bit more silicon to implement, and a lot more work soldering and debugging if you're putting stuff together by hand <muurkha>but, yeah, it's fair to say that AVX-512 isn't general-purpose <aggi>those earlier DEC VAX offered general purpose 128bit, 40years ago already... which too is relevant for cryptography, and the pain a simple xorshift on 128bit int types can be <muurkha>and you don't lose much by implementing them with vector instructions like AVX-512 <stikonas[m]>Else people now use non general purpose accelerators <muurkha>I don't think anybody has RSA accelerators <aggi>well, some symmetric crypto can be implemented relatively easy and fast then... although i doubt it would be 512bit, because fast xor-shifting requires a barrel-shifter in hardware, and for large data-tupes, those become extremely expensive <muurkha>the reason 128-bit and 256-bit integers aren't in mass-market hardware (or basically any hardware) is that almost no customers care about 128-bit performance. nothing to do with export controls <aggi>i proposed a cipher/hash design, little while ago, simple LFSR, put into a matrix (to scale up from 32bit to any other desired block size) <aggi>add some nasty non-primitive recursion to those... and you got the strongest military grade symmetric crypto ever <muurkha>AES doesn't benefit from 128-bit or 256-bit integers either <aggi>which requires nothing but a barrel-shifter, which are available always with 32bit, and are extremely fast <stikonas[m]>muurkha: wouldn't matrix multiplication ops be faster on 128/256 bit CPUs? <aggi>don't know, if AES could be implemented with 8bit datatypes... in a way, i think RC4 was a better cipher design than AES <muurkha>aggi: it sounds linear in the vector space GF(2)ⁿ and therefore trivial to break <aggi>i added some non-primitive recursion agains known-plaintext key-recovery <muurkha>well, you haven't described it in enough detail to show otherwise <aggi>i consider my design not prone to this type of attack, even when it's "one round" only <muurkha>stikonas[m]: yes, if your matrix elements need more than 64 bits of precision <aggi>muurkha: i already published some test-implementation, hacked against linux dm-crypt, for 64bit <muurkha>aggi: cool, but that doesn't tell me anything about its security <stikonas[m]>Even after studying them a bit as part of maths courses <aggi>but meanwhile, down-graded to 32bit, simplified and improved the design further, and utilize the ancient loopdev api from linxu for this <aggi>and hacked it into dropbear ssh, for testing... and well, it's fast... the fastest cipher ever, in software (with barrel-shifter available) <muurkha>the identity cipher and NOT are surely faster <aggi>i consider, the 32bit variant, safe... it's the best cipher design ever proposed, for software <muurkha>the problem is that they aren't secure <aggi>it can be used in ECB too, if the limitations are known <muurkha>aggi: how would you know if it's any good or not? which cryptosystems have you broken? <aggi>muurkha: i reviewed some stuff <aggi>and the non-primitive recurse LFSR matrix design, was just for fun, to showcase "crypto" can be done differently <aggi>meaning, as _simple_ and fast/efficient as possible, with maximized strenght <aggi>instead of blowing up complexity <muurkha>stikonas[m]: in the usual case your matrix elements have a lot less precision than that, and things like AVX-512's elementwise multiply of vectors of 16 32-bit floats is a lot more helpful <aggi>furthermore, the whole LFSR/CRC related stuff, was reviewed for decades, so i trust that <aggi>the non-primitive recursion however, that's the idea of mine, to prevent known-plaintext key-recovery... <muurkha>aggi: I notice you haven't answered which cryptosystems you've broken, which makes me think you don't have the expertise to assess the quality of your cipher <aggi>if you go low-power embedded, such as i do, and want to copy over ssh... for example, such as fast and secure cipher design is very desireable <muurkha>the standard rebuttal to snake-oil cryptography claims is that anyone can devise a cipher he can't break himself <aggi>and my cipher design, is the fastest, it's faster than RC4, and probably, more secure <aggi>muurkha: i too offered the design to Leibniz institute of mathematics in Germany... <muurkha>being more secure than RC4 would be no great feat <aggi>to some expert, who refused to elaborate on this design <aggi>muurkha: and it is much faster than RC4 too, the design i proposed <aggi>the 32bit variant, which i didn't publish, is very few lines of code only... and it's probably the smallest and less complicated variant ever <aggi>it's scalable, for various block-sizes, up to stream-cipher type of operation... can be utilized as hash-function, or PRNG... <aggi>i mean, even NATO specified LFSR for "scrambling" with 8bit only, and no non-primitive recursion added... but it's not "crypto" then, MIL-STD-188 that was <aggi>anyway, i think that's the reason why, there wasn't general purpose 128bit anymore, because of this type of crypto <muurkha>"primitive recursive" is a concept from computability theory that doesn't seem to apply here <aggi>it did apply it, non-primitive recursion against known-plaintext key-recovery attacks <aggi>otherwise, LFSR are considered not secure... sure, i do know that <aggi>LFSR are not snakeoil, and non-primitive recursion is the result of an algorithmic expansion for known-plaintext key-recovery attacks, meaning those are not feasible then <muurkha>I think you are probably going to do good work with this, but only if you can let go of the idea that you've already done it <muurkha>learn to break some cryptosystems first <aggi>i already did publish a 64bit variant, but i think the 32bit variant is much better, because it's ridiculously simple to implement, simple to review <muurkha>study how the most recent big breaks like those of MD5 and SHA1 work <muurkha>then you'll be in a position to distinguish a secure cryptosystem from an insecure one <aggi>i don't comment on MD5 or SHA1, because i am no expert on those; i only do know with certainty what i designed and implemented myself <muurkha>until then, of course any expert at the Leibniz Institute will decline to elaborate on the design <stikonas[m]>Not everything in NATO is super secure... UK nuclear weapons used to be secured by something like bike lock keys <muurkha>because it's just another cryptosystem that can probably be broken with standard techniques the author doesn't understand <aggi>i only tried to say, LFSR are well researched and known, among telekom and military, and LFSR can easily be improved upon, to make them safe <aggi>but for this, you do need to know, what you're doing, otherwise they're prone to known-plaintext key-recovery attacks <muurkha>Ron Rivest tried to improve upon LFSRs to make them safe, which is where RC4 came from, but as you know, he failed <aggi>no, RC4 are not based upon LFSR <aggi>but RC4 has an advantage over LFSR, i think, which is RC4 does not require 32bit data-types; my LFSR design does need 32bit registers <muurkha>it's a stream cipher, and the most obvious and well-known stream cipher is XOR with an LFSR <aggi>i see the whole symmetric "cipher" discussion more closely related to the block-mode of operation and the hashing method chosen <aggi>another reason why, AES is weird <muurkha>you could of course get lucky and stumble across an algorithm that is actually hard to break, even if you don't know it <aggi>if i couldn't use that in ECB mode... <stikonas[m]>And true, most likely experts just wouldn't have time to answer random emails <muurkha>but it's enormously more common for amateurs to reinvent well-known broken cryptosystems, or slight variations on them that are vulnerable to the same standard attacks <aggi>anyway, that's why i was reading about DEC VAX, that it had 128bit general purpose already, 40 years ago <muurkha>I've found that experts are usually very willing to answer random emails <aggi>and DEC supported 128bit integer and floating point with those... by concatenating several registers, somehow <muurkha>But there's a certain category of random emails they tend to ignore <muurkha>Excited emails from amateurs who are sure they've stumbled across a groundbreaking result in their field, but who evidently lack the expertise to distinguish groundbreaking results from others <muurkha>The hotel where I'm staying this weekend, the owner was telling me about his son, who is quite a gearhead <oriansj>Crypto discussions are rarely productive if they don't include links to working code and/or peer reviewed analysis <aggi>i am still struggling to decide, if i may continue with any efforts for linux-2.4/tcc/tccboot, or if i'll depart into the 8bit realm (gigatron, z80 whatever) and be happy there <muurkha>And has a design for an electromagnet-based perpetual motion machine <muurkha>aggi: have you thought about 12-bit, 16-bit, or 18-bit? <aggi>oriansj: i published the 64bit/dm-crypt proof-of-concept three years ago already <muurkha>You can ddesign a 32-bit non-Linux processor pretty easily, even without HDLs, down to the gate level <aggi>muurkha: no, i consider 32bit broadly available nowadays, and almost all those got decent barrel-shifter <aggi>that's why, my cipher is that fast, without any "acceleration" <oriansj>aggi: no links were provided. Hence the ask. in a more productive direction. Have you checked out the commander X16 yet? <muurkha>The bit-serial design used in SeRV is a way you can even build it in less gates than a normal 8-bit processor <aggi>oriansj: sadly, the C64/8bit era predates my active carreer <oriansj>as you expressed interest in the 8bit realm <muurkha>having more than 16 bits of address space and more than 8 bits of instruction word will simplify your life enormously <aggi>sure, it was 16bit adressing <oriansj>or 24bit if you do some bank switching <aggi>no expert, but i was reading Z80 used 4bit ALU concatenated, to support larger integer type operations, hence was a tad slower <oriansj>although the 6502 has the dumbest stack design <muurkha>oriansj: it's not very flexible but it sure is fast <stikonas[m]>It's easier for physics experts to deal with amateurs inventing perpetual motion machines. Unlike ciphers, there isn't even a small chance to stumble upon those <muurkha>stikonas[m]: no, because you have to build the machine before you find out it doesn't work <muurkha>and even then that's often chalked up to a construction quality problem <aggi>i proposed this cipher, because there was various "experts", who questioned my expertise, for a little while too long <muurkha>aggi: if you want to prove them wrong, break some existing cryptosystems, or improve known attacks on existing cryptosystems <oriansj>but a 256byte stack limit isn't really enough for anything past assembly. Heck even FORTH can easily cross that line <muurkha>there are existing curricula for how to learn how to do this <muurkha>it's enough for anything that isn't recursive <aggi>i made it non-primitive recurse <aggi>just for them, those experts, to break mine <muurkha>incorrect usage of standard terminology is a bigger red flag than inventing nonstandard terminology for standard concepts <oriansj>again. If no links to working code or peer reviewed articles. Please drop the discussion of crypto <aggi>that's the dm-crypt/64bit proof-of-concept; i won't publish the 32bit one... it's too god <aggi>it's much simpler, than AES or any other, far less lines of code, it's very fast, the faster one proposed ever <aggi>it's intended for tiniest embedded, low power systems <aggi>simple portability, and full trust in the design <oriansj>aggi: I am glad you made something that you are proud of. But we are a Free Software Community; we share the good things we make so that we all benefit in a non-zero sum community. <aggi>the 32bit variant too is much better, because i dropped the whole idea, to hack against linux-kernel crypto-api (i removed the entire crypto-api from my linux kconfig btw..) <aggi>oriansj: to my knowledge, Intel never published particular things <aggi>and there is many other stories: ACPI, UEFI, the whole firmware.exe junk <aggi>COCOM, 1984 SCPA... well, no, there isn't any "community" who shares the "good things" <aggi>that's another reason why, nowadays, the clean system bootstrapping, is a horror show <oriansj>aggi: well yes but we are not intel. we are #bootstrappable; there are no secrets. No exclusion. No Deception. No Fear nor Intimidation. No Information Control nor Reporting Structure. <oriansj>Yes, there are a great many problems we face but by working together and with other communties; we can improve the situation. One step at a time. <oriansj>we publish for the whole world, so that they can see our mistakes and our most impressive work. If they care about us, they will tell us what we could have done better. <rickmasters>stikonas, fossy: have you guys tried a qemu build lately? The sysc disk image seems to be running out of space. Or is it just me? <vagrantc>anyone going to be coming to 2013.fossy.us in mid-august? would love to see a bootstrappable talk there <vagrantc>will propose a reproducible builds talk and touch on bootstrappable stuff ... but bootstrappable probably deserves it's own talk <oriansj>vagrantc: well, I was just about to ask if you have a time machine I could borrow ;-p <vagrantc>not sure guix time-machine is up for that just yet <oriansj>do you know if they would accept a remote talk? <vagrantc>asked in the conservancy XMPP channel ... <vagrantc>oriansj: another angle would be to propose a talk and there is a notes-to-the-organizers field where you could mention that <aggi>oriansj: #bootstrappable is _the_ project, with which i recovered some hope for free/open software (and hardware!) <aggi>and there is some problems remaining, to cope with "bureaucracy" here, which is the hindrance to me working and publishing freely <aggi>unrelated to bootstrappable/gnu <fossy>rickmasters i did do one with GCC but not since then.. <stikonas[m]>rickmasters: yes, I tried and it failed in sysc install stage <oriansj>well if anyone is interested in Ada, there is work there needed for Guix. And Libreboot needs Ada support for native graphics initialization on most Intel boards. <fitzsim>cool, I didn't know Libreboot used Ada <Irvise_>hi oriansj, there is a very small group of people who is aware of this issue :) <Irvise_>theruran kickstarted the idea and some discussions have already taken place in order to see how we can bootstrap Ada. <Irvise_>Sadly, that is going to take years, as progress is basically nonexistent (lack of time...) <Irvise_>I talked to GNUtoo from #libreplanet during FOSDEM as he pointed this exact issue to me. <Irvise_>Therefore, I believe, the best thing to do now is to get GNAT/GCC-Ada support into Guix using a binary ala Haskell. That way Ada packages could already be packaged into Guix. <Irvise_>After that, the bootstrapping system could see some work (an probably some more hands...) <Irvise_>If someone would like to help me get Ada packaged in Guix, I would give that priority in my life (not the highest overall, but in terms of projects) <oriansj>Irvise_: well given that GNAT was originally bootstrapped from Ada-ED, (which is packaged in guix) one would think there might be a much easier path to bootstrappaing Ada by checking if an earlier version of GNAT can be compiled and if not, what handful of features are missing. <Arghadeep_Saha>Hello I am new to this field as some of you suggested me to study the documentation of the GNU Mes project. I am studying that. Can anyone please list some more resources to learn from? <Irvise_>oriansj: afaik, GNAT was bootstrapped in closed source form (internal to the Uni of NY) using Ada-ED. It was written in Ada83 (using Ada-Ed). Once it matured, it was rewritten in Ada95 which was compiled with itself. Finally, that Ada95 src version was then opened to the public/upstreamed in GCC (3.12p) <oriansj>Arghadeep_Saha: you need to be a little more precise on your end goal before effective recommendations can be made. <oriansj>Irvise_: that would be quite unfortunate and someone confirmed that the initial release is not buildable by Ada-Ed correct? <Irvise_>Though I did read the original release documentation (introduction) and it said that it was very buggy and that it should not be used and potentially be unable to build a lot of programs while leaving some parts of the Ada95 standard out. <Irvise_>I could give it a try. But it is a really old release... I would not be surprised if even the C backend would not build in todays systems... <oriansj>Irvise_: fair enough but thank you for checking. <Irvise_>I will report back. Hopefully within a couple of months. <oriansj>ouch, hard to imagine the Ada build environment is that horrid. <theruran>not that hard to imagine since as you have pointed out @oriansj most compiler developers forget about the issue of bootstrapping as soon as possible <oriansj>theruran: but taking months to setup, is kind of an epic step past how long it takes to setup even the worst C bootstrap environment. <Irvise_>oriansj: I meant that it will take me a bit of time as I am extremely busy nowdays :( It should not really need that much time! :) <Irvise_>theruran: hey! How is the PhD going? Did the application go all right?