Hi Gideon, this is an extremely interesting approach I would love to know how this compares with a more naive encoding scheme, whereby predetermined strings of bits represent 1/0, and there can be multiple strings representing the same bits while all other strings of the same length are discarded. So apart from reducing the key size, is there another advantage in using the Hamming distance for the purpose of encoding the bit value?
Sorry for the very late reply... the Hamming distance discriminator is very effective in creating equivocations. Brute force cryptanalysis will generate several plausible plaintexts with no built in preference.
@@GideonTheTeacher I see, thank you for your reply. It is interesting to think how various "decryption oracle" attacks figure in this, I guess it would be very important to ensure that an attacker can't figure out the key by replaying various chunks of traffic... also, perhaps by timing analysis on how the receiver processes the traffic (I am thinking about cases where a large chunk of bits is discarded as null data while suddenly another 'valid' one gets processed, it can produce a significant timing signature).
@@klgamit There is no processing difference between discarded strings and letter-evaluated strings. All strings are checked against all letters of the alphabet. Served by the same plaintext time and again BitFlip will generate a different ciphertext each time. see wesecure.net/learn/BitFlipEncrypt.php
@@GideonTheTeacher Oh but I am talking about an application induced processing difference, which is not strictly a responsibility of the encryption algorithm to handle. However it may be very important to address it when using BitFlip, more than currently deployed ciphers, because of the algorithm simplicity and the shortness of the key. The key is basically 12 bits so the application must not generate any timing signal that can be seen by the attacker when processing the decrypted data (and it doesn't process discarded bits of course)
You may ignore my last question, I watched the video again and it clarified things (been a while since 1st watched it). I am curious to know if the cipher can work as well without having to delibarately include a lot of 'spurious' bits (but the idea is great, always thought steganography is underrated and underused ;-)).. but I'll get around to reading your paper soon, anyway this is great & בהצלחה!!
There is a qBitFlip version to ascertain the distance between the transmitted string the key string, will be presented in a coming crypto episode. This BitFlip cipher using classic bits is quantum safe through drowning techniques and other means covered the cited articles.
In BitFlip you project security by sending off a ciphertext much longer than the plaintext. You don't store the long ciphertext. The more you use a key, the longer the ciphertext has to be per same plaintext in order to maintain the desired level of security. With 5G technology we can easily use a megabyte of ciphertext for a kilobyte of plaintext. The user determines how much security to project.
Gosh, always overwhelmingly inspired by your passion and love for crypto
The only professor, who doesn't use cookies and remembers his password from his UA-cam account in mind.
No, I don't use cookies but UA-cam does...
Hi Professor Thank you for an other interesting episode :)
Thank you SS! Planning to add a few more soon
the problem of exchanging keys still remains. RSA is still nedeed !
Hi Gideon, this is an extremely interesting approach
I would love to know how this compares with a more naive encoding scheme, whereby predetermined strings of bits represent 1/0, and there can be multiple strings representing the same bits while all other strings of the same length are discarded. So apart from reducing the key size, is there another advantage in using the Hamming distance for the purpose of encoding the bit value?
Sorry for the very late reply... the Hamming distance discriminator is very effective in creating equivocations. Brute force cryptanalysis will generate several plausible plaintexts with no built in preference.
@@GideonTheTeacher I see, thank you for your reply. It is interesting to think how various "decryption oracle" attacks figure in this, I guess it would be very important to ensure that an attacker can't figure out the key by replaying various chunks of traffic... also, perhaps by timing analysis on how the receiver processes the traffic (I am thinking about cases where a large chunk of bits is discarded as null data while suddenly another 'valid' one gets processed, it can produce a significant timing signature).
@@klgamit There is no processing difference between discarded strings and letter-evaluated strings. All strings are checked against all letters of the alphabet. Served by the same plaintext time and again BitFlip will generate a different ciphertext each time. see wesecure.net/learn/BitFlipEncrypt.php
@@GideonTheTeacher Oh but I am talking about an application induced processing difference, which is not strictly a responsibility of the encryption algorithm to handle. However it may be very important to address it when using BitFlip, more than currently deployed ciphers, because of the algorithm simplicity and the shortness of the key. The key is basically 12 bits so the application must not generate any timing signal that can be seen by the attacker when processing the decrypted data (and it doesn't process discarded bits of course)
You may ignore my last question, I watched the video again and it clarified things (been a while since 1st watched it).
I am curious to know if the cipher can work as well without having to delibarately include a lot of 'spurious' bits (but the idea is great, always thought steganography is underrated and underused ;-)).. but I'll get around to reading your paper soon, anyway this is great &
בהצלחה!!
So this forces the communications to use either a 1 or 0? preventing the use of a bit that's both 1 and 0 ?
There is a qBitFlip version to ascertain the distance between the transmitted string the key string, will be presented in a coming crypto episode. This BitFlip cipher using classic bits is quantum safe through drowning techniques and other means covered the cited articles.
Should the 'actual message' length be close to 1/2 the stream length? Is there an optimal ratio?
In BitFlip you project security by sending off a ciphertext much longer than the plaintext. You don't store the long ciphertext. The more you use a key, the longer the ciphertext has to be per same plaintext in order to maintain the desired level of security. With 5G technology we can easily use a megabyte of ciphertext for a kilobyte of plaintext. The user determines how much security to project.