Neat idea! I got inspired and went for a different approach based on reversing the hash function directly. This has some nice advantages like being able to use descriptive names and include the hash value in the name for reference. For example, you could set up serial addressing for hydroponics/harvies with names like: Tomato (1) [KQ]HVF]UP Harvie (1) [Y^VFCJL_E Tomato (2) [FJQFSKYAG Harvie (2) [TEZHFGHKR Soy (3) [F\^BG\JPY Harvie (3) [TEAXU[EN@ Surprisingly, reversing the CRC32 hash was the easy part. Making sure that what came out the other end consisted of printable characters was the tricky bit. Maybe I'll put a full writeup somewhere later.
Interesting video. I thought of something similar myself. Why not get rid of the "DEV" at the beginning of your device names? That might get rid of the holes in your rainbow table.
Counter intuitively, the contents of the data to be hashed, has very little organizational impact on the results of the hash, the solution will always be sudo random. Functionally, there is no difference between between the plain text "DEV12345" and "12345678", the algorithm treats alphas and numerics synonymously... I added DEV to give the dataset some context. CRC32 was never intended to be used as a cryptograph, but rather as an integrity check, so it was not optimized to minimize collisions, and as a result, has the worst redundancy rate... I'm not sure what the exact factor is, but wiki says there's a 50% chance of at least one repeat value in a hub of 77,163 results. This factor rises exponentially as the number of generated results rises linearly, meaning to generate a full hub of 4.28 billion, the maximum number of results for CRC32, I would need to generate trillions of hashes...
Neat idea! I got inspired and went for a different approach based on reversing the hash function directly. This has some nice advantages like being able to use descriptive names and include the hash value in the name for reference. For example, you could set up serial addressing for hydroponics/harvies with names like:
Tomato (1) [KQ]HVF]UP
Harvie (1) [Y^VFCJL_E
Tomato (2) [FJQFSKYAG
Harvie (2) [TEZHFGHKR
Soy (3) [F\^BG\JPY
Harvie (3) [TEAXU[EN@
Surprisingly, reversing the CRC32 hash was the easy part. Making sure that what came out the other end consisted of printable characters was the tricky bit. Maybe I'll put a full writeup somewhere later.
amazing work
Thank you
The longest consecutive sequence of numbers is 140 and starts at -1004190489 DEV306897424 Hf :)
very useful, ty! Here's that streak from hashes ...489 to ...629. The first column is that hash's offset from ...489:
0 -1004190489 DEV306897424
1 -1004190490 DEV832553671
2 -1004190491 DEV3318724099
3 -1004190492 DEV4179246105
4 -1004190493 DEV4910256795
5 -1004190494 DEV8302419959
6 -1004190495 DEV1733156754
7 -1004190496 DEV2246401617
8 -1004190497 DEV5236879940
9 -1004190498 DEV5816157504
10 -1004190499 DEV3340700486
11 -1004190500 DEV2989837037
12 -1004190501 DEV1426386844
13 -1004190502 DEV975858100
14 -1004190503 DEV6414251492
15 -1004190504 DEV2896518359
16 -1004190505 DEV1204330003
17 -1004190506 DEV2771667140
18 -1004190507 DEV5646714966
19 -1004190508 DEV6333243825
20 -1004190509 DEV4550661017
21 -1004190510 DEV7025336154
22 -1004190511 DEV1142801673
23 -1004190512 DEV3467712831
24 -1004190513 DEV9589526556
25 -1004190514 DEV8571771742
26 -1004190515 DEV6330312232
27 -1004190516 DEV5645645371
28 -1004190517 DEV6076823442
29 -1004190518 DEV8561851888
30 -1004190519 DEV2582255677
31 -1004190520 DEV7361238818
32 -1004190521 DEV1486301239
33 -1004190522 DEV4371786247
34 -1004190523 DEV9140616284
35 -1004190524 DEV2922175735
36 -1004190525 DEV2150780310
37 -1004190526 DEV356027753
38 -1004190527 DEV1762288108
39 -1004190528 DEV5173219527
40 -1004190529 DEV1250359577
41 -1004190530 DEV529302823
42 -1004190531 DEV1009547069
43 -1004190532 DEV7809701851
44 -1004190533 DEV4504608563
45 -1004190534 DEV5545802083
46 -1004190535 DEV1116868307
47 -1004190536 DEV3527391354
48 -1004190537 DEV3042378848
49 -1004190538 DEV4395848284
50 -1004190539 DEV8156924807
51 -1004190540 DEV1688427844
52 -1004190541 DEV1566705321
53 -1004190542 DEV1478144564
54 -1004190543 DEV4174965545
55 -1004190544 DEV8058045188
56 -1004190545 DEV4396919893
57 -1004190546 DEV4231305922
58 -1004190547 DEV3306276104
59 -1004190548 DEV1795337416
60 -1004190549 DEV2010303875
61 -1004190550 DEV1565654936
62 -1004190551 DEV5039431616
63 -1004190552 DEV5127270053
64 -1004190553 DEV1242646581
65 -1004190554 DEV434412471
66 -1004190555 DEV6270791957
67 -1004190556 DEV3587316929
68 -1004190557 DEV4419118931
69 -1004190558 DEV2691263058
70 -1004190559 DEV2574884642
71 -1004190560 DEV1115939910
72 -1004190561 DEV2671574698
73 -1004190562 DEV5410016704
74 -1004190563 DEV1058699635
75 -1004190564 DEV2439724967
76 -1004190565 DEV3631010653
77 -1004190566 DEV573919300
78 -1004190567 DEV4618722830
79 -1004190568 DEV2490459159
80 -1004190569 DEV971081703
81 -1004190570 DEV2049849941
82 -1004190571 DEV7451482771
83 -1004190572 DEV7554426381
84 -1004190573 DEV4956720217
85 -1004190574 DEV4848161452
86 -1004190575 DEV2211539974
87 -1004190576 DEV103674326
88 -1004190577 DEV8869071307
89 -1004190578 DEV8977630542
90 -1004190579 DEV2839483258
91 -1004190580 DEV7546139377
92 -1004190581 DEV2155437038
93 -1004190582 DEV4955671800
94 -1004190583 DEV100725931
95 -1004190584 DEV2212468363
96 -1004190585 DEV1880240039
97 -1004190586 DEV7080006801
98 -1004190587 DEV1051563476
99 -1004190588 DEV2524034535
100 -1004190589 DEV570848917
101 -1004190590 DEV1209813443
102 -1004190591 DEV4705032462
103 -1004190592 DEV4600096092
104 -1004190593 DEV5721348785
105 -1004190594 DEV3404884709
106 -1004190595 DEV2607675542
107 -1004190596 DEV1372322401
108 -1004190597 DEV6864011548
109 -1004190598 DEV1034813271
110 -1004190599 DEV3647311589
111 -1004190600 DEV4426673415
112 -1004190601 DEV2277918564
113 -1004190602 DEV2857036920
114 -1004190603 DEV4886553557
115 -1004190604 DEV4998312312
116 -1004190605 DEV4526548
117 -1004190606 DEV5109155796
118 -1004190607 DEV2131229314
119 -1004190608 DEV223164946
120 -1004190609 DEV2854167337
121 -1004190610 DEV9036604686
122 -1004190611 DEV2085644778
123 -1004190612 DEV6722887807
124 -1004190613 DEV3225963559
125 -1004190614 DEV7599145893
126 -1004190615 DEV220035351
127 -1004190616 DEV2026792712
128 -1004190617 DEV5733657773
129 -1004190618 DEV6246300630
130 -1004190619 DEV1265699007
131 -1004190620 DEV408228342
132 -1004190621 DEV1037942866
133 -1004190622 DEV3512651624
134 -1004190623 DEV1950033779
135 -1004190624 DEV1855097389
136 -1004190625 DEV4696480588
137 -1004190626 DEV4793424178
138 -1004190627 DEV5426487863
139 -1004190628 DEV4568882127
140 -1004190629 DEV6897977655
now this is next-level. thanks for going through so much effort for this!
Interesting video. I thought of something similar myself. Why not get rid of the "DEV" at the beginning of your device names? That might get rid of the holes in your rainbow table.
Counter intuitively, the contents of the data to be hashed, has very little organizational impact on the results of the hash, the solution will always be sudo random. Functionally, there is no difference between between the plain text "DEV12345" and "12345678", the algorithm treats alphas and numerics synonymously... I added DEV to give the dataset some context. CRC32 was never intended to be used as a cryptograph, but rather as an integrity check, so it was not optimized to minimize collisions, and as a result, has the worst redundancy rate... I'm not sure what the exact factor is, but wiki says there's a 50% chance of at least one repeat value in a hub of 77,163 results. This factor rises exponentially as the number of generated results rises linearly, meaning to generate a full hub of 4.28 billion, the maximum number of results for CRC32, I would need to generate trillions of hashes...
Why are you wasting cable connections? Why don't you cable it like so that you use all 4 connections on one intersection.
It's just a test and demonstration?