Wireless home automation 100+ meters range encrypted network AC mains switches - Page 1
Forum section: electronics / projects

author: eneuro
author_rank: Super Contributor
timestamp: August 06, 2015, 07:59:31 pm
content: Hello,This idea was born some time ago and of course I'm rather big fan of Tesla RF wireless communication than "internet of things", so I prefere pure wireless low range (around 100 meters) radio communication, than internet, since i think HTTPS internet encryption in the era of future quantum computers will be soon only illusion of secure commnication and we need pure TRNG data exchanged on internal home network devices from time to time to be able have one-time pad TRNG keyFirst wireless home automation target will be inteligent wall switch with wireless RF communication and TRNG encrypted transmision to send secure commands to small AC mains switches with builting MPUs and RTCs as well as probably one time passwords based on TRNG data created by those devices itself in their lifespan while waking up from idle mode from time to time to check local RF transmisions in the air.There is some simple yet powerfull theory behind this and I've made decent TRNG some time ego based on tiny MPUs with hardrware TRNG support.Why must we use XOR?https://www.khanacademy.org/computing/computer-science/cryptography/ciphers/a/xor-and-the-one-time-padXOR cipherhttps://en.wikipedia.org/wiki/XOR_cipherIf the key is random and is at least as long as the message, the XOR cipher is much more secure than when there is key repetition within a message. When the keystream is generated by a pseudo-random number generator, the result is a stream cipher.With a key that is truly random, the result is a one-time pad, which is unbreakable even in theory.I've already developed and sucessfully tested a few PCB modules for this automation project and I will try to make fusion of those modules to have custom network of AC mains low speed switches controlled by very tiny amount of charge obtained using different energy harversting methods (including sound, but not ultrasoundenergy transfers) available in environment and of course small tiny PV panels to charge ultracapacitors, but it will depend on application.Waiting now for a few 500V N-channel mosfets to test DC/AC mains switch RF receiver and redesigning this shown on photos above quite universal wall switch to implement inside PCB with low power consumption wireless RF transmiter, MPU, RTC, etc to be able support two switch version of this quite standard wall switch-one switch version on images above, but its teardown showed that it is capable to put two switches instead of one, while its mechanical design was made to support this and two switch versions of the same wall switch "footprint" exists

author: Kjelt
author_rank: Super Contributor
timestamp: August 06, 2015, 09:01:53 pm
content: I guess you didn't study well enough, there are quite a few issues I do not even know where to begin.1) there are already post-quantum secure algorythms and more being developed.2) an OTP is absolute secure if and only if that OTP is generated from a pure RNG source and distributed to both parties after creation in total.If you use a PRNG or any other algorithm that generates the OTP data from a RNG basis than per definition you are not using OTP and have a very weak system. The state of the PRNG and the algorithm behind the PRNG is then your key and weak crypto system.Besides, what happens if your PRNG overflows, you are generating the same OTP data again and again.

author: eneuro
author_rank: Super Contributor
timestamp: August 06, 2015, 09:12:47 pm
content: Quote from: Kjelt on August 06, 2015, 09:01:53 pmCould you quote, please, where in my first post I'm talking about using myself PRNG?Forget about PRNG-random key data is based on TRNG in my system, so very hard to find anything in RF noise in air or make "man in the middle" kind of attack to switch something using own RF source

author: Kjelt
author_rank: Super Contributor
timestamp: August 06, 2015, 09:24:57 pm
content: So you distribute the entire otp for the entire lifetime of the system at design time?Perhaps if you share more details we can think with you on this for now it is hard to see if its valuable or jibberish.

author: helius
author_rank: Super Contributor
timestamp: August 06, 2015, 10:03:41 pm
content: "one time pad" being seriously suggested for a crypto product is such a reliable indicator of cluelessness.could you explain again how your "TRNG generated OTP" becomes a public key algo?only DH/RSA are seriously impacted by quantum computing. known symmetric ciphers are not a problem.

author: lewis
author_rank: Frequent Contributor
timestamp: August 06, 2015, 10:50:43 pm
content: The one time pad thing reminds me of a passing thought I had regardingnumbers stations. The idea that a message can be literally broadcast all over the world, in such a simple manner, and yet remain crytographically unbreakable, is something I find rather appealing.

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 07:43:42 am
content: In the case of 32bit On/Off AC mains switches IDs comunication of randomly send On/Off commands vis RF in simulation could be as simple as it is using TRNG and XOR cipher for encryption:Code:unsigned long i, n= 10;// Assign pseudorandom (or TRNG) on/off IDson= rng32bit();off= rng32bit();for(i=0;i<n; i++ ) {enc= trng32bit(t); // TRNGonenc= on^enc;offenc= off^enc;// random on/offfprintf(stderr,"%s: Sending: ", argv );// Pseudo random On/Off messageif((rng32bit()&1)==1 ) {// Onfprintf(stderr," on: 0x%08X on_enc: 0x%08X (%s) enc: 0x%08X\n", on, onenc, bits(onenc,32), enc );} else {// Offfprintf(stderr,"off: 0x%08X off_enc: 0x%08X (%s) enc: 0x%08X\n", off, offenc, bits(offenc,32), enc );} // if} // forSample output off 10 random on/off commands to see that it works and what will be seen in the air on given RF frequency:Code:./crypto_test: Sending: on: 0x752115C8 on_enc: 0x6270F7B2 (01100010011100001111011110110010) enc: 0x1751E27A./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x21950150 (00100001100101010000000101010000) enc: 0x40293A4F./crypto_test: Sending: on: 0x752115C8 on_enc: 0x35EA92F3 (00110101111010101001001011110011) enc: 0x40CB873B./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x3C80E29F (00111100100000001110001010011111) enc: 0x5D3CD980./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x16E75F43 (00010110111001110101111101000011) enc: 0x775B645C./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x759569F5 (01110101100101010110100111110101) enc: 0x142952EA./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x3EE0D2BF (00111110111000001101001010111111) enc: 0x5F5CE9A0./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x28452D2D (00101000010001010010110100101101) enc: 0x49F91632./crypto_test: Sending: on: 0x752115C8 on_enc: 0x5C07705E (01011100000001110111000001011110) enc: 0x29266596./crypto_test: Sending: on: 0x752115C8 on_enc: 0x4E2E659D (01001110001011100110010110011101) enc: 0x3B0F7055When we try decode those first two on/off commands we of course get proper on/off IDs:Code:./crypto_test: Sending: on: 0x752115C8 on_enc: 0x6270F7B2 (01100010011100001111011110110010) enc: 0x1751E27Adecrypt: 1751e27a xor 6270f7b2 = 752115C8 (open garage doors 1965102536 dec)Code:./crypto_test: Sending: off: 0x61BC3B1F off_enc: 0x21950150 (00100001100101010000000101010000) enc: 0x40293A4Fdecrypt: 40293A4F xor 21950150 = 61BC3B1F (close garage doors 1639725855 dec)So, we assigned in this example for ON/OFF garage doors 32bit IDs:Open garage doors ID: 1965102536 (0x752115C8)Close garage doors ID: 1639725855 (0x61BC3B1F)Of course I can't reveal details of protocol used, since it can be different depending on application, but idea of encrypting comunication messages using TRNG key as long as encrypted bits and using simply XOR cipher remains the same

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 08:17:38 am
content: Let us assume that attacker tries within 24 hours use brute force to switch on/off something (eg. garage doors) than in the case of 64bit (8 bytes) messages (32bit for source ID and 32bit for destination ID), while those 64bits are encrypted a, so he had to jam RF in local area at speed:2^64 / (24 hours *3600s ) tries per second which is equal to: 18446744073709551616÷24÷3600 = 213503982334601 per second and of course it is beyond RF frequency and receiver switch MPU speedIf attacker knows proper sender 32bit IDs, still it is 49710 attempts per second, but changing IDs bits length to 64bits (128bits per message) again mission imposible for attacker to brute force this simple design within his entire lifespanIf he wanted do it within 100 years using brute force it had to do it at speed: 5849424173 per secondUpdate: Yep, probably I've made mistake there in the case attacker knows sender ID (there will be NOT 49710 attempts per second but as shown above >2*10^14) and forgot that still this known sender ID is encrypted, so it doesn't help when we encrypt both sender and receiver IDs, so attacker still have to guess proper 64bits to be able perform any action on target (destination) device, so knowing sender ID doesn't help.

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2015, 08:23:52 am
content: you still do not answer the question, where does the OTP data come from:1) is it distributed at start2) are you calculating it somehow.First is good but takes MB's to GB's for lifetime of a product and you need a moving window if some messages are not received (and the sender goes forth in the OTP table )Second is bad and can be hacked.Look at how pro companies do their RF control communications: use a symmetric cipher with PSK and rolling codes (increasing sequencenrs in the message so you can miss commands inside the window).The whole code you post is crypto 101 bullshit a 10yr old knows that OTP xoring works. The issue is where does the OTP data come from and that is where you don't want to answer, giving me an indication that it is unsecure obfuscation you are using. Oh well who gives a *&^* noone wants to hack your system anyway if there is not a lot of $$$ to gain, i can spent my time better than this. Good luck on your project.

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 08:57:57 am
content: Quote from: Kjelt on August 07, 2015, 08:23:52 amSo, show us and hack this communication and tell us on/off IDs-you have 1000 IDs send over air and... there is a hint:there are only two on/off IDs and of course they are different than shown in example aboveCode:./crypto_test: Sending: on: 0x00000000 on_enc: 0x7093E3C4 (01110000100100111110001111000100) enc: 0x00000000./crypto_test: Sending: on: 0x00000000 on_enc: 0x2BE8576C (00101011111010000101011101101100) enc: 0x00000000./crypto_test: Sending: off: 0x00000000 off_enc: 0x7AD29968 (01111010110100101001100101101000) enc: 0x00000000./crypto_test: Sending: off: 0x00000000 off_enc: 0x568504B3 (01010110100001010000010010110011) enc: 0x00000000./crypto_test: Sending: off: 0x00000000 off_enc: 0x53212154 (01010011001000010010000101010100) enc: 0x00000000./crypto_test: Sending: on: 0x00000000 on_enc: 0x27360A1C (00100111001101100000101000011100) enc: 0x00000000./crypto_test: Sending: on: 0x00000000 on_enc: 0x3CC02F57 (00111100110000000010111101010111) enc: 0x00000000./crypto_test: Sending: off: 0x00000000 off_enc: 0x3F3F1B16 (00111111001111110001101100010110) enc: 0x00000000./crypto_test: Sending: on: 0x00000000 on_enc: 0x1E917513 (00011110100100010111010100010011) enc: 0x00000000Attached sample 1000 random on/off IDs send over airWhen we close/open garage doors w few times a day this is possible amount of RF transmission to controll eg. garage doors, so if someone wanted to try sniff this he could record during the year similar estimated amount of "sample" RF comunication at garage doors.crypto_test_RF_air.txt.zipAnyway, in real home automation environment will be more than two IDs send over air including from neighbour who might also want use similar switch, so this will make life even more difficult if someone wanted sniff radio communication to identify sender/receiver IDs to reveal used keys which switch software understands

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2015, 09:13:24 am
content: Again let me put it simpler , and first answer the question of the basis of your system:you have a transmitter using a claimed TRNG, you XOR the CommandData with the outcome of this TRNG and sent it over to a receiver. Fine.Now how does the receiver generate the same outcome you're TRNG on the transmitterside did or else you can not get the original message back?If you have a manner where you can synchronize the TRNGs so they produce the same outcome then per definition they are not TRNG's but synchronised statemachines aka PRNGs.The definition of a TRNG is that you can not predict the next generated number, this per definition means that two TRNGs can never ever produce the same outcome or they are no TRNG.

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2015, 09:23:30 am
content: Send the data as unencrypted binary packet. Along with the payload data, the packet contains also a 32-bit running counter which will be incremented by one for each transmitted data packet. Then, sign the binary packet using SHA-256 using the secret password as the seed. Now, the reciver is able to verify the sender and the reciver will also be able to discard any erronous or fake packets. The running counter will prevent the eavesdropper from re-sending the packets as any packet which contains packet counter value less than the last known good packet is discarded. For cosmetics, you could encrypt the packet.

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 01:42:52 pm
content: Quote from: Kjelt on August 07, 2015, 09:13:24 amIt is not possible synchronize TRNGs and it is not neededhttps://en.wikipedia.org/wiki/Quantum_key_distributionQuantum key distribution is only used to produce and distribute a key, not to transmit any message data. This key can then be usedwith any chosen encryption algorithm to encrypt (and decrypt) a message, whichcan then be transmitted over a standard communication channel.This above is best description of idea of using TRNG (true random number generator).

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 01:56:42 pm
content: Quote from: Kalvin on August 07, 2015, 09:23:30 amSometimes a few lines of pseudocode eg. in C language are easier to understandYep, preventing the eavesdropper from re-sending the packets might be critical in some security applications and it is another story.However, resending eg. open doors packet again a few times within defined period of time in which end user knows that can happen is not an issue, since when he locks the doors, different key will be used for another period of time (window), so when someone will try lets say a few minutes later open the doors using sniffed RF code (which had to be closed) it will be rejected (or marked as security threat event) since those old packet keys will be no longer valid, so simply receiver will not perform open the doors action -it will be ignored and optionally alert condition set, etc

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2015, 02:28:16 pm
content: Quote from: eneuro on August 07, 2015, 01:56:42 pmSomething like this. The sender will increment the payload.message_counter for each message to be sent, so there will be 2^32 different messages before the counter wraps around. If that is a problem, one can use uint64 instead of uint32 or some kind of simple windowing. This system allows the sender to send the packet multiple times if the radio link is bad, but only the first valid packet received will trigger action. Other packets with the same message_counter value will be discarded.typedef struct{typedef struct {... other payload stuffuint32_t message_counter;} payload;sha256_t signature;} message_t;message_t message;...get_message(&message);if (valid_packet(message)){/* Message is valid, but check also that it is not retransmitted */uint32_t last_message_counter;read_from_storage(&last_message_counter);if (message.payload.message_counter > last_message_counter){/* We have a valid message */last_message_counter = message.payload.message_counter;write_to_storage(last_message_counter);handle_message(message);}else{/* The sent message counter is invalid, so discard the message */}}else{/* Received corrupted or fake message */}...

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 04:50:06 pm
content: Quote from: Kalvin on August 07, 2015, 02:28:16 pmThanks for this detailed pseudocode-it explains everythingI've tested a few versions of MD5 on tiny 8 bit MPU like ATTiny85 with 8KB of program flash and it takes as I remember 1KB-2KB of not optimized code to compute MD5-SHA256 is probably even more demanding in program flash storage, I guess?Probably it might work and in applications where additional security needed by adding TRNG based keys encryption we could achieve decent cryptography levels.BTW: In some applications like mentioned garage open/close switch those TRNG keys generated in spare time on master/slave MPUs could be exchanged easy not by sending over air by radio (RF), but... using light and very close by direct optical contact like fiber optics, etc, authenticated by remaining valid TRNG keys, so there is no chance that 3rd party will be able catch those TRNG bits via RFI wonder what orders of magnitude could be advantage of using SHA256 vs MD5 in the terms of computational cost on mentioned 8 bit AVR MPU running at 1MHz, while lower power consumption could be advantage to save battery life on those tiny MPUs ?

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2015, 05:05:47 pm
content: OMGYou say you don,t need to sync the TRNGs but than come up with a quantum scheme that does need synchronisation, and you then even admit it.So you,re secure wireless system depends on a quantum state synchronisation by optical fibre. Brilliant, not. What is the point of a wireless sustem then?And you don,t even recognize a simple symmetric authenticated (optional encrypted) protocol as Kalvin post but you needpseudocode.Well that says enough. You really have no clue what you are doing. It certainly has nothing to do with a TRNG.

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2015, 05:09:17 pm
content: Quote from: eneuro on August 07, 2015, 04:50:06 pmI just used the SHA256 as an example. If your security is less demanding, you could use something less secure and less computationally intensive hash function to sign the data packets.Some hash functions for AVR:http://perso.uclouvain.be/fstandae/source_codes/hash_atmel/

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 06:56:46 pm
content: Quote from: Kalvin on August 07, 2015, 05:09:17 pmIt could be nice have SHA256 implemented in this tiny MPUIt looks like one of those from your link:http://perso.uclouvain.be/fstandae/source_codes/hash_atmel/source/SHA256.asmmight be worth to try; Description: SHA256 hash functio (standard); Version 1 - July 2012.;; IMPORTANT NOTES;; (1) THIS CODE HAS BEENOPTIMIZED FOR; MEMORY AND REGISTER ALLOCATION. PLEASE MAKE SURE THAT; THE ALLOCATION FITS YOUR DEVICE BY CHOOSING THE; CORRECT BASE MEMORY LAYOUT. PLEASE CHECK OUT THE;OPTIONS  AND  TO SELECT ATXMEGA, ATMEGA OR ATTINY; DEVICES APPROPRIATELYEspecially, while it is only ~1KB of flash program code and estimated ~34ms @ 1MHz AVR MPU hash of 8 byte message (64bits) and less that two times more for 128bit-256bit message which could be fine for low speed switchesI'll try compile this version of SHA256 AVR and hash something on ATTiny85 to see how it worksUpdate: Yep, now noticed this (*) on benchmark tests page, so probably it shouldn't be any problems to run this code on ATTiny85Quote

author: nctnico
author_rank: Super Contributor
timestamp: August 07, 2015, 07:11:32 pm
content: AFAIK SHA256, SHA-1, MD5 have been broken a long time ago. I wouldn't base a new product on such hashing algorithms. The error you are making is to try and use antiquated microcontrollers. Look at using an ARM based controller so you have the processing power to implement meaningfull security.

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2015, 07:13:59 pm
content: No SHA-1 is not recommended anymore, SHA-2 family where SHA-256 is a member of is still NIST recommended.

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 07:28:15 pm
content: Quote from: Kjelt on August 07, 2015, 07:13:59 pmYep, that is why I'm interested in SHA-256http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.htmlQuoteI'm not sure why they still mention SHA-1 there, but it doesn't matter since I want use SHA-256.There are some detailed examples of hashing with SHA-256 internal structures, etc, which might be helpfull during testing on AVR MPUhttp://csrc.nist.gov/groups/ST/toolkit/documents/Examples/SHA256.pdf

author: jezsmith41
author_rank: Contributor
timestamp: August 07, 2015, 07:48:54 pm
content: The crypto algorithm the op is talking about may well be crap and I suspect that it is, but it does raise the real problem with home automation using bluetooth, the way Bluetooth works means its easy to sniff key pairs for each session thereby adding more security concerns for IoT products.If someone can solve that particular problem its worth far more than this projectSent from my Xoom using Tapatalk

author: jezsmith41
author_rank: Contributor
timestamp: August 07, 2015, 07:50:34 pm
content: By the way, nobody is going to take this product seriously because it cunningly avoids so many home automation standards its not funnySent from my Xoom using Tapatalk

author: nctnico
author_rank: Super Contributor
timestamp: August 07, 2015, 08:05:28 pm
content: Well.. I'm not aware of any secure home automation standard so a truly secure system would be something new.

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2015, 08:52:25 pm
content: Disclaimer: I am not an expert in cryptography, so please use this at your own risk.A simple XOR-based encryption could be implemented as follows using a PRBS (pseudo-random byte stream).Note: This may not be cryptographically secure enough for your purposes, but if will provide at least cosmetic encryption. Please consider using well-known, proven industry standard algorithms if you need robust encryption.typedef struct{typedef struct {... other payload stuffuint32_t message_counter;} payload;sha256_t signature;} message_t;secret1 = key used for signing the message's payload.secret2 = key used for seeding the PRBS.Sender:1. Compute the signature = SHA256(secret1, payload).2. Seed the PRBS generator with SHA256(secret2, signature).3. XOR the payload using the byte stream from the PRBS.4. Send the message.Receiver:1. Get the message.2. Seed the PRBS generator with SHA256(secret2, signature).3. XOR the payload using the byte stream from the PRBS.4. Verify that SHA256(secret1, payload) equals to the signature.5. Process the message.Hopefully I didn't miss anything important. Like security.

author: nctnico
author_rank: Super Contributor
timestamp: August 07, 2015, 09:18:04 pm
content: Actually encryption is only a component of security. You can't make a secure system based on encryption alone. Think about someone recording and replaying messages.

author: Kalvin
author_rank: Super Contributor
timestamp: August 07, 2015, 09:23:28 pm
content: Quote from: nctnico on August 07, 2015, 09:18:04 pmif you see my previous messagehttps://www.eevblog.com/forum/projects/wireless-home-automation-100-meters-range-encrypted-network-ac-mains-switches/msg726106/#msg726106there is a message_counter field in the payload which will prevent recording and replaying.

author: Kjelt
author_rank: Super Contributor
timestamp: August 07, 2015, 09:42:29 pm
content: Could be done that way but makes not much sense.For this kind of small protocols and wanting authenticated encryption I likeAES-CCMbetter with the AES-128 cipher.You can run it on a 8bit microcontroller if needed. Just make sure you code the protocol exactly asNISTdescribes it. Or better "lent" it from a proven open source software library.

author: eneuro
author_rank: Super Contributor
timestamp: August 07, 2015, 10:40:32 pm
content: Quote from: Kalvin on August 07, 2015, 08:52:25 pmI'm still before this step, since... I had to change this AVR Studio.asmsource code to.Ssupported bygcc-avrand I've already linked this converted to GNU asm (.S) SHA256 code, but I'm not sure if it will workHopefully, I've found thereComparison of GCC assembler vs Atmel AVR assemblerbasic gudelines howto convert AVR Studio .asm to GNU asm .S, but still some work to do, to be able test thishttp://perso.uclouvain.be/fstandae/source_codes/hash_atmel/source/SHA256.asmcodeUpdate:Nope, I have to convert ATMEL ASM macros since avr-as report it as error:Code:sha256_avr.S: Assembler messages:sha256_avr.S:171: Error: unexpected end of file in macro `rotate_bit_to_left_32' definitionThis bloody .asm macro is a problem for the moment and need to be converted to GCC assembler .SCode:; MACRO: ROTATE A 32 BIT WORD TO LEFT BY ONE BIT; INPUT: @0-@3; DESTROYS: TEMP_REG; OUTPUT: @0-@3.MACRO ROTATE_BIT_TO_LEFT_32MOV TEMP_REG, @3ROL TEMP_REGROL @0ROL @1ROL @2ROL @3.ENDMACRO

author: lapm
author_rank: Frequent Contributor
timestamp: August 08, 2015, 07:25:38 am
content: Somehow im thinking, ok hes system might be secure enough to use, but if im not interested in bruteforce hacking into it, i just jam it with random bit transmissions in same frequency and make fellow actually using system run around trying to debug.. If this persist long enough, most people start ripping their own system apart, disable encryption, try wired connections, etc...The human is always easiest to attack when trying to gain access to somewhere...

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 08:21:20 am
content: Quote from: lapm on August 08, 2015, 07:25:38 amRather simply way to determine if sender/receiver are jammed-put them side by side (but with decent spacing depending on RF frequency used) inside metal cage and see if they are working in this more controlled environmenthttps://en.wikipedia.org/wiki/Faraday_cageTo a large degree, though, they shield the interior from external electromagnetic radiation if the conductor is thick enough and any holes are significantly smaller than the wavelength of the radiation.So, if this thing works inside safe lock, but very often it is not working outside, easy call to call local "ghost buster" to see what happends on RF spectrum analyzer

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 08:51:00 am
content: Quote from: Kjelt on August 07, 2015, 09:42:29 pmI'd like to have SHA-256 code, while it can be used at MPU startup to verify device flash program code for any errors, so it can help prevent running corupted MPU code, eg. due to eaging processes or other flash memory failuresIn this quite nice introduction to one--way authentication methodsAtmel AVR232: Authentication Using SHA-256they says:QuoteThey also mention tips howto defend against powerline analysis methods and make reading secret key from device harder, by keeping it in volatile RAM instead of non-volatile flash, etcQuoteDifferent HMAC papers will also can help design this system even more secure depending on requirements:Message authentication using hash functions the HMAC constructionKeying_hash_functions_for_message_authenticationIn practice limited frequency at which eavesdropper can observe exchanged data via RF additionally limits possibility for finding hash collision and probably SHA-256 hash is overkill with 256bits (32 bytes) in many applications of home automation where this switch will be used, but that is fine since its code size on AVR MPU is at the range of 1KB-2KB (small) and I need verify MPU flash program integrity to ensure good code is running, so its is worth to use it also in authentication.I've already successfully linked another SHA256 gcc assembler implementation and compiled for ATTiny85 (2KB of code-not so bad), so can now make some benchmarks and in spare time convert macros from ATMEL AVR assembler to GNU avr-as of this nice SHA256 implementation linked by @Kalvin , since still I'm strugling with error codes in those bloody AVR studio macros converted myself to GCC avr-asIt is not a big deal now, but it could be nice save 1KB of code and maybe this implementation has better performance, so we'll see if I will be able find a way to recompile smaller SHA256.asm implementation using GCC avr-as

author: Kjelt
author_rank: Super Contributor
timestamp: August 08, 2015, 09:49:54 am
content: Quote from: eneuro on August 08, 2015, 08:51:00 am

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 10:37:17 am
content: Quote from: Kjelt on August 08, 2015, 09:49:54 amCIAThis what I need for authentication is mentioned and linked HMAC, where in applications where it will not be a concern that (eg. open/close command) will be in clear text in HMAC message NO encyption needed to authenticate.When message text need to be encrypted using shared decent amount of TRNG bits and lest say put in clear text index from which take those random bits at the length of the encrypted bits send at the rest of the message, to decode on reveiver side just by looking into the same copy of TRNG data at index given in clear form in HMAC text part of the message, will allow use XOR cipher to encode/decode and no AES or other ciphers needed-depending on how much data need t be encrypted, how often, etc.It doesn't matter if we have acces to lets say 1GB of precomputed TRNG random bits shared eg. on SD card, this way we can with extremely high security exchange 1GB of data using even simple XOR cipher, since there is theory behind this and this is what I'm talking about from the begining in this thread.No need t use AES to encrypt/decrypt something when we have decent amount (equal to exchanged data bits) of TRNG bits which are known ONLY to two parties, since they exchanged those TRNG keys before starting communicate using XOR cipher

author: Kalvin
author_rank: Super Contributor
timestamp: August 08, 2015, 11:46:33 am
content: An industry-standard block-cipher would be a good solution. As the OP is using Attiny85, I suggested simple XOR-ciphering seeded with a seed derived from SHA256(secret2, signature), which should provide quite good cosmetic encryption and requires only little Flash, RAM and CPU overhead. How strong this encryption is I cannot give any estimate. That's why it would be a good idea to use proven industry-standard ciphering algorithms.For a simple garage door opener this XOR-cipher should be good enough, as there are very few security implications if an outsider can decipher the payload and detect whether you are opening or closing the garage door.For some other applications the security and/or privacy is more of concern. For example, activating and deactivating surveillance monitoring systems needs to have high level of security and confidentiality in order to prevent the outsiders from monitoring what is going on. In applications like these the payload confidentiality must be taken into a careful consideration in addition to data integrity and authentication.

author: Kjelt
author_rank: Super Contributor
timestamp: August 08, 2015, 11:52:06 am
content: You keep on insisting on your TRNG but that needs synchronisation, the suggested way of doing it just needs 1 secret of 16 bytes a so called PSK (pre shared key). If you don't want to use the PSK for encryption directly you can derive a key (from the PSK) in your own protocol. You can even create temporary keys between two parties aka session keys this way and since they are temporary and short lived brute force attack has no chance.There is so much you can learn about security.Anyway I am off for a well deserved holiday the next weeks so some advice: do the free CryptoI course from coursera from Dan Boneh to get a better feeling of what it is all about. You can skip the advanced mathematics if you have problems with it but get a better feeling of symmetric keys and the ways they are attacked.

author: Kalvin
author_rank: Super Contributor
timestamp: August 08, 2015, 12:11:01 pm
content: Atmel has also MCU variants that contain built-in security features. If the Attiny85 doesn't provide enough Flash, RAM or MIPS, it would be a better solution to upgrade the MCU instead of compromising the security.

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 12:16:23 pm
content: Quote from: Kjelt on August 08, 2015, 11:52:06 amThis is no need brake open doors and I suggest you read first those papers I've linked about HMAC (adopted in SSL and s-https) and thisPDF: NIST Recommendation for Applications Using Approved Hash AlgorithmsI've already implemented HMAC sometime ago and there i sno rocket science do it on powerfull PC-doing those things on MPU with restricted flash program code size and 512 bytes of SRAM is a litle bit challenging, but hopefully I know AVR assembler at the level which allows me understand and modify sample code to fit my needs.There is nothing more needed to make this authentication secure than SHA-256, and I've linked source of all papers which might be interesting for someone trying to do similar thing, so now it's time to concentrate on MPU implementation of SHA256, since HMAC is strightforward and well documented when we have high performance assembler version of secure hash like SHA-256 optimized for target MPU.My target MPU is ATTiny85 (1MHz-8MHz) 512 bytes of SRAM and 8KB of program flash, so now if someone could help resolve those issues with this bloody macros conversion from SHA-256 source code written in Atmel AVR Studio (.asm) to GNU GCC, probably many people could benefit from this since this SHA-256 AVR assembler was optimized for ATMEGA'a too, wchich are cheap, easy available, but I do not like Window$ so ATMEL AVR Studio is not my AVr development platform- GNU AVR is fine, while this is quite simple project and the only thing I'd like to do is try run GCC AVR version of this optimized SHA-256 .asm code to compare its performance with other SHA256 avr-as implementations

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 12:22:42 pm
content: Quote from: Kalvin on August 08, 2015, 12:11:01 pmWhen you read carefully those NIST recomendations they estimate different probabilities and even truncating SHA-256 based HMAC to minimum 32bits will not affect security in simple switches like thisATTiny85 has enougth of Flash,RAM and MIPS, the only issue is conversion of ATMEL AVR .asm to GCC avr-as, so the problem is not hardware, but software and this can be fixed sooner or later..

author: Kalvin
author_rank: Super Contributor
timestamp: August 08, 2015, 12:36:24 pm
content: Quote from: eneuro on August 08, 2015, 12:22:42 pmI understand. However, you may notice at some point that the application code is so big (read: feature creep) that you need desperately more Flash and RAM, and you find yourself thinking where can I get more Flash or RAM. So you might try to squeeze more Flash and RAM from the security portion. Typically that means that you are compromising the security. In that sense, I just suggested that you might be better off with a MCU which provides either more Flash and RAM and/or built-in hardware security features.

author: Kalvin
author_rank: Super Contributor
timestamp: August 08, 2015, 12:53:01 pm
content: Quote from: eneuro on August 08, 2015, 12:22:42 pmIf your MCU would have for example 32KB Flash and 2KB RAM instead of the 8KB/512B, you could use the C implementation of the SHA256 without any problems. When you had finished the project you could try to optimize it for the Attiny85. Now you are struggling due to the limitations of the Attiny85 and problems with porting from one ASM to another, while you could spend your time in developing your application. Just my 2c.

author: hans
author_rank: Super Contributor
timestamp: August 08, 2015, 03:36:23 pm
content: Oh yes very much so.I started out my own home automation system with a PIC16F1509 chip and a MRF49XA RF transceiver.Couldn't get the 1509 for a few boards, so ordered the 1508 instead (boards were already on the way - seemed I was unlucky picking the PIC chip with non-compatible pinout).Got protocol working, retransmissions on CRC fail, sensor readout with low-power modes, etc. ~75% flash used, and wasn't even at the point of security or maybe a bootloader. Although you could fit a lot more in 8K on an AVR, I still agree it's not very much code space if you account for feature creep. My implementation was very simple, basically only running the radio driver with a small protocol stack to handle retransmissions & XOR CRC.One feature I really wanted is to store sensor data to EEPROM in case coordinator would go down. The coordinator would then need some commands to empty the contents of the EEPROM.I also found that 256 bytes of RAM is quite limiting. You always need 2 packet buffers. 1 for holding a TX message and 1 for RX to process the ACK message. If you only have 2; you need to be careful for any other commands that also need to be delivered on that node.. because you don't have any space left to continue.However if a single packet is 32 bytes (including header, status bytes, etc.) , then e.g. 4 or 6 packet buffers x 32 is quite a big burden for 256 bytes of RAM. On 512 it may be OK, but if you need some for encryption..I now plan to switch to a PIC24F32KA301 device. 2K should be plenty.. for now. STM32F031 is interesting too (same package, lot more RAM and horse-power), but it's ADC is only specced down to 2.4V.Or, alternatively, PIC24FJ128GA202. It has a cryptographic engine with AES-256 and "True Random Number Generator", but is a lot bigger package

author: eneuro
author_rank: Super Contributor
timestamp: August 08, 2015, 06:32:36 pm
content: Quote from: Kalvin on August 08, 2015, 12:53:01 pmThere were no problem implement HMAC using other GCC avr-as SHA256 implementation, which changed to have nice sha256 interface:Code:extern sha256(uint8_t *hash, uint8_t *msg, uint32_t len);Then followed HMAC detailed description from linked earlier HMAC papers and I've already implemented HMAC which return 256 bit (32 bytes) HMAC of passed txt and key:Code:// HMAC papers// http://cseweb.ucsd.edu/~mihir/papers/hmac-cb.pdf// http://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf// h: Assumes hmac hash output size 32 bytes for sha256 - 256 bits )void hmac(uint8_t *h, uint8_t *txt, uint8_t txt_len, uint8_t *key, uint8_t key_len ) {#define hmac_hash_size (32)#define hmac_ipad (0x36)#define hmac_opad (0x5C)// hmac ipadhmac_pad(h, txt, txt_len, key, key_len, hmac_ipad );// hmac opadhmac_pad(h, h, hmac_hash_size, key, key_len, hmac_opad );} // hmacSo, having HMAC implemented now I could easy create secure key instance and keep in memory as 256 bit (32 bytes) hash - result of HMAC entered security password, random salt xor'ed with other MPU real time data:Code:...#define hash_size 32volatile uint8_t seckey;...hmac(seckey, pass, 9, salt, 4 ); // Generate hmac of entered password with salt and store as secure key in SRAM...I'm so far less than 3KB of AVR ATTiny85 MPU code so far and I've HMAC and SHA256 hash implementedCode:$ ls -l sha256_test.bin-rwxrwxr-x 1 eneuro eneuro 2324 2015-08-08 20:11 sha256_test.bin

author: eneuro
author_rank: Super Contributor
timestamp: August 09, 2015, 08:52:19 am
content: Quote from: jezsmith41 on August 07, 2015, 07:48:54 pmIn spare time make your homework first and watch this before you press post button on furumQuantum cryptography: basics and technology with Vadim Makarov (one-time pad unbreakable -bit wise addition XOR- cipher used by comercial systems to encrypt QKD keys send over public channel)https://www.youtube.com/watch?feature=player_detailpage&v=wF-BWgnpYmI#t=1900This man hacks quantum key distribution and if you do not understand him, you will not understand what I'm talking about too, but you do not have to spam forum with this sort of statements you made....Quote from: jezsmith41 on August 07, 2015, 07:48:54 pmWho cares what sort of crap someone uses to post something on forums?Do not let spam forums with this sort of crappy apps, so I'd suggest use classic WWW browsers instead...

author: jezsmith41
author_rank: Contributor
timestamp: August 09, 2015, 08:54:19 am
content: Its nothing to do with quantum cryptography, the guy is a charlatan using buzz words he knows nothing aboutSent from my Xoom using Tapatalk

author: jezsmith41
author_rank: Contributor
timestamp: August 09, 2015, 08:56:24 am
content: I work in cryptography so I do know what quantum crypto entails which is more than he doesSent from my Xoom using Tapatalk

author: jezsmith41
author_rank: Contributor
timestamp: August 09, 2015, 09:00:41 am
content: There is a very good reason why there are only a few crypto algos used, we only have the maths to prove the security of certain classes, one time pad is provable secure if and only if its used correctlySent from my Xoom using Tapatalk

author: jezsmith41
author_rank: Contributor
timestamp: August 09, 2015, 09:05:13 am
content: Quantum cryptography uses ideas based around quantum entanglement of photons and nobody has yet built a commercially viable system' there are some research systems.Sent from my Xoom using Tapatalk

author: eneuro
author_rank: Super Contributor
timestamp: August 09, 2015, 08:14:56 pm
content: Quote from: jezsmith41 on August 09, 2015, 09:00:41 amMaybe its time to demistify complexity of XOR cipherOne Time Pad Encryption The unbreakable encryption methodInteresting visual demo of one-time pad below:One-time pad

author: eneuro
author_rank: Super Contributor
timestamp: August 09, 2015, 08:38:21 pm
content: Anyway, I've successfully tested implemented SHA-256 hash:Code:// Hash test// hash_test of "eneuro": 46302ed80aeaf03b60cb8abe84702cfd8312d0b876edda25df3e5af8e7283f08sha256(hash_test, "eneuro", 6 );hash_ok= (hash_test==0x46 && hash_test[hash_size-1]==0x08 );as well as HMAC-SHA-256 on running ATTiny85:Code:// HMAC test// txt: eneuro// key: 123456789// HMAC-SHA-256: C46C02EB3B09E985404674558DC1614DAA4043EFEEEC7A1821672D1772590440hmac(hmac_test, "eneuro", 6, "123456789", 9 );hmac_ok= (hmac_test==0xC4 && hmac_test[hash_size-1]==0x40 );It is time to connect RF modules to MPU instead of LEDs and try to send/receive lets say ~128bit long pulses ended with hash truncated from 256 bits to 128 bits or even 64bits, since depending on security level needed, eg. no need to send full 256bit hash to turn on/off light bulb in the room and 64bits should be fine , but for garage doors 128bits should be probably fine, since attacker rather will use explosive materials to open the doors than will be able do it by hacking 128bit truncated SHA-256, while additionally will have little chance to see not too many such messages, so very difficult to be luckyI think I will define something like security levels, where highest will be 0 with oryginal 256bit hash, then level 1 - 128bit, level 2 - 64bits and even level 3 - 32bits for thing which do not require too much security like a remote controled toys, etc.

author: Kalvin
author_rank: Super Contributor
timestamp: August 09, 2015, 08:43:47 pm
content: Quote from: eneuro on August 09, 2015, 08:38:21 pmGood progress! You should also verify the SHA256 against the standard test vectors.

author: eneuro
author_rank: Super Contributor
timestamp: August 09, 2015, 09:00:43 pm
content: Yep, I will generate code for more detailed tests to test hash function which is critical there, for the moment only wanted to see if I'm able do get proper sample hash output and hmac, to be able make real RF tests with real hash/hmac values

author: Kalvin
author_rank: Super Contributor
timestamp: August 09, 2015, 09:17:54 pm
content: Quote from: eneuro on August 09, 2015, 09:00:43 pmThe algorithm implementation looks good as it matches to the linux command output:echo -n "eneuro" | sha256sumIt is always a good thing to check against the standard test vectors so that the implementation hasn't missed something.

author: lincoln
author_rank: Regular Contributor
timestamp: August 10, 2015, 03:34:34 am
content: Quote from: lapm on August 08, 2015, 07:25:38 amI think this is relivent:https://xkcd.com/538/

author: eneuro
author_rank: Super Contributor
timestamp: August 10, 2015, 10:35:38 am
content: Quote from: Kalvin on August 09, 2015, 09:17:54 pmI've found those NIST SHA-256 test vectors thereNIST: Cryptographic Algorithm Validation Program (CAVP)Inside those zips provided here:http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabittestvectors.ziphttp://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zipthere are SHA-256 byte/bits test vectors with excpected responsesCode:shabittestvectors-sha256-20150810:Readme.txt SHA256LongMsg.rsp SHA256Monte.rsp SHA256Monte.txt SHA256ShortMsg.rspshabytetestvectors-sha256-20150810:Readme.txt SHA256LongMsg.rsp SHA256Monte.rsp SHA256Monte.txt SHA256ShortMsg.rspThis testing is described in thisNIST: The Secure Hash Algorithm Validation System (SHAVS)

author: eneuro
author_rank: Super Contributor
timestamp: August 10, 2015, 10:47:04 am
content: I've changed slightly HMAC implementation to be able output HMAC with desired number of bits rather than full 256bits from SHA-256 hash function-this function uses temporary program stack memory to output full hash, but returns truncated given number of bits, so there is no need to allocate MPU memory for full hashes if security level will not require this, especially for mentioned later HOTP implementation:Code:void hmac(uint8_t *h, uint8_t h_len, uint8_t *txt, uint8_t txt_len, uint8_t *key, uint8_t key_len );It will allow easy implementHOTP: HMAC based One-time Password Algorithmas described inRFC4226: HOTP: An HMAC-Based One-Time Password AlgorithmQuoteHOTP algorithm security is analyzed in this document, so worth to see if it fits my needs.Having HMAC-SHA-256 with resulting hash trunctate option implemented it is easy to have HOTP coded, too

author: eneuro
author_rank: Super Contributor
timestamp: August 10, 2015, 12:36:11 pm
content: Quote from: eneuro on August 10, 2015, 10:47:04 amAfter quick review of thisRFC4226: HOTP: An HMAC-Based One-Time Password Algorithmproblem is that it fit snice in client-server applications, where we have established secure connections, since one of its requirements to avoid replay attacks defintely in the case of RF communication without additional encryption, probably will not work by applying HOTP ptotocol schemed described in this RFCQuoteHowever of course counter is not send with HOTP (eg. encrypted or in clear form), but server try its next value(s) during resync based on current value confirmed in the case of sucsessfull HOTP authentication, so replay attacks could be an issue when we have not encrypted communicationQuoteReplayed attack could also lock client if suggested way of synchronization were performed in this way:QuoteIt might be good idea send two HOTP numbers (64bits) to help resynchronize counter on server, but still in the case of insecure RF link replay packet issues do not allow implement this HOTP in a strightforward way described in this document and tricky solution neededHowever, I like idea of 32bit HOTP precomputed based on updated synchronized counter on receiving devices and stored asuint32_tfour bytes numbers easy to compare in MPU after RF signal is received

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 11:27:54 am
content: Since there is additional requirement I might need a few project-make this radio RF communication with arbitration to be able send more critical mesages at higher priority, so devices capable to send/receive will abandom own transmission when detects higher priority transmiter, I might need encrypt sender IDs, so I've developed tricky random bytes generator and will apply NIST tests for randomnes to see how good it is, but when high security will be needed between senders/receivers in my RF network of devices, than 4GB o TRNG data obtained from hardware random generators will be shared along devices with its secret keys, so this way no AES or othercipher used, but pure random bits and... one-time pad XOR cipher .Working on such TRNG based on timing jitter random phenomenon and oscillator drift found in free-running CMOS ring oscillators as a source of randomnessOf course NIST tests for randomnes will be made to ensure high entrophy quality of this custom hardware random bytes generator.Anyway, optimizing now for speed and size PRNG for 8bit AVR which will be seeded with TRNG bytes bits and packets send over radio RF will be "encrypted" either using this PRNG (to make life harder for eavesdropper, since he can't see HMAC/HTOP and other data in clear unencrypted way ready to compare with brute forced hash, etc) or TRNG with XOR cipher for critical systems which require really high security.Anyway, even PRNG will be seeded with a lot of TRNG bytes, so it should be fine for applications, where we do not care about eavesdropper-just to confuse, because of when someone is not able see anything while sniffing our RF channel, than can think that it is encrypted and when he decrypt this he will get access to our system, but it will be only fake "encryption"However, sometimes TRNG one-time pad XOR cipher will be used, so encryption will be really strong, so eavesdropper will be forced to make attempt to decrypt those messages send over our local radio network, else sniffed HMAC/HOTP hashes and all communication which attacker can see could look like this in the case of PRNG usedLets confuse eavesdropper and let him loose their time, when we will be able switch between PRNG/TRNG even in the same application, so he might be successfull in decrypting PRNG part of fake stream, but no chance to do anything usefull when encrypted with TRNGFor arbitration, packets probably will based on expierience from CAN/VAN buses, so device ID will define its priority in network, so high priority devices will have given proper IDs, so they will have a chance to win arbitration, when a few senders will try transmit at the same time.So, not encrypted packet will probably look like this:Code:SRC,DST,TXT,SHA256/HMAC/HOTPDepending on application security level HMAC or SHA256 will be used instead of truncated HOTP to 32bits.When we encrypt such packets, than nodes which will create something like VPN (Virtual Private Network) will be able resolve arbitration issues and esnure send messages integrity, while signed with SHA-256 based on shared secret keys, counters, and another MPU real time data available only for these devices while running for some time and difficult to obtain by eavesdropper, even if he buys the same device for teardown, to try dissassemble/change by sending to company to read locked program code, make power analysis attack, etc.

author: nctnico
author_rank: Super Contributor
timestamp: August 11, 2015, 12:40:57 pm
content: That amount of random data needs to be stored somewhere and is likely not to change. This makes it an easy target for an attacker. He can extract the random data and use it to decode the messages. Come to think of it. As soon as you store random data for later it is no longer random data but a fixed key.

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 01:05:11 pm
content: Quote from: nctnico on August 11, 2015, 12:40:57 pmNope, because of used TRNG bytes are replaced by new TRNG data, so even when he gains access to TRNG bits used for encryption, it doesn't help him decode previous messages and new are not generated yet, so he CAN't use it to decode messages, especially when this event is detected, eg. explosives used to destroy safe, but probably MPU and TRNG keys will not survive this, so he will destroy keys when trying to get access.BTW: Unused TRNG bits are random and good for encryption and it doesn't matter they are stored somewhere-used TRNG bits are replaced with new TRNG bytes, when no longer needed, so no chance to reuse used keys and decode old messages and additionallyeavesdropper might think that he got those keys, but he will find there only unused keys, so another way to confuse him-he will find garbage bits instead of used keys, so he can't decode previous transmissionWriting software to test entrophy of data send over RF to estimate level of PRNG encryption-to make it more difficult for eavesdropper to findout it is fakeThe Search for Randomness by Jean Bourgain

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 02:50:20 pm
content: Quote from: eneuro on August 11, 2015, 01:05:11 pmOK, I've implemented Shannon entropy and calculated using this examplehttp://rosettacode.org/wiki/Entropyfor ~128KB of sample random data:Linux TRNG /dev/random:entropy: bytes: count: 135852 entropy:0.999825472Linux TRNG /dev/urandom:entropy: bytes: count: 135852 entropy: 0.999814676For simply PRNG I've got:Code:$ entropy <erng_test.rndentropy: bytes: count: 135852 entropy: 0.994979704As expected /dev/random has highest entropy.When tried compress /dev/random and dev/urandom gzip refuses and shows 0.0%dev_urandom.rnd: -0.0% -- replaced with dev_urandom.rnd.gzdev_random.rnd: -0.0% -- replaced with dev_random.rnd.gzbut in the case of this simple PRNG we get:Code:$ gzip -v *.rnderng_test.rnd:94.3%-- replaced with erng_test.rnd.gzYep, didn't tested this PRNG period, but of course probablygzipnoticed this and found a way to make this file less than 10KB-rw-rw-r-- 1 eneuro eneuro 7747 2015-08-11 16:13 erng_test.rnd.gzAnyway, entropy numbers itself was not so bad for this PRNG, but probably NIST tests for randomness will show how bad this PRNG based fake encoding might beHowever, for short 128 bytes long messages both /dev/random and this simply PRNG gzip compression ratio was~2.3%, so it could be difficult say based on compresion ratios which message was encrypted using TRNG (/dev/random ) and which was XOR'ed using this simply PRNG, which gave 94.3% in the case of ~1000 times bigger file-probably this PRNG has very short periodUpdate: When tested a few KB english text it compressed at ~60% rate, but had ~0.5 bit entropy, so entropy doesn't looks bad in the case of this simply PRNG-it doesn't looks like clear textCode:$ entropy <eng.txtentropy: bytes: count: 4211 entropy: 0.543415917$ gzip -v eng.txteng.txt: 59.6% -- replaced with eng.txt.gzUpdate2: In comparision 4GB of Linux /dev/urandomCode:$ dd if=/dev/urandom bs=128M count=32 | entropy4169053888 bytes (4.2 GB) copied, 877.318 s, 4.8 MB/sentropy: bytes: count: 4169053888 entropy:0.999999995Update3: For this simple PRNG I've got for exampe seed:1GB:entropy: bytes: count: 1073741824 entropy:0.9995283134GB:entropy: bytes: count: 4294967296 entropy:0.999528314PRNG period must repeat and no new information available, so there is no improvement of entropy between 1GB-4GB, as we could see in the case of Linux /dev/randomNope, /dev/urandom had small entropy improovement too: +15*10^-9 ...Code:$ dd if=/dev/urandom bs=128M count=8 |entropy1073741824 bytes (1.1 GB) copied, 226.159 s, 4.7 MB/sentropy: bytes: count: 1073741824 entropy:0.999999980It will be interesting to see what we get from TRNG based on hardware random generator I'm working on

author: helius
author_rank: Super Contributor
timestamp: August 11, 2015, 09:34:11 pm
content: I can't tell if you're taking the piss or you really believe what you're writing. Do you think real cryptographers test their ciphers by just running them through gzip?You can't distribute OTP bits by protecting them with OTP bits. The security of the OTP depends on every single bit you transmit being mixed (XORed) with a secret, only used one time, OTP bit. If you ever use any OTP bit more than once, it has no security at all. So if you use an OTP bit to "protect" multiple bits being sent, some of which are new OTP bits for future use, and others are commands or data, this scheme has no security at all.Forget all this "random" stuff you learned online, randomness is no test of security. A secure cipher will appear random most of the time, and sometimes it won't. You can also create trivially breakable codes that appear random; it's completely meaningless.

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 09:38:53 pm
content: I've reimplemented PRNG to be able combine a few PRNG ciphers with different seeds to obtain one final encryption byteCompared entropy of this PRNG (I use it in other project, where air conditionig fan is randomly driven to create feel of wind rather than boring constant air flow with classic fan noise and the same PRNG inside this thing works 24 hours a day 7 days a week) withaout strange fan behaviour and no supprise its entropy looks good:Code:$ ./rng_test 1024 |entropyentropy: bytes: count: 1024 entropy: 0.976932390Linux random devices for such short strings return something similar:Code:$ dd if=/dev/random bs=1024 count=1 |entropyentropy: bytes: count: 1024 entropy: 0.977850489$ dd if=/dev/urandom bs=1024 count=1 |entropyentropy: bytes: count: 1024 entropy: 0.9761842894GB bytes entropy much better then in previous.... Eniac based squared meanCode:$ ./rng_test 4294967296 |entropy./rng_test: bytes: 4294967296entropy: bytes: count: 4294967296 entropy: 0.999973700I think, its time put everything together while I've implemented and tested different software building blocks and switch ON/OFF light bulbs with a litte help of cryptography support to authenticate in light bulb RF module the only RF switch(es) in my yard which are allowed turn ON/OFF this thing

author: Kjelt
author_rank: Super Contributor
timestamp: August 11, 2015, 09:45:45 pm
content: Quote from: helius on August 11, 2015, 09:34:11 pmAs mr smith has elequantly put it, he has no idea what he is doing and just piecing it together.If he had any sense he would have asked advice from people that do know what they are doing. Have studied randomness, know the difference between statistical randomness and cryptographically secure randomness.But unfortunately he just keeps babbling on thinking he is doing something reaaly new and smart and very unfortunately this forum gives him a podium so that newbies also might think he is on the right track.I work in the field for more then 15 years and find it embarrassing what is going on, but stop wasting my time giving advice to someone that does not want to listen or learn.

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 09:53:50 pm
content: Quote from: helius on August 11, 2015, 09:34:11 pmI know how and I've NIST packages for testing randomness and was playing with this stuff a few months ago.There is no sense to use NIST tools if gzip shows such huge compression-for any decent even PRNG cipher it will refuse compress, so it is always interesting to see how gzip deals with some data just to see compression ratio, not to test randomnessFor example 1MB of /dev/urandom]Code:$ cat dev_urandom_1MB.rng|entropyentropy: bytes: count: 1048576 entropy: 0.999978779Attempt to compress this file and result is 0.0% compression, since it it decent PRNG:Code:$ gzip -v dev_urandom_1MB.rngdev_urandom_1MB.rng: -0.0% -- replaced with dev_urandom_1MB.rng.gz

author: eneuro
author_rank: Super Contributor
timestamp: August 11, 2015, 10:04:21 pm
content: Quote from: Kjelt on August 11, 2015, 09:45:45 pmI know, one bug is fixed by another because of systems are too complicatedI've sucessfull projects, because of I test everything step by step, function after function and now I'm ready put everything thogther including RF modules.It is not a rocket science, but require some work to ensure everything works as expected and by testing everything carefully step by step on MPU there is progress and I will have at the end of this week working solution I hope, since this is part of another projects so I'd like to have working devices as soon as possible before holidays

author: eneuro
author_rank: Super Contributor
timestamp: August 12, 2015, 07:40:18 pm
content: Quote from: Kjelt on August 11, 2015, 09:45:45 pmI've studied mechanics and was interested in electronics. Last time worked as software developer for years, but writing code for big company was boring and now I do what I always wanted to-fusion of machanica, electronics and software development on tiny MPUs to make usefull things for everyone.When I need something to study I can read a book or attent live webinar.Forum is for brain storm ideas only, but of course I won't reveal too much before final product showdown, so thank you, but you can not help more/Now I've clear vision how this will be "glued" together thanks to my work expierience and technical background at university.RF physical communication layer is in my interest now, so worth go back 65 years to the originsCommunication Theory of Secrecy Systems By C.E.SHANNON

author: eneuro
author_rank: Super Contributor
timestamp: August 13, 2015, 09:40:09 pm
content: I've successfuly tested MPU software fast moveing avarage pin bits digital input, to be able receive on MPU pin clear bits regardles of a few noisy pin changes.Code:000001a0 <mpu_pin_bit_is>:1a0: 20 91 60 00 lds r18, 0x00601a4: 80 e0 ldi r24, 0x00 ; 01a6: 98 e0 ldi r25, 0x08 ; 81a8: 32 2f mov r19, r181aa: 31 70 andi r19, 0x01 ; 11ac: 83 0f add r24, r191ae: 26 95 lsr r181b0: 91 50 subi r25, 0x01 ; 11b2: d1 f7 brne .-12 ; 0x1a8 <mpu_pin_bit_is+0x8>1b4: 86 30 cpi r24, 0x06 ; 61b6: 10 f0 brcs .+4 ; 0x1bc <mpu_pin_bit_is+0x1c>1b8: 81 e0 ldi r24, 0x01 ; 11ba: 08 95 ret1bc: 98 e0 ldi r25, 0x08 ; 81be: 98 1b sub r25, r241c0: 96 30 cpi r25, 0x06 ; 61c2: 10 f4 brcc .+4 ; 0x1c8 <mpu_pin_bit_is+0x28>1c4: 82 e0 ldi r24, 0x02 ; 21c6: 08 95 ret1c8: 80 e0 ldi r24, 0x00 ; 01ca: 08 95 ret000001cc <mpu_pin_bits_add>:1cc: 81 70 andi r24, 0x01 ; 11ce: 90 91 60 00 lds r25, 0x00601d2: 99 0f add r25, r251d4: 89 2b or r24, r251d6: 80 93 60 00 sts 0x0060, r241da: e2 df rcall .-60 ; 0x1a0 <mpu_pin_bit_is>1dc: 82 30 cpi r24, 0x02 ; 21de: 31 f0 breq .+12 ; 0x1ec <mpu_pin_bits_add+0x20>1e0: 90 91 61 00 lds r25, 0x00611e4: 99 0f add r25, r251e6: 98 2b or r25, r241e8: 90 93 61 00 sts 0x0061, r251ec: 08 95 ret000001ee <mpu_pin_bit_delay>:1ee: 88 ea ldi r24, 0xA8 ; 1681f0: 91 e6 ldi r25, 0x61 ; 971f2: 01 97 sbiw r24, 0x01 ; 11f4: f1 f7 brne .-4 ; 0x1f2 <mpu_pin_bit_delay+0x4>1f6: 08 95 retI've made also tests by hand using... classic button as pin state source of course at very low transmission speed, to ensure that this software noise reduction works and it looks like no problem with software-it works as designedPins will be additionaly protected like described in thisProtecting Inputs in Digital Electronicsarticle.All subsystems working, so very close to proof of concept and switch real mains AC loads using developed secure communication500V mosfets are in my hands, so I will solder another prototype AC mosfets switch tomorow controlled by RF and this sophisticated custom piece of AVR ATTiny85 code

author: eneuro
author_rank: Super Contributor
timestamp: August 16, 2015, 07:36:47 pm
content: Energy storage choosen and it could be supercapacitor 5.5V 220mF in many devices with additional different energy harversting methods -probably Tesla style wireless resonant energy transfer to recharge this supercap, but need to test this1.1Q and close to 2.75J of eelctric energy should be fine for one of my designed AC mosfets switches with very low power consumption gate driver

author: jezsmith41
author_rank: Contributor
timestamp: August 17, 2015, 04:40:27 am
content: The guy is an idiot, not sure if he is deliberately trying to con people but what he has written is a one time pad which:-) has been done hundreds of times before, he claims that it uses quantum cryptograohy when it uses nothing if the sort. He is either deliberately trying to con money out of people or he is an idiotSent from my Xoom using Tapatalk

author: jezsmith41
author_rank: Contributor
timestamp: August 17, 2015, 04:48:04 am
content: So tell me my little con man friend, why are we so excited that you've written a one time pad which definitely does not use quantum cryptography it anything like it?Sent from my Xoom using Tapatalk

author: eneuro
author_rank: Super Contributor
timestamp: August 19, 2015, 04:00:03 pm
content: Testing physical RF transmision layer with implemented software bit averaging which should help receive correct bits values regardless of short spikes possible during RF communication.I've implemented on byte level start bit which is always "0" and allows synchronize serial comunication speed, as well as end bit which is even parity bit (https://en.wikipedia.org/wiki/Parity_bit) of eight byte data bits inside 10bits per byte.Local Interconnect Network (LIN)serial communication protocol was inpiration to implement physical layer this way, but I've decided to add even parity bit which is optional -software can be recompiled with parity bit disabledQuoteWhile I'd like try remote control at distances over 100+ meters I might be interested in low speed RF transmission, so that is why I've implemented start bit to be able in slave device detect transmission speed and adjust receiver, so with simply protocol like this I should be able now send comunicate faster at short distances (better RF quality) and the same master can send messages to far away slaves at lower speed to be able take advantage of RF signal averaging and still be able understand data bytes in more noisy environment hundreds of meters from transmiter.We'll see how it works in practice, but automatic receiver transmision speed adjustment was one of communication protocol requirements at the begining, while I'm interested to controll many devices on my yard which is a few hundred meters long, not only home equipment (including weather station and wind turbine on nearby hill)Plastic optics fibers (POF) can be used using the same implemented protocol, so it is worth to spend some time and test it well to ensure no bugs are in software which could apear in production environment