Hi,

I built an AES encrypted LoRa (Long Range <1 GHz) chat.

It uses 128-bit ECB mode for encryption. As hardware I used a Raspberry Pico 2W, a 3,5" TFT Resistive Touch Display ILI9488 (SPI for Touch and Display), a SX1262 LoRa Node Module by Waveshare (SPI, supports half-duplex only) and a Pico Dual Expander Board by Waveshare. You can find everything I mentioned here on Google.

I use VS Code with PlatformIO extension. As C++ libraries I use RadioLib (unofficially has integrated support for AES), TFT_eSPI and the LCDWiki touch library (because I tested other touch libraries and they don't work). The encryption key can be changed by typing “/CHANGEKEY <key>” or disabled by only typing “/CHANGEKEY”.

This is the Pinout I was using for the touchscreen (since for some reason SPI didn't work on the same bus sharing with the LoRa module; I needed a separate bus for touchscreen, display // LoRa module):
#define TFT_MISO 16 // SD0/MISO
#define TFT_MOSI 19 // SDI/MOSI
#define TFT_SCLK 18 // SCK
#define TFT_CS 17 // CS
#define TFT_DC 22 // D/C
#define TFT_RST 21 // RESET
#define TFT_BL 13 // Backlight, HIGH=on
#define TOUCH_CLK 6
#define TOUCH_CS 4
#define TOUCH_DIN 7
#define TOUCH_OUT 8
#define TOUCH_IRQ 5

It was a fun project to see what I can build. One of my friends said "specific" people might be interested in this since when powered off there's no chat storage and there's encryption but this was not my intention to build this, I always had a fascination for data that can be transferred wirelessly. :-)

Ask me anything.

This is a close-up.

>>2918442 (OP)
> AES encrypted LoRa
As far as I understand, /diy/ham/ thinks that is probably illegal in the ewe ess of eh.

>>2918444
>As far as I understand, /diy/ham/ thinks that is probably illegal in the ewe ess of eh.

I had to laugh. :-) If /ham wants to listen in, they can't. :P

What exactly is illegal? The frequency I use or that it is encrypted? I believe it depends on the country and state regulations.

I share a little bit more:

TFT_eSPI tft = TFT_eSPI(); // you need to set User_Setup.h in the TFT_eSPI library

LCDWIKI_TOUCH my_touch(TOUCH_CS, TOUCH_CLK, TOUCH_OUT, TOUCH_DIN, TOUCH_IRQ); // These (TOUCH_CS, etc.) are from User_Setup.h

SX1262 radio = new Module(3, 20, 15, 2, SPI1, RADIOLIB_DEFAULT_SPI_SETTINGS); // when you put the Pico LoRa module on top of the Raspberry Pico 2W or on the Waveshare GPIO expander, this is the way to go.

I also forgot to say that since it's half-duplex, you need to do something like this:

void setFlag() {
if (transmitting) actionDone = true;
else receivedFlag = true;
}

and you use the method to call setFlag():

radio.setDio1Action(setFlag);

https://www.youtube.com/watch?v=2Ry-ck0fhfw

>>2918448
seems like a good way to get a blackhawk helicopter to land in your front yard

>>2918476
I already thought about getting LilyGo or unPhone https://shop.pimoroni.com/products/unphone?variant=40829810311251

>>2918483
by using LoRa? :-) You just have to make sure that you're using the right frequency for your country.

>>2918488
ok :|
but have you heard of this? https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

>>2918476
https://www.youtube.com/watch?v=0A7A-CSd3e4
Another part on a different channel.

>>2918495

A few weeks ago I wanted to buy hardware and I wanted to buy the Heltec ESP32 + LoRa (https://heltec.org/project/wireless-tracker/) but then decided to extend my Pico project since I already had the LoRa module. But if I have 40$ left over I will get my hands on the 2x Heltec.

I think the next thing I will build is a magnetic stirrer because I already have the other stuff I need to build. I just need to buy a magnet and build an engine rotor with a 3d printer (my neighbor has).

3 different generals you could have posted this in instead of creating this useless thread

>>2918510
where? which generals? I'm new to 4chan

>>2918448
The encryption is illegal. So is using nonstandard encodings.
We don’t know what you’re exfiltrating, nor to whom.
But, at least you’ll get to see a blackhawk helicopter close-up.

>>2918520
/ham/, /ohm/, /mcg/

>>2918522
the wattage is too low to care, fcc part 15 or whatever

should i post there or would that be considered cross-posting?

>>2918526
nah, if you start a separate thread next time at least put your code and shit on github though. how's your experience been with the pico 2w? i liked the pico, they kinda seem like power hogs though and rarely do i need multi processing

>>2918531
I rarely had any hardware issues with the Pico 2W. My first Pico that I soldered I completely fucked up but it was still working.. I have now 5x Pico 2W and the Pico family is growing :3

Due to simplicity I can also recommend using Arduino SDK on the Pico. Also, PlatformIO extension is great and seems to be the go-to extension for hardware developers since most boards are supported.

What I miss on the Pico is the proprietary WiFi-Now Protocol by Espressif, see here: https://www.espressif.com/en/solutions/low-power-solutions/esp-now

Other than that it's totally worth its price, I can totally recommend the Pico 2W.

>>2918448
>frequency or encrypted
likely both are illegal depending on the frequency, but unless you're causing a massive amount of interference on something "important" like an airport or cops or some shit (highly unlikely) no one will even notice.

>>2918546

The frequency I'm using is legal, I double checked that. Encryption of data is not only legal but also supported by the government's data protection laws I'm residing in and is generally used in LoRa applications.

> The frequency I'm using is legal, I double checked that. Encryption of data is not only legal but also supported by the government's data protection laws I'm residing in and is generally used in LoRa applications.

** The frequency I am using is legal, I have double checked that. Encryption of data is not only legal, but is also supported by the data protection laws of the government of my residence and is generally used in LoRa applications.

Hijacking Real Quick

I Know AES is theoretically Impossible to Crack but what about Motorolas ADP?

I know it's possible but I'm not to sure how to go about doing so.

Shits been eating at me for a while.

>>2918442 (OP)
sounds pretty much like something i had a long time ago.

>>2918442 (OP)
Whats the use case? For fun? If you want to save some money on transmitters you can use lolra. https://github.com/cnlohr/lolra You need the ch32v203 not the 003 or you can use esp32 or 8266. I asked you what use case because you can use it on the things network, you can use a lorawan network to transmit messages, if they aren't encrypted they will use less power and travel faster. I plan to use mine for gardening info so its less important to encrypt it.

>>2918442 (OP)
Just get a motorola talkabout with the text chat option, uses frs/gmrs.

>>2918619
https://duckduckgo.com/?q=Motorola+Advanced+Digital+Privacy+(ADP)+cracking

All I could find was that ADP is a 40-bit RC4 kinda proprietary Motorola standard. Nothing very specific.

>>2918726
There's no use case (right now). I built it for fun. :) I have plans to put it all with a battery in a 3D printed case to carry around. I didn't know of lolra, but it's good to know! Thank you. I recall another project here but for SBC (Raspberry Pi): https://github.com/pimylifeup/fm_transmitter

>>2918728
Thank you. But I like to build stuff myself :)

>>2918726
Further thinking about it, it's actually a pretty good idea to use Lolra. That would make it easier to 3D print the case. But I wonder how reliable it is.

>>2918728
>>2918703
I don't think you people understand how much range these LoRa devices are getting.

>>2918741
Elaborate.

>>2918442 (OP)
Nice work OP but meshtastic has had AES capability already. In any case you should consider contributing to their efforts, its by and large the strongest and farthest along LoRa standard software out there.

>>2918444
>>2918483
>>2918522
its not illegal and even if it was /ham/dorks can go fuck themselves while they gobble on FCC cock.

>>2918754
Thanks :3 I know this might sound odd but I like the process of putting work into something and enjoying the process and the end result. While doing that I also learned a lot about LoRa configuration, how to handle half-duplex communication (this can be tricky if you never did before) and how to prepare a minimal GUI for a touch display. And there's still so much more to learn.

Neat project! What’s the range on it? What data rate can it support?a while ago I was looking at building a remote self contained lorawan weather station that would send readings back to a base station. As I recall lorawan is really low data rate, and the rate is worse the further the transmission goes. I know Lora (maybe lorawan too) in different countries has different frequencies that are legal or illegal- can your device change frequency bands on the fly?

>>2918741
If it got good range it will be banned.
Also, if everyone started using it, it will be banned and/or useless. Some lora/internet gateways are already saturated. You’re getting into it on the tail end of its useful lifespan before it was destroyed by idiots.

>>2918777
> data rate.
Remember your 110 baud cup modem? Luxury. You’re going to dream about how great it was in the 70s.

Oh, and for you zoomers, that thing on the left is a “telephone” and the thing on the right is a computer that was used by creatives (or, what are called trans people now). The thing in the middle is the acoustic coupler modem.

>>2918777
>What’s the range on it?
I haven't tested yet (but I would love to) because I have no one to test with. People say 3 to 4-5 miles under ideal environmental conditions.

>What data rate can it support?
It is not suitable for transferring huge amount of data. It's slow af.

I use:
Bandwidth = 500 kHz
Spreading Factor = 12
Coding Rate = 4/8

Rs = BW / 2^SF
500 000 Hz / 4096 ≃ 122 symbols/s

CR = 8-4 = 4
Rb = Rs * SF * (4/4+CR)
Rb ≃ 122 * 12 * 0.5 ≃ 732 bit/s (0.73 kb/s)

That means 91.5 byte/s. Packet size is 256 byte maximum. To send a single packet with 256 bytes, it takes about 2.8 seconds for transfer. Correct me if I'm wrong.

>>2918733
I don't think its worth it if you aren't going to have someone to talk to, it will just be like hams going im from xx where can you hear me from, wow yy cool. If you use it for gardening you can ignore the encryption, unless you really want to hide the humidity. If you are in the us you can get a LORA module for cheap, they are like $3. If you are in the US, you will want the 915mhz version, like the LLCC68.

I got a few of them just to use as receivers, I will use esp32, and cnlohr's video shows it can have a very reasonable amount of range with these cheap chips.
>>2918735
If I was to make a network this is the system:
LLCC68 LORA receivers perched high in the range I would use it to receive data, but now the chips are all very expensive since the tariffs, and the LORA chips are not that much more, still at volume OP will save at least 20% at the cost of range, even now he can cheapen the board and the LORA module. You can also relay to internet encrypted messages.

>>2918847
> 915 MHz version
I don’t see what difference it makes, why can’t they standardize across countries?

The military reserves 90% of the bandwidth for nothing, and when they introduce electronic countermeasures, they just get flustered and use any frequency possible anyway. Just start out with that, because you will anyway.

The russians went so far as to use enemy cell phone towers and cell phones…

>>2918748
>>2918787
In a practical sense people are getting 3 miles. It can go much further of course with direct line of sight. Like carrying it on a drone. But range of one device is not the big thing. The cool ass thing is that it can carry your message across devices. So it can hop from your device across 20 strangers to reach your buddy 30 miles away. Like a peer to peer file share for text messages. Messages can be encrypted or even just shared with everyone it can reach.

>>2918963
Ahh, so like the internet in the 80s and maybe early 90s.

>>2918442 (OP)
Good thing you used libraries for the LCD, or it would've taken you a gorillion years to make the graphics and fonts. Or maybe I'm just a basket case
Anyway, i too made a LoRa gateway which lives on a pole at the top of my house. It talks to my on-body computer. Not sure what to do, the computer has a bunch of sensors and a 4Ahr slim li-ion cell

>>2919016
I guess kind of like the 80's when your mom wouldn't let you pay the toll fees of far away BBS numbers. So you were forced to only connect local. But back then you could share text files and ascii art. Not yet here.

>>2918442 (OP)
That is honestly great. Good work.

>>2918448
Laws about what you can send and receive vary by country, but assuming you live in burger land:
https://www.offgridweb.com/preparation/encrypted-radios-aes-256/amp/
>In the Code of Federal Regulations (CFR), Title 47 § 97.113 — “Prohibited transmissions,” the Federal Communications Commission (FCC) prohibits amateur radio users from transmitting “messages encoded for the purpose of obscuring their meaning.” This blanket statement effectively prohibits everything from advanced ...
Similar laws exist all around the world, so you're with a very high likelihood breaking some serious law.

>>2919269
these devices are covered under fcc part 15, the same rules that dictate wifi routers and other consumer wireless devices. part 97 governs amateur radio. buried in here is something like under 10 watts basically do whatever you want https://www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-15

>>2919272
s/10 watts/1 watt/ https://www.ecfr.gov/current/title-47/part-15#p-15.247(b)(2) my bad. in any case, encryption is a non-issue since part 15 doesn't care and actually encourages it:
>§ 15.9 Prohibition against eavesdropping.
>
>Except for the operations of law enforcement officers conducted under lawful authority, no person shall use, either directly or indirectly, a device operated pursuant to the provisions of this part for the purpose of overhearing or recording the private conversations of others unless such use is authorized by all of the parties engaging in the conversation.

>>2919274
to even further lay this to rest here is the sc1262's fcc certification under part 15c

>That is honestly great. Good work.

Thank you :3

>>2919274
Yeah? wait for a war or an invasion to be declared and see what happens.
At least you’ll be easy to find.
Unless ICE picks you up first.

>>2919489
seems inappropriate but ok, you upset or something because you bleated out the first result google search ai gave you without even thinking about how wifi is allowed?

>>2919492
Wifi is allowed because it doesn’t go far.
In addition, all the wifi keys they use are already submitted to the government.
Also the encryption is incredibly weak if they wanted to brute force it. Look at wpa.
They even decided that the antennas can’t be removable on wifi routers not too long after they were allowed for sale. There was an incident :-)
On a wifi, you have no idea how they work or what they’re actually doing because the chips are undocumented. For all you know, every one has a plaintext sidechannel.

>>2918442 (OP)
at first i was cross with you for wasting a thread and not even posting your code
>>2918483
>>2918522
>>2918546
>>2919269
but then you drew out some retards who blindly said encrypted transmissions are illegal, presumably because they are/know hamfags who only know the laws for licensed amateur radio
>>2919541
and now we have this stupid nigger, who went from "encryption is illegal" to "well the government knows all encryption keys anyways". never seen documentation because he doesn't understand what he is looking at, so he rejects it as nefarious magic https://file.elecfans.com/web1/M00/BA/E6/o4YBAF6ijEqAQpDBACLQAF2ggPY084.pdf

overall 8/10 thread, i take back what i said about posting this in any of the generals

>>2919566
>overall 8/10 thread, i take back what i said about posting this in any of the generals

Thank you.

>at first i was cross with you for wasting a thread and not even posting your code

Currently, the code is missing for example a scroll bar for scrolling the messages. Right now messages are scrolling automatically for each new sent/received messages. Also, it's not fully optimized yet, I need to refactor the code. I also have the issue that even though I have two seemingly identical constructed displays (same manufacturer, same ICs, same interface), that the touchscreens work a bit differently in code.

>>2918442 (OP)
Very cool OP. There was a guy on one of the fediverse nodes, I think SPC or Poast, that was working on a similar project a couple of years ago. That you?

>>2918959
to make it operable with others if you want to add or connect to a mesh network, nobody is stopping you from using 433mhz but you will not be able to tx or rx 915 everyone else standardized on unless its only for you

>>2919566
This post is entrapment, and nobody is going to click on your malware pdf that your department bought from nso group. Find something useful to do and stop wasting taxpayer money.

Unmodified government approved encryption, encoding, and antennas are not illegal, per se, it’s “roll your own” encryption that is illegal.

>>2919624
alright well if you're too afraid to download a pdf from a manufacturer i don't really know how to help you. picrel is from the documentation for the wifi chip on the pico 2w. remind me, which pin is it again for the "plaintext sidechannel"?
>roll your own encryption
you have smoked yourself retarded. you can use any encryption you want, legally, including your own custom cipher, as long as you keep it under 1 watt and not on any banned frequencies

>>2919629
> which pin is it
It’s the same pin used to enable SSL on web requests, except you pull it high instead of holding it low for plaintext.

Lol, that’s not how any of this works, but you gave me a chuckle.

>>2919637
which pin is it? i sent you the pinout you fucken retard. what pin do you enable for "SSL on web requests"? (hint: we've been using TLS for about 5 years now)

>>2919741
my bad time flies, 10 years now we've been using TLS

>>2919637
>curl is a hardware function
kek

>>2919741
You need to toggle the pins in sequence.
Please send the transistor-level schematic of the device, and a de-capped chip with the microphotographs of the actual die with schematic cross-references (so we can tell if the schematic didn’t happen to include the secure enclave housing the back do… i mean “secure management module” for your safety)

>>2919776
Software based encryption is for poors

>>2919742
> 10 years now we've been using TLS
Oh, did the government tell you to use TLS?
OP isn’t using TLS, at least.
Next you’re going to tell me that the free “let’s encrypt” service isn’t a massive key exfiltration system by the .gov, the .mil, and/or the .il

>>2919617
>Very cool OP. There was a guy on one of the fediverse nodes, I think SPC or Poast, that was working on a similar project a couple of years ago. That you?

Thank you. No, that's not me

>>2919805
i think you either mean tpm or bmc but you're too low iq to bother looking it up. nice big words though, did chatgpt spit that load of bs out?
>he buys useless accelerators

>>2918442 (OP)
> ECB mode.
Sigh.

>>2918442 (OP)
well done OP. You should now:
- put it on github so the nsa can pick it up, introduce laws against this very thing;
- sell it as prepping tech;
- keep it to yourself as an invention no one will hear about;
- get it patented hoping a major networking company will buy it off you someday (or lose your savings trying to prove you came up with the idea first);
- 3d print a shell and try to sell it on ebay for $29.99;

whatever you do, congratulations on your invention, you probably feel like a million bucks rn.

>>2918522
>The encryption is illegal
What if I just enjoy to broadcast random data between two devices?

>>2918754
> by and large the strongest and farthest along LoRa standard
I’m still going to destroy lora by holding lora DXing contests continually.
It’s probably for the best, the birds lora was invented to track can finally go free.
t. ham

>>2918754
>meshtastic
I was under the impression that Rnodes was better in every way that mattered besides user count. Because it does packet routing, it doesn't clog the network to the same extent, among other things.

>>2919269
Unrelated to lora. The fuck is wrong with you ham retards

>>2920472
aside from us, the rest of the developed countries are all subjects to the royal crown where if a brown murder-rapes your daughter they'll let him go free and jail you if you say anything about it. no hamfags would say encryption is illegal for lora since the technician covers fcc part 15 and 97 extensively

>>2920137
Thank you but I'm not feeling like a million bucks :/ I wish I did. But this was just another day project. I have a few unpublished projects.

>>2920545
In actually it's much worse than not allowing encryption. In fact, part 97 basically says you're not even allowed to "obscure" an unencrypted channel.
For example, you can't transmit some extra junk in between legitimate signals that make it more difficult to determine the intended operational signals. Unless you're running satellites.

This also goes for things like telemetry signals. Most devices you can get ahold of will broadcast their telemetry plainly.

Because the language is so vague, it could mean almost anything is banned if they want it to be. Talking in pig latin. changing the 10- codes so that 10-4 means "no police presence in the area"

>>2920588
yes, hamfags complain to the fcc all the time when their neighbor's shit interferes with their ragchews and unfortunately by law the fcc is supposed to be on their side. lora though is part 15, not part 97; eavesdropping is illegal however if you transmit in the clear it's technically public hence the unwritten "encouragement" to use encryption. there is no law or standard on how to implement it

>>2920588
also technically whistling is illegal on cb, truckers don't give a fuck though not should they

>>2918442 (OP)
I'm 90% sure someone have created this before + with mesh network or something
nice project tho

Short update, I'm 3d printing now a box. Don't know if it's going to work out, this is the first time doing it.

For editing I used the free Autodesk Fusion but I had to delete it again because my disk space is almost full. For printing preparation (slice) I used UltiMaker Cura.

>>2920568
can i ask how old you are or what your situation is? if you do this as a hobby, or professionally... etc

>>2920631
>>2920637
also i'm a 3d guy, so if you need a hand let me know.

>can i ask how old you are or what your situation is? if you do this as a hobby, or professionally... etc

I am currently unemployed and I do it as a hobby but it's also part of my job background. I'm 30 :)

>also i'm a 3d guy, so if you need a hand let me know.

that would be nice.

>>2920631
Are you sure the walls are going to be thick enough to block an EMP?
Better go solid infill using mu metal powder entrained filament.

>>2920664
I have not considered that yet but with the "open" display on top that could be affected by an EMP does it even make sense?

I have an Encryption question because I can’t find an answer to this, but it almost certainly has a name.
I know a one time pad is unbreakable. If both devices share the pad initially, can they include their message AND the next pad on their next transmission? Then each subsequent message has a new pad in it so as long as the initial one isn’t known it will remain unbreakable?

>>2920674
Also, is there a commercial product that does this: Imagine a peripheral that your phone connects to (wired or blue tooth etc), and the peripheral has a powerful radio, antenna, and battery. So it can send/receive data (voice, text, small data files) through an app on the phone except it’s using a different radio frequency than the cell phone. I think the use case would be if you’re communicating in the back country/natural disaster and want the good user interface and convenience of a cell phone (and the peripheral can be cheaper because it doesn’t need a screen, can have a weaker/cheaper computer etc)

>I have an Encryption question because I can’t find an answer to this, but it almost certainly has a name.
I know a one time pad is unbreakable. If both devices share the pad initially, can they include their message AND the next pad on their next transmission? Then each subsequent message has a new pad in it so as long as the initial one isn’t known it will remain unbreakable?

I don't know the name but I think I understand what you're asking for. Technically that would be possible but would require to define a protocol so that message and "pad" are separated. And also it would only work if two devices chat together continuously and if 1 packet is sent without the other device receiving it, it would break communication since the new packet with the new "pad" is lost. I think a way to handle this would be a fallback "pad" shared between the two devices, so whenever a message can't be deciphered the next message contains the fallback pad. But having a fallback pad would be also a security flaw.

>>2920681
That's CBC, cipher block chaining.
It was developed in the 60s and also forms the conceptual basis for "block chain"
Virtually all encryption uses (or should use) CBC mode as long as it's a block cipher, obviously.
It essentially makes the previous block the pad for the next block, whether you implanted material in the previous block (i.e. random bytes) to negotiate it or not.

> inb4 that's not the exact definition that chatgpt just gave me (making me an expert)
no, but I can mathematically prove they're equivalent.

>>2920688
>That's CBC, cipher block chaining.

I think we're mixing up two different concepts. CBC mode and OTP (one-time pad)

CBC mode = Block cipher mode of operation
One-Time Pad (OTP) = Stream cipher (encryption algorithm)

The data handling is:
bit/character-wise for OTP
and for CBC block-wise (128-bit for example)

If correctly used OTP is extremely secure unlike CBC.

The bottleneck for OTP is the fact that key size = data to encrypt size.

>>2920690
>key size = data to encrypt size
The OTP is a largely a theoretical construct used to compare strengths of various things.

> write a "C" program to generate 25 gigabyes of OTP
> burn it on to a blu-ray disc.
> send a man with a briefcase handcuffed to his wrist (and the blu ray disc locked to the inside of the case) to the destination. He will take back another blu ray disc to the source with the pad going in the other direction
> FBI decrypts everything trivially
> used rand() to generate the pad

>>2920681
>1 packet is sent without the other device receiving

So, this is recoverable, but the work factor is absolutely immense, and it assumes the decrypted data could even be easily distinguished from random data. This is why the original unix password algorithm was allowed to expose the hashes, it would be too much work to guess and test. Well, back in the day it was.
Anyway, (directed) searching back and forth through the 25 gigabyte is doable, but it's noteworthy you don't know what happened exactly. Data could be replaced, missing, etc.
Presumably the encrypted data had checksums or something. Thank god it's a block, though-- missing or substituted bytes in a stream cipher is seems like a bigger nightmare.

>The OTP is a largely a theoretical construct >used to compare strengths of various things.

[code]OneTimePad::OneTimePad() {}

std::string OneTimePad::xorBytes(const std::string& data, const std::string& key) {
if (data.size() != key.size()) {
throw std::invalid_argument("Data and key must be of equal length");
}
std::string result(data.size(), '\0');
for (std::size_t i = 0; i < data.size(); ++i) {
result[i] = data[i] ^ key[i];
}
return result;
}[/code]

I made a small library with a random key generator and xorBytes(). Also, I will read a bit more about "true" random number generation. Do you have any ideas how this can be achieved on a microcontroller? Temperature sensor, realtime clock module, or...?

>>2920854
> random
Cheap ones use a zener diode.
Also used for white noise generators.

>>2920854
sample them from nist pussy

>>2920891
>Cheap ones use a zener diode.
Thank you :)

>sample them from nist pussy
ok! did you write your own compiler?

>>2918442 (OP)
It might be cool at festival sites. There is usually bad internet, and you need something to chat/find your mates.

I decided to buy a RNG90-SSVDA-T chip for random number generation which supports I2C. It's ~0.50$ and FIPS 140-3 Compliant.

>It might be cool at festival sites. There is usually bad internet, and you need something to chat/find your mates.

Since I ordered from mouser, I also bought a Raspberry Zero 2W and I think I will also get a LoRa hat for the Zero. I could build a range extender or repeater which repeats the packets sent via LoRa (it listens for packets and whenever a packet is received, it will send the
same packet again). On the Pico LoRa devices I would have to implement some form of protocol that will disregard messages if duplicates are sent within a specific time frame.

>>2921132
> FIPS certified
Like that prng hasn’t been weakened such that .gov can’t predict future values based on previous values.

>>2921132
>>2920699
>>2920690
Thanks for the discussion and ideas.
I was thinking, with data storage so cheap, you could make a big table of rows of random numbers (like 1gb worth, with each row being 100 characters or something, and a row index that goes from 0 to a big number, and each device has a copy of the table. When A sends a secret message to b, it would include an unencrypted note like- starts at row 1, ends at row 9, or whatever, so that B can use that chunk of the table to decipher it. That way the message would use each part of the pad once (onetimepad) but not waste it, and messages can be arbitrary length (the pad for each message is as long as each message)

>>2921294
That is amazing. Thank you for the input. :3

I'm trying it.

>>2918448
Your gonna get vanned. Lmfao


Thanks for the info though jackass. Had the same idea for the cartel in Mexico. ;)

>>2918442 (OP)
I very much doubt that you use ECB and if you actually are, you should know that you're effectively sending plain text.

Today, I extended the project for OTP encoding/decoding and using a 1GB key dictionary that is stored on a microSD card. Unfortunately, the loggers I had were defective. (1 out of 2 worked)

Effectively I can test it in 2-3 days because I ordered some microSD loggers (SPI).

Basically it works like this:
<plaintext message> -> XOR with key from dictionary -> <ciphered message><separator><line number>

Decoding works vice versa.
It splits the message using the separator, then looks up the line number with key and then decodes using XOR.

>>2921622
> logger
Wat is means “logger” in this context.

>>2921622
Very cool that my idea was an inspiration.

I was looking at algorithms to generate pseudorandom numbers. Excel does it with a marsenne twister algorithm that repeats with a very long period. I bet competent code breakers have tons and tons of lists of =rand() from basically every programming language, then they can look at encrypted data to see if it’s one of the standard random number sets. Think of it like a dictionary attack but instead of guessing a password by using the common ones (password, hunter2, etc), its looking for ‘excel’s millionth =rand() after an initial seed’. I imagine some of the algorithms you’d use to do this have identifiable characteristics that can be found with fingerprinting algorithms (like those used in dna fragment analysis). This dataset would probably also have many versions of hash algorithms applied like excel’s Rand() + sha1, etc.
I wonder how much complexity/obscurity you could bring to a pseudorandom number set. Like a big mess of nested Rand functions: rand()*rand()/rand()+rand-rand()mod(rand(),rand()) etc

>>2921716
There is a group of people that want to ban rand() from the C language because of the possibility that it could be used to secure top secret information.
Luckily, this “outs” those people so we can fire them. Likewise, with things like gets()

Anyway, we’ve been using rand() for decades in testing, and the fact that the test run is deterministic and can be reproduced because it generates the same sequence when seeded identically, on separate runs.

>>2921661
>Wat is means “logger” in this context.
microSD card reader/writer. Sorry for the confusion.

>>2921716
>Very cool that my idea was an inspiration.

I'm glad it was an inspiration. :) As I mentioned before I ordered a microchip that is controllable via i2c. I think I will use this chip to generate a large dictionary. Currently, I used a standard random function to generate the dictionary. I will prepare one of my Raspberry Pico with a microSD card reader, write a small chunk of code that will generate the random chars using the microchip RNG90 and save it to a file on the microSD card that is connected to it. From there I will distribute the dictionary to my devices. :3 I also thought about applying a hash function to the dictionary to make it even more random.

>There is a group of people that want to ban rand() from the C language because of the possibility that it could be used to secure top secret information.

LMAO. :D

The microSD reader/write with the red rectangle is faulty. In a few hours I get a replacement, then I can test it.

>>2920891
I was under the impression that a reverse-biased BJT was easier than a zener for making random noise.

>>2921882
I've had problems with those before, solder a bigger bypass cap to the module itself (e.g. 10uF) to see if that fixes it because it worked for me. Or maybe it's fucking out because the chinks used an AMS1117 with MLCCs, when it's not specified to be stable with low-ESR caps. The datasheet recommends tantalum caps, though normal electrolytics would likely work fine too.

Furthermore, those modules probably won't work with a 3.3V supply voltage if you're still using the Pico. The 3.3V voltage regulator wouldn't be on properly with only 3.3V at its input. You can get around this by shorting together the 3.3V and 5V pads on the regulator, making it a voltage passthrough, and obsoleting the logic level shifter IC. Or you could just solder wires directly to a micro-SD to SD adapter (plus a bypass cap). It's just SPI.

>>2921986
I'm running the microSD module with voltage from the USB port (measured VBUS on Pico is >=~5v). As I said one of the two is working as expected (for some reason, they are from the same manufacturer...).

Good news: I got the RNG90 ICs delivered today. They're tiny :3
Bad news: I'm still waiting for delivery of the new microSD modules.

>>2921986
> reverse-biased BJT was easier than a zener for making random noise
I think the silicon physics on those two solutions is very similar, yeah. I’ve also heard about using LEDs.
With the zener diode, you generally want to go through a bunch of them and test for especially noisy ones.

>>2918442 (OP)
>128-bit ECB
hi, 2002 called, they want their crypto back

>>2921716
>>2921879
Wondering if you can secretly ‘regenerate’ the pad. Not sure how encryption and compression work together… a binary file full of random numbers can’t be meaningfully compressed I think. Maybe the pad could have encoded instructions like: make a new 100 character line at row #1000. The values will be the xor of rows 5 and 19. You wouldn’t want the instructions too formulaic because obvious reuse of a onetime pad makes it possible to crack, but I wonder what the threshold would be. XOR every 4th digit of pi against the inverse of the thousand digits of e. My intuition is that Interleaving several of these methods would probably make it just as good as the initial onetimepad

>>2922002
>I'm running the microSD module with voltage from the USB port
Then doesn't that mean you're feeding the 5V logic level shifted signal into a 3.3V Pi Pico?

>>2922139
It’s surprisingly easy to stymie nsa (or whomever) decryption efforts. They really don’t want people to even apply snd non-standard encoding (like, say, base 78 encoding) because to break it they’re trying keys and comparing it to plaintext (or, the directed form of that) and it’s computationally expensive to try and do that, since they have to try them all. Obviously, they’re a lot smarter about it than literal brute force, but it scales the problem a lot for an attacker. A non-standard compression is another way to make lives difficult for brute force attackers, you want the output to be binary and appear as random as possible.
If you’re testing it, every compression algorithm should make the encrypted output bigger, not smaller.

Guys, I made it! It works!! Finally :D

With the prepared source code, I just flashed and it worked.

Here's the result

>>2922106
>hi, 2002 called, they want their crypto back

The 1880s called and I believe they want their crypto back now :D
https://en.wikipedia.org/wiki/One-time_pad#History

>>2922139
>Wondering if you can secretly ‘regenerate’ the pad.

That would also introduce the problem of distribution. The receiver needs the dictionary to decipher.

>a binary file full of random numbers can’t be meaningfully compressed I think.
The file is not a binary, it's a text file containing random chars. I don't understand though which problem you want to have solved using compression.

>XOR every 4th digit of pi against the inverse of the thousand digits of e.
I think that could be a good idea. But I would need two separate files containing the numbers preprocessed.

>My intuition is that Interleaving several of these methods would probably make it just as good as the initial onetimepad

A non-biased opinion by a professional cryptographer would be nice. But I'm with you so far.

>>2922147
>Then doesn't that mean you're feeding the 5V logic level shifted signal into a 3.3V Pi Pico?
No? How? I'm using the VBUS pin on the Raspberry Pico which has the same voltage as the USB that is connected to the Pico.

>>2922207
Those are some good ideas. :)

>>2922219
By regenerate the pad I mean with the 1gb pad you’re kind of stuck with that size and once it’s used up your devices need to be resynced (or use a chained block cipher to regenerate, which needs a lot of bandwidth between devices, which might not be ideal if you want secret communications. 1gb transferred at a few baud would take a long time). What if some of the 1gb pad was actually instructions to build 1tb of pads (or whatever, just a big number, potentially infinite pads). In this way, you’d potentially never need the devices to sync again. They’d delete the used pad and generate new pad at the end of the file (the row count index keeps ticking up). Probably part of the protocol in messages would be for the device to tell the other one which message # it had received. Actually to keep the onetime pad from inadvertently being reused by both devices (if A uses rows 1-10 and B simultaneously does too) it makes the pad breakable. You’d probably have a prearranged delineation: A can use odd rows, B can use even or something like that.

>>2922371
Good idea. :) Noted.

I have some unexpected issues with the RNG90: https://www2.mouser.com/datasheet/2/268/RNG90_CryptoAuthentication_Data_Sheet_DS40002499-3235517.pdf

I get it to wake up but then it doesn't proceed with other things such as printing the info of the chip. :/ I also try to drain the 4 byte wakeup sequence. I will fix somehow but it will take longer I guess.

I fixed the issue. My RNG90-SSVDA-T microchip works now. I had an issue with my CRC method. :)

Later I will add the microSD reader as well for saving the random strings but for now I get random strings. :)

This is the (fragile) setup. :3

>>2922947
>This is the (fragile) setup. :3
I also attached a microSD card reader to it, to write the key dictionary to it. I had an issue around 1 million bytes where it stopped generating new strings.

Now, I implemented a short delay of 10 ms before it generates the string and writes to the SD card. Now it goes beyond 2 million bytes, I will let it running until it stops at 100 MB. I think giving it a bit time fixed the issue.

>>2924372
You shoud use a circular buffer, so it overwries the oldest stuff first.

So, when the FBI, Police, ICE, DoHS, DOGE, or the National Guard, Coast Guard, or IRS frontline combattents seize your device, they can read the last 100 MB of data.

I carry several suspicious looking devices with me at all times containing large binary blobs encrypted with 53 bit DES encryption.
When they’re done decrypting it, it’s a huge pepe image they will fee embarrassed by.