Bitcoin Forum
May 22, 2022, 08:45:12 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 »
1  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 19, 2021, 11:11:50 PM

You sound confused. More noise is more entropy. Less noise is less. You want as much noise as possible. You are trying to use "radio noise", but for somehow want less noise?

Let me clarify then; I said if only gets white noise, means if the receiver is so bad that isn't able to receive any broadcast at all. White noise is obviously welcome for entropy.

Update on the first attempt:

As I said this week I'll start trying around (time permitting), and for this first attempt I used a cheap analogical AM receiver. But the results were a disaster. I started to get a pattern, and it turns out the only thing the receiver was receiving was interference from the electronics around.
Will retry next week changing some stuff.
2  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 19, 2021, 01:22:28 AM
Do a search using "software defined radio modules" One good link that pops is https://blog.bliley.com/10-popular-software-defined-radios-sdr
#7 in that lineup looks good...

Thank you for the suggestion, yet SDR radios are both too expensive (can range up to hundreds of USD) and too good for the desired effect. For the intent the radio mustn't have good reception, the more interference the better, as long as it isn't just white noise, I don't actually want to be listening to whatever is said over radio waves.
So one of those inexpensive soap-shaped AM receivers that old men used for listen to football matches when I was a kid seams more appropriate. Turn the varicap around can be achieved either by a small stepper or servo.
I'll start drawing and testing around this week, to see what I can achieve with that setup.
3  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 18, 2021, 10:29:13 PM
My only input is that a FM radio receiver does not produce any audio signal if there is no rf signal. They work by finding a rf signal, locking onto it then responding to the frequency deviations of the signal to create an audio signal. You'll have the baseline thermal noise from semiconductors but that's it.

On the other hand, an AM receiver will pickup and amplify anything including natural radio emissions along with a plethora of man-made signals and would be the best choice to use.

Indeed, totally agree there.

FM seams to be unsuitable for the purpose, I'm currently looking into MW/SW/LW, the more promising to be MW and SW, LW never been quite used so the band is pretty much left to static. The issue is; I don't know any module as the FM module referred to work with those frequencies, but I'm thinking on using a stepper to tune around an analogical MW/SW receiver circuit.
4  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 17, 2021, 11:00:04 PM
1) I mean events that either because we don't yet know or are unpredictable on nature, doesn't allow anyone to predict or replicate the result.

i.e. if you seed your computer randomness at the current microtime, it may sound like the result will be unpredictable, but if I know the second it was generated, all I have is to generate 1000 keys with the same algorithm within that second. A hard task by hand, but an easy pick for any computer.

Usually for entropy (other unpredictable events) computers uses parts of the user interaction. Now let's say we add to the previous example the current position of your mouse pointer. Well, it can be at any point in the Cartesian plane represented by your screen resolution. So let's say it's 1920x1080, so now I've 1920*1080*1000, or 2,073,600,000 keys to generate, at 2 Mh/s this would take 1037 seconds, or ~17 minutes to brute force, if I take more points from the cursor, I'll get a number so big that would take millenniums to break, this is actually how Bitcoin is kept secure, it's possibilities are a number so huge that we would be long dead before generate a significant amount of the possible keys.

2) Mine isn't "more random" than yours, the question is, for you to have mouse moves, to have the memory contents changing, to have all the entropy elements a computer being used normally has, someone has to be operating it, otherwise it's pretty much dormant, so it's pseudo-randoms will be weak due to lack of entropy elements.
5  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 17, 2021, 08:16:23 PM
How about vibration sensor? Unless you push the button gently, the sensor should be able to pick small vibration.

I believe that would be interesting if you are near a road or railroad where trucks or trains may shake things around. Not the case, as the intended generator is a warehouse.


Quote
I saw some people creating random number generation with Geiger counters, using radioactive decay as an entropy source.
One guy Alex Waltz even went to extreme with his project and he combined Raspberry Pi, Geiger counter, Audio interface and Americium 241 from a Smoke Detector.... I think that plain old dices would be just fine  Smiley
https://twitter.com/raw_avocado/status/1433408813596545027

That's quite interesting too.


Updating: after checking some waves around, I'm now thinking on use AM or SW bands rather than FM.
6  Economy / Economics / Re: What will be the effects of China's central bank declaring all crypto illegal? on: October 15, 2021, 02:41:01 PM
Bitcoin thrives from the very beginning with bad publicity.
Everyday you get FUD from somewhere, ever since 2009. And at every step BTC has overcame it and became stronger.

So, who cares about China? They want to go back in time and rub sticks to start a fire? Let them go for it...
7  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 15, 2021, 01:32:11 PM
Thank you for your answers.
I'm of a philosophy that in cryptography no "secure is secure enough" and no level or paranoia or far fetched attack vector is too much. So your input was highly appreciated.

I strongly disagree with your instance about "external variables"; computers are precision machines, that's why they are unsuitable for generate true randoms on their own. Much of the entropy pools are user generated, or "external variables", such as mouse movements, keys entered, pixel color swaps and so on. All of them, if we ever manage to control quantum mechanics become pretty much predictable, but taken we don't they're pretty good.
Likewise radio waves are much unpredictable out of the quantum level. Yes, if a known song is being broadcast at the frequency the radio is listening, one second of such song = one chunk of the key, but entropy here is naturally given because it's highly unlikely that the radio will have perfect reception, a "crack" and "fizzz" will make a whole difference at the end result.
Also on the "attacker", there's one thing to take to account; one thing is to be physically attacked the other remotely, there're way more kids with VPN and TOR than James Bonds around. The attack vector is very physical, the attacker will have to be in a very short range of the receiver in order to overcome bad reception entropy. And don't forget that the system will pick a random frequency each time, the MCU RNG entropy pool will be keep changing as its memory contents change from the radiowaves being processed. Given enough running time (and it is never meant to stop, regardless if the contents are being used or not) it becomes more and more unpredictable.

One of the most basic electronic random generator is the electronic dice, it's a capacitor that will feed a 555 timer to a decade counter, the timer will oscillate accordingly to the charge at the capacitor, which is set by the amount of time a user is pressing a button, where a microsecond of charge will make a whole difference to the pulses generated and input voltage adds an entropy level. You can "cheat" this by creating a machine that presses the button a very accurate amount of time, thus controlling the capacitor charge and therefore the pulses, for sure, but if you go to use this to play Monopoly with a friend, I believe he will find pretty much strange that you bring your timer device along.
8  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 12, 2021, 11:40:10 PM
1 second in loop, not 1 second only.
1 second -> change frequency -> 1 second -> change frequency... at all time the data at the pointer is being append and changed accordingly.
Microphone and camera are pretty much useless, as the place is silent, buttons are just one and spool is erased after each print. No wifi is used and ESP doesn't start wifi unless told to, also an Arduino without Wifi shield can be used.

Let's assume for the sake of the example that the seed is 100 bytes long and each 1 second capture renders 10 bytes of data, so that just after ~10 seconds (+ i2c and code loop) the system is able to return a random.
init: 00 00 00 00 00 00 //init all bytes as 0x00.
loop1: AF DE 3E 21 21 89 39 40 FF FE 00 00 00 00... //one sequence, pattern detected (00 00 00...) -> invalid
loop2: EF EA A1 00 22 11 FA 2F 1A 3B AF DE 3E 21 21 89 39 40 FF FE 00 00 00... //two sequences, pattern detected (00 00 00...) -> invalid
... and so on until the buffer is filled up at loop10.
When the buffer if full, the next loop will remove the last 10 bytes and append the new ones at the beginning of the sequence, repeating this all the time.
9  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 12, 2021, 10:19:58 PM

I suppose it depends on what attack vectors you're trying to protect against and how vulnerable you'd be if a successful attack were performed, however, the two concerns that immediately come to mind are:

1.  If the radio stops working for some reason, you'll possibly be fed a repeating sequence that represents pure silence on all frequencies?

2. An attacker that is aware of your algorithm could potentially transmit a strong enough signal from close enough to your equipment to effectively overpower any "noise", resulting in a predictable set of input data.

First of, thank you for the valid and pertinent answer.
I hadn't think of #1, but I can add a response validation algorithm, either at the MCU or computer checking for patterns or repeated bytes.
As for #2, it has to be potent enough, has to "guess" when the print key would be pressed, as that the only time the random bytes are actually used, and it has to be a FM jammer, as the attacker has also to "guess" which frequency is being listen to and if or not shifted. Thus a jammer would probably render a pattern, throwing an error with the fix applied to #1 and having to running it in continuum, people around would start to complaint of bad radio reception.
10  Bitcoin / Development & Technical Discussion / Re: True Random for automatic offline address generator on: October 12, 2021, 06:47:21 PM
I would fart during the listen 1 second for the sake of randomness.



It doesn't listen anything on 16hz to 32khz, just between 88 and 108 Mhz, so your farts wouldn't add nothing to it.
11  Bitcoin / Development & Technical Discussion / True Random for automatic offline address generator on: October 12, 2021, 03:31:33 PM
For a BTC related project I need to create some addresses on automatic mode; the machine is offline, the machine prints both WiF Key and matching Address, there's minimal interaction for this, so it won't be able to pick much from its own memory in order to generate a good Random seed.
So my idea came about building a small piece of hardware using RDA5807M FM radio module under follow scheme:

Arduino/ESP(32/8266) --> gets/generates pseudo random between 880 ~ 1080, then divides by 10 -> i2c frequency set -> listen 1 second -> 2x 16 bit ADC (capture stereo output) -> sets bytes accordingly ---> repeat the process
At access: return x bytes stored, where x = amount of seed bytes.
RDA5807M is meant to be equipped with a weak or no antenna, in order to get not only music or whatever is being said at that frequency, but also get noise and interference.
A secondary pseudo random may set it to shift the frequency (+0.05 Mhz) or not.

Do you think this solution would provide a good enough Random generator? If not, what/how do you think this can be improved?
12  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 12, 2020, 01:28:44 AM
I'm not against automation, don't get me wrong, but the ultimate utility of automation and machinery is to serve humans somehow. We wouldn't be polluting the planet and crave for power sources just for fun.

What is interesting atm, is to discuss possible flaws and exploits, trim and cook the idea, eventually even weight it's pros and cons against other concurrent systems that may show up. But discussing about hypothetical software... What would be the point?

And death of someone is not to be taken lighten; the deceased could well blow his money on women and cars instead of save anything, but if he chose another path and his soul must have some way to rest in peace about the loved ones he left behind. So we must add some romantic and human vector to the whole system. Taken must of us, if not all, use strong passwords and/or strong security systems, way too complex sometimes, figure a way to open it when needed is far from an easy task or, like the widow of the Canadian exchange owner, crypto ends locked for good, practically dying with the owner.

Thank you for your offer.
13  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 12, 2020, 12:37:01 AM
Now your trust party is a batalion of people?

Let's put things a bit straight here; there're two opposite PoV in inheritances, the PoV of the heirs, who probably want the money ASAP, but that's their problem, and the person who actually gathered the wealth and eventually deceased. My system is towards the PoV of the former, not heirs, a more personal and human way to provide a last will, not some random characters and an automatic email with a weird key of sorts, which could land in some spam box.

If you have a better idea: develop and present it. But it turns kind of annoying to keep reading "I would send emails", "I would go with smart contracts", "I would use multi sig", "I would... whatever" -> Great! Do it!

A valid idea and valid discussion about this issue is on how to trim its usage, like AGD addressed and posed the issue.

Technology has the sole purpose of serving "rotting flesh", without humans all of Bitcoin, all of the electronic junk we created, would be rendered plain useless and worthless.
14  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 12, 2020, 12:03:47 AM
@Vod

How is that any easier?!

You type in the names and email addresses of your friends.   Done!

The key is automation, and avoiding rotting meat (the human memory lol)

So, what if your trusted third party get acquainted with one of the interested parties? Guess what... you'll "die early" and someone will be sharing your wealth while you entertain yourself finding a lawyer and engage the funny and long civil court processing.

To not mention that would be a plain money-grab...
15  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 11, 2020, 11:56:12 PM
@Vod

How is that any easier?!
16  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 11, 2020, 09:18:57 PM
Those are good questions indeed.
The informatics part is quite straight forward, it's just encrypt, encrypt, encrypt.
The human part however isn't that easy, and I believe there's no "one-size fits all" solution for it and my system isn't fail proof.

If one of the addressees dies shortly after you, the best shot would be to resource his closest relative (wife, husband, sons...). We have "layers of communication", there are things we say to family, but not to friends or strangers, others maybe to friends but not even to family.

For the custody, you could use a testament lawyer office, or you can intruct one of the addressees (preferentially not the #1) or a third party you trust, or you can leave it in a vault with a note on what to do next.

Yes, it's possible, however the other 2 already gave their answers, so they're already triggered by what's going on and would probably chase down or sue that last one.

EDIT:
One of the cases that inspired me to do this: https://www.newser.com/story/270824/crypto-investors-woe-widow-cant-open-founders-laptop.html
17  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 11, 2020, 01:28:27 PM
If Paul, Sue or John dies before being able to answering all 3 questions or one of them forgets only one answer, the remaining two will not be able to decrypt the file, am I right? Is there a way to let it work like a 2 of 3 multi sig?

If one party dies before you do, don't forget to redo your system. As no, there's no way to skip or create partial solvers.
About forgetting, they've all the tries they want to remember, will take them longer to solve.

The encryption system works like peeling an onion; each layer of encrypted text just uncovers the next layer of encrypted text.
18  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 10, 2020, 10:55:04 PM
@OgNasty

Yes, you can call it a sort of "Encryption for Dummies", it is intended for the easiest usage possible assuming one or several of the target parties couldn't be tech savvy.
IDK any already in place system for this purpose of "e-Testaments". As for memory loss, you will probably also forget you'd any crypto assets, so the custodian part can show up and tell you about your system and those you need to summon to help you out on regain access.
There's a lot of human side to this system, creating a good Q&A set is one of them.

@STT

You can combine it with a dead man's switch for sending the said email (but don't forget email services die as well, imagine you'd an @cjb.net; wouldn't be of much use now), just sending the msg.js (where the encrypted final text resides) and the other two files, the HTML and CryptoJS.js, as attachment.
But this shouldn't obviously be the "only option" or the "only path", just "another option" or "another way".
19  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 10, 2020, 06:43:14 PM
I think this is too complicated to ever work - but ideas are always great!

Take your idea and wrap it in an easy to use GUI with clear instructions in each automatic email sent out.

Your technical solution is not unique or difficult, but you need to sell it.  

Not trying to sell anything, it's GPL licensed, and it doesn't send any email or communicate anywhere at all.
But probably can be handy for lawyer offices that offers testament's custody services.
20  Bitcoin / Project Development / Re: Heritage/Insurance Encapsuled Encryption System on: December 10, 2020, 04:32:25 PM
Still don't see your point... it's like "hey, don't use RIPEMD160, use MD5 instead" or something alike. There's no technical advantage whatsoever in your solution, to the least both solutions can achieve the same, being your more unnecessarily complicated, unless space is a constraint (which isn't much these days, with regular entry levels USB pens to be up to several Gb).

I believe you're more thinking of the informatics part than the human part of the question. The human part requires that:

1. An human solvable and reasonably easy way to pose the questions (your heirs might not be nerds).
2. No previous advice of the existence of the system by the heirs (they might get greedy... we never know).
3. Enforce a way for all parties to cooperate, no threshold of partial parties (a few of them may conspirate to leave others out of the scene).
4. Personalize your message; it's your TESTAMENT, not some random hashed characters.
5. Also you might want those you love to remind you one last time, instead of doing a simple cash grab. By posing questions of your co-existence, you can be sure that will happen.

But you're free to present your system. Like at RAR, ACE, 7Z, ZIP and other compressing algorithmics, you don't see one of them to come over to say the other must do as he does, do you?

Still your system of Xor'ing the hashes with the question doesn't pose much difference than AES'ing it. But that would provide a way they might solve the questions individually and not as a group, forwarding their hashes through lawyers or so, unlike the intended way of this solution that forces them to be together or take a very long time by proxying it through representatives.
Pages: [1] 2 3 4 5 6 7 8 9 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!