Re: [cryptography] QODE(quick offline data encryption)
On Tue, 6 Jan 2015, Kevin wrote: I figured I'd start building my own open source encryption algorithm: And how many have you broken so far? -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE
On Wed, Jan 7, 2015 at 6:24 PM, listo factor listofac...@mail.ru wrote: He did try to sell maiden-voyage seat reservations. I have no idea if he collected any money, but if he did, I would not blame him, I would blame those that coughed up their coin. tl;dr: caveat emptor? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
Hey Natanael, Thanks for your response.
It's the chain of signatures always published in an accessible way so that
the original members can't doublespend and claim to be the task group?
Otherwise the blockchain approach is useful for you.
I think the naive solution I proposed in my first message is more efficient
than using Bitcoin, because it does not involve proof of work or flooding
stuff.
Shortly: Whenever a person is added to the band, all the members sign on
the new list. Whenever a member leaves the band,
all the members sign on the new list. The band members keep the signatures
forever, so they can always prove they where formed originally
from the original band S.
Example:
If the original band, band_0 = {a_0,a_1,a_2,a_3}, and a new member (a_4)
joins, we get a new band {a_1,a_2,a_3,a_4}.
If we denote the new list as band_1 := (a_0, a_1,a_2,a_3,a_4) then we need
the following signatures to prove the change:
sign[a_0](band_1), sign[a_1](band_1), sign[a_2](band_1), sign[a_3](band_1)
If the member a_1 now leaves the band, we denote band_2 =
(a_0,a_2,a_3,a_4), and we need the following signatures to prove the change:
sign[a_0](band_2), sign[a_2](band_2), sign[a_3](band_2), sign[a_4](band_2)
(Note that we might not be able to get a_1's signature, because maybe he
just failed somehow).
So far, after those two changes, we have to carry about 8 signatures.
If someone asks the group to prove that they have a majority of correct
nodes, they can just prove their current
identities, and send the 8 signatures.
(I can probably get away with less than 8 signatures, but the asymptotic
nature of the amount of signatures needed doesn't really change).
The band S doesn't publish the signatures. They only show the signatures
whenever I ask them.
The group setting is also solved as-is thanks to both the multisignature
support (m-of-n for up to 15 people), and thanks to ECDSA threshold group
signatures if you prefer these (I'm assuming they also don't limit you to
15 members).
Using a multisignature scheme I can probably get much shorter signatures,
which is cool.
I will still have to remember the identities of all the signers, and the
set of signatures to be remembered grows linearly with respect to time.
Assuming that I use some kind of Threshold signature scheme, how can I
transfer the secret parts to the next members in the band, so that parts of
the secret don't leak to previous members?
Most of what I read about threshold signatures assumes that some that some
trusted dealer deals the secret parts to the participants.
How can I move the secret parts to the new band without a trusted dealer?
Someone in this thread has mentioned Shamir secret sharing. Considering
this idea,
How can I avoid the possibility that some set of corrupt ex-band members
will gather and combine their secret parts?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE
On 1/7/15 4:24 PM, listo factor wrote: On 01/06/2015 09:12 PM, Kevin wrote: I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode I find the reaction from the list somewhat surprising. Some years ago, I had a neighbour that was building a moon-landing spacecraft in his backyard. Obviously, he never landed on the moon, but he learned a whole lot of useful things: for instance, holding a hammer close to the head instead of at the end of the handle will not substantially reduce the likelihood of hitting the thumb. He did try to sell maiden-voyage seat reservations. I have no idea if he collected any money, but if he did, I would not blame him, I would blame those that coughed up their coin. Grumbling is common. Variety is the spice of life, and it's also useful against issues of monoculture to protect against subsequent discoveries of backdoors or implementation vulnerabilities, published or not. This does not endorse the use of homegrown algorithms over any of the various well established and more vetted algorithms that researchers (and crackers) have analyzed, especially for anything of value. Such apps generally require the use of established crypto anyway, and sadly are often enough insecure because of misuse or flawed key management. It's hard to know if homegrown crypto is much of a learning experience, though, because it's so hard to tell if it's actually secure. As I said before, most crypto looks secure because the ciphertext generally looks like gibberish, whether secure or not. There's no easy way to test an algorithm compared to that neighbor's spacecraft. But if you are not a high value target, your crypto may provide adequate security as there's unlikely a cabal who will invest the resources to attempt to crack it. Life is short and freedom to explore is your right! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/7/2015 3:05 PM, shawn wilson wrote: On Wed, Jan 7, 2015 at 2:40 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: On 2015-01-07, at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Hi Kevin. Actually that’s a part of my job within the company I work for. I’m the one who can read some of the primary literature in cryptography. Now this makes me unusual, not a lot of companies our size have someone with my skills. And I'm betting they're Fortune 100. My point is, the company I work for does pentesting and have seen so many issues with information that people thought was encrypted not being encrypted and then leaked because it was only obfuscated with some base32/64 or w/e and maybe rotated by some value or w/e. It's kinda insane what people will do instead of using a well vetted crypto library. So I'm fearful that we'll stumble across someone using your library by finding some issue with it and the client says well, we encrypted it and then well, obviously not. OTOH, people will be people. If you want to keep it available and hope that no one uses it in production and that someone reviews it *shrug*. If someone uses it vs making their own system, hopefully you're smarter than them (probably) and it'll be harder to break than w/e they might've done. And it would probably be a good learning exercise if an expert got back to you with issues. If you have the fear that some poor soul will fall victem to a breach because of what I've done, take steps to prove that it is a threat and put the word out there. People will be people... And that is exactly what I am saying. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On Wed, Jan 7, 2015 at 3:09 PM, Kevin kevinsisco61...@gmail.com wrote: On 1/7/2015 2:40 PM, Jeffrey Goldberg wrote: On 2015-01-07, at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Hi Kevin. Actually that’s a part of my job within the company I work for. I’m the one who can read some of the primary literature in cryptography. Now this makes me unusual, not a lot of companies our size have someone with my skills. But I would be useless at evaluating your algorithm. I don’t know how to check if linearity in S-Boxes; I don’t know what properties to look for in a key schedule; I don’t know how to look for related key attacks, etc. I’ve never broken anything and wouldn’t really know where to begin trying to break something. So what I do is rely on expert advice and err toward being conservative. My understanding of both the process by which AES was developed and chosen along with the extensive research on it is that remains a very good choice as a block cipher. So if I were to “review” your algorithm for my company, I wouldn’t do it by actually reading the code, I would ask exactly the same sorts of questions that you have been presented with: (1) Does it offer me some valuable feature that isn’t available in more standard alternatives? If “no, there really is no reason to look at it further. (2) Is there good reason to believe that it has all of the security properties I depend on of what I am already using? If “no”, there is no reason for me to look at it further. (3) Is there a clear design document explains how it is supposed to achieve its claimed security properties? This is part of (2), but I wanted to break it into its own point. I can read — slowly and with effort — the descriptions of the designs of the things that I do use. I don’t get all of the finer points, but I see how problems that I never even would have thought of are addressed. As others have suggested, this is what you should START with. (4) What does the expert community say about it? If it hasn’t been sufficiently studied, then even if it is a complete work of genius, I’m going to wait until people who know how to evaluate things have done so. (5) Are there “safe” implementations of it available for me to use? An implementation needs to not only implement the algorithm, but guard against side-channel attacks. There are other things as well. All of which your system fails at without anyone having to look at the code. I am not going to take it down. Freedom, boys and girls, freedom. Good for you. Now if you actually want people to start looking at it, start with addressing my point (3). If you don’t make it easy for people to analyze your system, it is not going to receive the expert scrutiny required to meet some of the other criteria. But the concern is that there are software developers out there who don’t pay attention to the criteria that I listed. So, sure, go ahead and play with ideas. But please put some prominent notes that it hasn’t been evaluated and was designed by someone with no expertise, and so should only be used for playing around. And if you would like expert evaluation, you need to help those experts. There are lots of lone crackpots out there who think that they are lone geniuses. You are going to show that it isn’t a complete waste of experts time to look at your stuff. Cheers, -j J. I think it's great that you can look at this sort of thing from all angles. The security lies in data with a salt added to data which is rotated to the left by the length of bytes. I won't insult your intelligence by rehashing the formula as it is clearly written in the code. Errr... *which* code? Where? Sum total of what is published (that I could find) is: https://github.com/kjsisco/qode/blob/master/qode.au3 containing 5 lines: - qode An encryption algorithm - Perhaps you have missed the fact that you need to git push? Or is there some other location that I missed somewhere? W The point is, do you feel this provides the level of security that you desire? If the answer is no, in the trash can it goes! -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
Hey, Thank you for all the responses. I figured out that I left some important details out, probably because I thought about it for a long time. I'm sorry about that. I will try to formulate it again: Assume that the world contains correct people (People you can trust) and corrupt people (Those you can't trust). Also assume that the world has a majority of correct people (If it helps, you may assume 3/4 correct people). I am given a set S which contains k members (The music band). Assume that a majority of this set is correct. From time to time: - A random person (From the world) joins the band. (With good probability this new member is correct). - A random person (From the band) leaves the band. ( The band always have at least k people. The full story is that if the band becomes too big, it is splits into two bands. If the band becomes too small, it dies. But you can forget about all this and just assume that the band always have at least k people. ). Note that those steps leave the set with a majority of correct people with high probability. Assume that I met the original band. At some point in the future I meet some group of people (Maybe none of them was in the original band). How can they prove to me that they were formed from the original band by a set of steps as described above? And the real question I care about: How can they prove to me that a majority of them is correct? It's pretty important that the amount of data the band keeps should be no more than logarithmic in the amount of steps that have occurred. I think that linear is just too much data to store. @Jonathan: I think the threat model here is the Byzantine model. I hope that it answers your question. @Dave: Your point of view is interesting :) @Alexandre: I still haven't read the article. I will check it out. thanks. @Andrew: The trusted majority is about what I meant. I didn't know about the ship of theseus. cool :) real http://www.freedomlayer.org On Wed, Jan 7, 2015 at 6:48 PM, andrew cooke and...@acooke.org wrote: On Thu, Jan 08, 2015 at 03:33:24AM +1100, Dave Horsfall wrote: On Wed, 7 Jan 2015, realcr wrote: I am looking for some crypto primitive to solve a problem I have. [...] I guess, if it is really a band application as opposed to something more abstract, it boils down to what you mean by descendants. At least one founding member left? Are the offspring of same OK? Some musos can be really purist about this. i'd suggest that you can assume that there is always a majority of members who can be trusted. so you need something that can follow a trusted majority, even if they include no-one who is original. fwiw, when searching for previous work, this kind of problem is often referred to as the ship of theseus (preserving identity of the whole when all parts are replaced) - http://en.wikipedia.org/wiki/Ship_of_Theseus andrew ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On Wed, Jan 7, 2015 at 2:40 PM, Jeffrey Goldberg jeff...@goldmark.org wrote: On 2015-01-07, at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Hi Kevin. Actually that’s a part of my job within the company I work for. I’m the one who can read some of the primary literature in cryptography. Now this makes me unusual, not a lot of companies our size have someone with my skills. And I'm betting they're Fortune 100. My point is, the company I work for does pentesting and have seen so many issues with information that people thought was encrypted not being encrypted and then leaked because it was only obfuscated with some base32/64 or w/e and maybe rotated by some value or w/e. It's kinda insane what people will do instead of using a well vetted crypto library. So I'm fearful that we'll stumble across someone using your library by finding some issue with it and the client says well, we encrypted it and then well, obviously not. OTOH, people will be people. If you want to keep it available and hope that no one uses it in production and that someone reviews it *shrug*. If someone uses it vs making their own system, hopefully you're smarter than them (probably) and it'll be harder to break than w/e they might've done. And it would probably be a good learning exercise if an expert got back to you with issues. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/7/2015 2:40 PM, Jeffrey Goldberg wrote: On 2015-01-07, at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Hi Kevin. Actually that’s a part of my job within the company I work for. I’m the one who can read some of the primary literature in cryptography. Now this makes me unusual, not a lot of companies our size have someone with my skills. But I would be useless at evaluating your algorithm. I don’t know how to check if linearity in S-Boxes; I don’t know what properties to look for in a key schedule; I don’t know how to look for related key attacks, etc. I’ve never broken anything and wouldn’t really know where to begin trying to break something. So what I do is rely on expert advice and err toward being conservative. My understanding of both the process by which AES was developed and chosen along with the extensive research on it is that remains a very good choice as a block cipher. So if I were to “review” your algorithm for my company, I wouldn’t do it by actually reading the code, I would ask exactly the same sorts of questions that you have been presented with: (1) Does it offer me some valuable feature that isn’t available in more standard alternatives? If “no, there really is no reason to look at it further. (2) Is there good reason to believe that it has all of the security properties I depend on of what I am already using? If “no”, there is no reason for me to look at it further. (3) Is there a clear design document explains how it is supposed to achieve its claimed security properties? This is part of (2), but I wanted to break it into its own point. I can read — slowly and with effort — the descriptions of the designs of the things that I do use. I don’t get all of the finer points, but I see how problems that I never even would have thought of are addressed. As others have suggested, this is what you should START with. (4) What does the expert community say about it? If it hasn’t been sufficiently studied, then even if it is a complete work of genius, I’m going to wait until people who know how to evaluate things have done so. (5) Are there “safe” implementations of it available for me to use? An implementation needs to not only implement the algorithm, but guard against side-channel attacks. There are other things as well. All of which your system fails at without anyone having to look at the code. I am not going to take it down. Freedom, boys and girls, freedom. Good for you. Now if you actually want people to start looking at it, start with addressing my point (3). If you don’t make it easy for people to analyze your system, it is not going to receive the expert scrutiny required to meet some of the other criteria. But the concern is that there are software developers out there who don’t pay attention to the criteria that I listed. So, sure, go ahead and play with ideas. But please put some prominent notes that it hasn’t been evaluated and was designed by someone with no expertise, and so should only be used for playing around. And if you would like expert evaluation, you need to help those experts. There are lots of lone crackpots out there who think that they are lone geniuses. You are going to show that it isn’t a complete waste of experts time to look at your stuff. Cheers, -j J. I think it's great that you can look at this sort of thing from all angles. The security lies in data with a salt added to data which is rotated to the left by the length of bytes. I won't insult your intelligence by rehashing the formula as it is clearly written in the code. The point is, do you feel this provides the level of security that you desire? If the answer is no, in the trash can it goes! -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/7/2015 3:32 PM, Warren Kumari wrote: On Wed, Jan 7, 2015 at 3:09 PM, Kevin kevinsisco61...@gmail.com wrote: On 1/7/2015 2:40 PM, Jeffrey Goldberg wrote: On 2015-01-07, at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Hi Kevin. Actually that’s a part of my job within the company I work for. I’m the one who can read some of the primary literature in cryptography. Now this makes me unusual, not a lot of companies our size have someone with my skills. But I would be useless at evaluating your algorithm. I don’t know how to check if linearity in S-Boxes; I don’t know what properties to look for in a key schedule; I don’t know how to look for related key attacks, etc. I’ve never broken anything and wouldn’t really know where to begin trying to break something. So what I do is rely on expert advice and err toward being conservative. My understanding of both the process by which AES was developed and chosen along with the extensive research on it is that remains a very good choice as a block cipher. So if I were to “review” your algorithm for my company, I wouldn’t do it by actually reading the code, I would ask exactly the same sorts of questions that you have been presented with: (1) Does it offer me some valuable feature that isn’t available in more standard alternatives? If “no, there really is no reason to look at it further. (2) Is there good reason to believe that it has all of the security properties I depend on of what I am already using? If “no”, there is no reason for me to look at it further. (3) Is there a clear design document explains how it is supposed to achieve its claimed security properties? This is part of (2), but I wanted to break it into its own point. I can read — slowly and with effort — the descriptions of the designs of the things that I do use. I don’t get all of the finer points, but I see how problems that I never even would have thought of are addressed. As others have suggested, this is what you should START with. (4) What does the expert community say about it? If it hasn’t been sufficiently studied, then even if it is a complete work of genius, I’m going to wait until people who know how to evaluate things have done so. (5) Are there “safe” implementations of it available for me to use? An implementation needs to not only implement the algorithm, but guard against side-channel attacks. There are other things as well. All of which your system fails at without anyone having to look at the code. I am not going to take it down. Freedom, boys and girls, freedom. Good for you. Now if you actually want people to start looking at it, start with addressing my point (3). If you don’t make it easy for people to analyze your system, it is not going to receive the expert scrutiny required to meet some of the other criteria. But the concern is that there are software developers out there who don’t pay attention to the criteria that I listed. So, sure, go ahead and play with ideas. But please put some prominent notes that it hasn’t been evaluated and was designed by someone with no expertise, and so should only be used for playing around. And if you would like expert evaluation, you need to help those experts. There are lots of lone crackpots out there who think that they are lone geniuses. You are going to show that it isn’t a complete waste of experts time to look at your stuff. Cheers, -j J. I think it's great that you can look at this sort of thing from all angles. The security lies in data with a salt added to data which is rotated to the left by the length of bytes. I won't insult your intelligence by rehashing the formula as it is clearly written in the code. Errr... *which* code? Where? Sum total of what is published (that I could find) is: https://github.com/kjsisco/qode/blob/master/qode.au3 containing 5 lines: - qode An encryption algorithm - Perhaps you have missed the fact that you need to git push? Or is there some other location that I missed somewhere? W The point is, do you feel this provides the level of security that you desire? If the answer is no, in the trash can it goes! -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography Code: ;QODE(Quick Offline Data Encryption) ;by ;Kevin J. Sisco(kevinsisco61...@gmail.com ;provides strong encryption for data entered ;written in Autoit $i = Inputbox( , Enter data) $b = StringToBinary($i) ;convert to binary $s = StringToBinary(the data is now secure) ;salt $salt = $b+$s ;add salt to input $l = BinaryLen($b) ;length in bytes $br = BitRotate($b, $l) ;left bit rotation $x = BitXor($br, $l) ;xor of rotation and length $y = @YEAR ;current year $r = Random(20, 50)
[cryptography] The Wandering Music Band
Hi,
I am looking for some crypto primitive to solve a problem I have.
Assume that I meet a group of people. call it S. I get to talk to them a
bit, and
then they are gone.
This group of people walk together in the world. Sometimes they add a
person to
their group, and sometimes they remove one person. (You can assume it's a
music
band, then it all makes sense). Generally, though, you may assume that they
have
at least k people in the group at all times.
Assume that I meet the resulting group at some time in the future, after
many
members were added or removed. How can the new group S' prove to me that
they
are the descendants of the original group S?
I include here some of my thoughts about this.
1. Naive Solution: Remembering lots of signatures.
Every person in the world will have a key pair (of some asymmetric crypto)
to
represent his identity. When I first meet the group S, I collect all their
public keys and keep them.
Whenever a new member x is added to the group S, all the current members of
S
sign over the new list: S U {x}. Whenever a member x is removed from the
group
S, all the current members of S sign over the new list S \ {x}. The group
members always have to carry with them all the signatures since the
beginning of
time.
When I meet the group at some point in the future, I can just ask them to
prove
their current public keys, and also to show me all the signatures since the
beginning.
My issue with this solution is that the group has to remember more and more
signatures as time goes by. I wonder if there is a more efficient way.
2. Using Transitive Signatures
I have seen two articles about a concept called Transitive Signatures.
Shortly: Given a signature of x over y, and of y over z, any participant
will be
able to generate a signature where x signs over z.
http://people.csail.mit.edu/rivest/MicaliRivest-TransitiveSignatureSchemes.pdf
https://eprint.iacr.org/2004/215.pdf
I didn't manage to apply this method to my problem though.
I will appreciate any idea or hint about how to solve this.
Regards,
real.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 7 Jan 2015 15:55 -0500, from kevinsisco61...@gmail.com (Kevin): Code: ;QODE(Quick Offline Data Encryption) ;by ;Kevin J. Sisco(kevinsisco61...@gmail.com ;provides strong encryption for data entered ;written in Autoit $i = Inputbox( , Enter data) $b = StringToBinary($i) ;convert to binary $s = StringToBinary(the data is now secure) ;salt $salt = $b+$s ;add salt to input A salt isn't a part of the encryption algorithm, though it's often a part of a sane cryptosystem implementation. Take a look at for example RC4; it's been broken, but it's a _dead simple_ example of an encryption algorithm that for a long time stood the test of the community. (And it was designed by a well-known and well-renowned individual in the field of cryptography, who knows and knew the craft. Ever heard of RSA? One of those guys.) $l = BinaryLen($b) ;length in bytes $br = BitRotate($b, $l) ;left bit rotation So this is basically a Caesar cipher with the rotation amount equal to the plaintext length? If we assume for a second that the rotation is per-byte, that will be modulo eight anyway. I can try those eight combinations by hand if necessary; it'd probably be quicker than writing up a program to do it for me. Even if the rotation is bitwise over the entire plaintext input, the value is bounded by 8 * L, where L is the length in bytes of the plaintext input. For a full DVD (a little over 4 GiB), that value is about 32 billion, corresponding to right around 32 bits of key. Anything less than 128 bits of key is considered short, and 80 bits of key is considered breakable with some reasonable amount of effort by a determined attacker. Keep in mind that every single bit added to the key _doubles_ the attacker's effort, assuming a brute force mode of attack. $x = BitXor($br, $l) ;xor of rotation and length $y = @YEAR ;current year $r = Random(20, 50) ;random number $formula = $salt+$br+$x+$y+10+32+$r*100 ;formula Wait, _what!?!_ Back up a few lines above, you assigned $salt to _include a representation of the plaintext input!_ $t = $formula*$formula*$formula*Log($formula) ;total So, for some transformation f(x) on the plaintext (your $formula assignment), _the output of which includes x_, we have that the algorithm is f(x)^3 * log(f(x)). I'm not really up to looking at the math of that right now, and the intricacies will depend on exactly what Log() in your language is, but I'm willing to bet that there is a trivial transformation of that right back to _x_, at which point we essentially have the original plaintext input. There should _certainly_ be a trivial transformation back to $formula, which is essentially the same thing. There isn't even a key in there that I can see, only a salt (which is included in clear in the output once you allow for the Log()). $o = FileOpen(output.txt, 1) ;create output file FileWriteLine($o, $formula) ;store the result Doesn't this mean that in your implementation, since $formula includes $salt which includes $b which is a representation of $i (the original plaintext input), the output file will contain a copy of that representation of the input? Presumably, StringToBinary() is trivially reversible. FileFlush($o) ;flush buffer to disk FileClose($o) ;close the stream The above took me all of a few minutes to look over and write up (mostly slowed down by your rather odd code formatting, causing me to have to look back and forth several times). And _I am definitely not an expert in the field_ and _have never used the language you wrote it in_. I'm just a mostly random guy who happens to do _programming_ for a living and have an _interest_ in cryptography. If we may assume that writing $formula to the output file is a simple bug, and you meant to write $t instead (a very embarassing bug indeed, but one that does not affect the _cryptography_), then is the entire security of your algorithm in what you call the salt? Is it even in the _length_ of what you call the salt? If so, you should start out with some basic terminology: _salts are meant to be public_ and are generally used so that _two plaintexts *hash* to different outputs_ in order to thwart dictionary or rainbow table attacks on hash values. They are, roughly, the _hash_ equivalent of an initialization vector. Here is an exercise for you. Assume that an adversary has access to the full and complete details of your algorithm. Also assume that the same adversary can run as many encryption attempts as they want to, on any plaintext input they choose to. Assume that they have access to the _particular_ implementation that the entity attempting to secure communications uses, as well as a copy of the ciphertext of the communication. Under these circumstances, _what_ property of your algorithm provides guarantees of _confidentiality_ against reasonable effort on the part of the attacker? -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514
Re: [cryptography] QODE(quick offline data encryption)
On 7 Jan 2015 22:11 +, from mich...@kjorling.se (Michael Kjörling): Even if the rotation is bitwise over the entire plaintext input, the value is bounded by 8 * L, where L is the length in bytes of the plaintext input. For a full DVD (a little over 4 GiB), that value is about 32 billion, corresponding to right around 32 bits of key. Apologies for the noise, people; of course, 32e9 corresponds to about 35 bits of key. (log(32e9)/log(2) ~ 34.9) Stupid mistake of mine that I really should have caught in proofreading. Doesn't change the big picture, though; for these purposes, 32 = 35. -- Michael Kjörling • https://michael.kjorling.se • mich...@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
Den 7 jan 2015 22:14 skrev realcr rea...@gmail.com: Hey, Thank you for all the responses. I figured out that I left some important details out, probably because I thought about it for a long time. I'm sorry about that. I will try to formulate it again: Assume that the world contains correct people (People you can trust) and corrupt people (Those you can't trust). Also assume that the world has a majority of correct people (If it helps, you may assume 3/4 correct people). I am given a set S which contains k members (The music band). Assume that a majority of this set is correct. From time to time: - A random person (From the world) joins the band. (With good probability this new member is correct). - A random person (From the band) leaves the band. ( The band always have at least k people. It's the chain of signatures always published in an accessible way so that the original members can't doublespend and claim to be the task group? Otherwise the blockchain approach is useful for you. The Bitcoin blockchain solves the problem of trustlessly transferring ownership. The group setting is also solved as-is thanks to both the multisignature support (m-of-n for up to 15 people), and thanks to ECDSA threshold group signatures if you prefer these (I'm assuming they also don't limit you to 15 members). Group S_1 creates a colored coin by sending the smallest denomination of Bitcoin to an address created using the public keys of all current members (must not be mixed with other coins). The threshold is defined such that m must be larger than half of n (the size of the group). When any change is made, group S_2 is then created and the colored coin is sent to a new address created from the public keys of all members in this new group, and the threshold is adjusted if necessary. Keeping only the blockchain headers and asking Bitcoin nodes for the transactions following the original colored coin transaction (SPV security model), you can track it to the latest address, and thus to the latest version of the group, the current descendant (S_n). You can verify that the group member(s) you meet is indeed part of the current version of the group by asking them to sign a nonce as a challenge with their private key and show the rest of the public keys from the group (such that the Bitcoin address can be recreated, to verify his public key is part of the group). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/7/2015 5:19 PM, Michael Kjörling wrote: On 7 Jan 2015 22:11 +, from mich...@kjorling.se (Michael Kjörling): Even if the rotation is bitwise over the entire plaintext input, the value is bounded by 8 * L, where L is the length in bytes of the plaintext input. For a full DVD (a little over 4 GiB), that value is about 32 billion, corresponding to right around 32 bits of key. Apologies for the noise, people; of course, 32e9 corresponds to about 35 bits of key. (log(32e9)/log(2) ~ 34.9) Stupid mistake of mine that I really should have caught in proofreading. Doesn't change the big picture, though; for these purposes, 32 = 35. Great! You see at the verry least, we're getting some practice with these algorithms. I believe that this list is great for this. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE
On 01/06/2015 09:12 PM, Kevin wrote: I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode I find the reaction from the list somewhat surprising. Some years ago, I had a neighbour that was building a moon-landing spacecraft in his backyard. Obviously, he never landed on the moon, but he learned a whole lot of useful things: for instance, holding a hammer close to the head instead of at the end of the handle will not substantially reduce the likelihood of hitting the thumb. He did try to sell maiden-voyage seat reservations. I have no idea if he collected any money, but if he did, I would not blame him, I would blame those that coughed up their coin. Listo Factor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
On Wed, Jan 7, 2015 at 10:40 AM, realcr rea...@gmail.com wrote:
Hi,
I am looking for some crypto primitive to solve a problem I have.
Assume that I meet a group of people. call it S. I get to talk to them a
bit, and
then they are gone.
This group of people walk together in the world. Sometimes they add a person
to
their group, and sometimes they remove one person. (You can assume it's a
music
band, then it all makes sense). Generally, though, you may assume that they
have
at least k people in the group at all times.
Assume that I meet the resulting group at some time in the future, after
many
members were added or removed. How can the new group S' prove to me that
they
are the descendants of the original group S?
I think part of this will be more clearly defining what you mean by
the new group S'.
Let's say the original band (Kingdom Of Blight, a hardcore
death-metal band) is made up of Alice, Bob, Charlie, Dave and Eric.
Eric leaves (he claims Dave is stifling his creative potential, and
they are all becoming too commercial)
They then have a huge fight about whether or not the kazoo is a valid
instrument, and Alice and Bob split off to form More Kowbell and
Charlie and Dave form Sounds of the Mandolin, a band specializing in
English folk songs from 1820 to 1843.
Who are the actual group now? I'm assuming KoB was still the band
after Eric left? What about when A and B left?
After a while Charlie leaves Sounds of the Mandolin and joins More
Kowbell - now there is a group of 3 of the original 5. Are they now
the new group S'? (If so, I *think* a this is simply an M of N
problem, so Shamir's Secret Sharing should work.. maybe... )
I think what might be best (in the real world) is for:
A: the identity to be tied to the group name -- the real world has
experience with this, like who owns a sing / IPR / etc.
B: you give a physical object to the original group (like a signed
piece of paper, or unique Hello Kitty statue) and tell them that this
identifies them. They then have to fight amongst themselves to
determine who own it. This does of course mean that one of them could
steal the paper / statue and claim they are the group.
I think the problem is not well enough defined / the band analogy
hides too much of the actual requirements...
W
I include here some of my thoughts about this.
1. Naive Solution: Remembering lots of signatures.
Every person in the world will have a key pair (of some asymmetric crypto)
to
represent his identity. When I first meet the group S, I collect all their
public keys and keep them.
Whenever a new member x is added to the group S, all the current members of
S
sign over the new list: S U {x}. Whenever a member x is removed from the
group
S, all the current members of S sign over the new list S \ {x}. The group
members always have to carry with them all the signatures since the
beginning of
time.
When I meet the group at some point in the future, I can just ask them to
prove
their current public keys, and also to show me all the signatures since the
beginning.
My issue with this solution is that the group has to remember more and more
signatures as time goes by. I wonder if there is a more efficient way.
2. Using Transitive Signatures
I have seen two articles about a concept called Transitive Signatures.
Shortly: Given a signature of x over y, and of y over z, any participant
will be
able to generate a signature where x signs over z.
http://people.csail.mit.edu/rivest/MicaliRivest-TransitiveSignatureSchemes.pdf
https://eprint.iacr.org/2004/215.pdf
I didn't manage to apply this method to my problem though.
I will appreciate any idea or hint about how to solve this.
Regards,
real.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
On Wed, 7 Jan 2015, realcr wrote: I am looking for some crypto primitive to solve a problem I have. [...] Fascinating... If it helps, I know a couple of musos who are in that position, and also have a geeky bent, so I'll pass along anything that they may have to say. Deep Purple would have some difficulty, of course (I think Jon Lord was the last founding member, and he left), but Led Zeppelin would have no problem (when Bonzo dropped out, so did they, but Jason -- his son -- has done a gig or two since then). I guess, if it is really a band application as opposed to something more abstract, it boils down to what you mean by descendants. At least one founding member left? Are the offspring of same OK? Some musos can be really purist about this. -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/6/2015 6:25 PM, John Young wrote: At 04:55 PM 1/6/2015, you wrote: Yes, that is the received canon of cryptosystems: 1.Sarcasm toward unqualified efforts, 2. Designing cryptosysystems is *hard*. 3. No, that's too mild, it's mindblowingly* hard. 4. It doesn't start with code, it strts with mathematical description. 5. No, even that is not true, it starts with years of study. 6. Denizens of this list have seen a hundred cryptosystems crash and burn. 7. Some of them designed by very clever people. 8. Designing crytposystems is hard. 9. Don't even think of trying it, not unless a fewyears spent studying the state of the art. 10. Sorry to be blunt. Not to mention how often thclaims are made despite thier sounding like alchemy and astrology, cultish, religious, authoritarian, scientistic, recruitment for arcane pursuit of unsolvable mysteries, and hardly applicable to the long and varied history of cryptology suffused with bizarre claims, subterfuge, deception, betrayal, treachery, obligatory prevarication, inherent cheating, diabolical misrepresentation of trustworthiness, venomous accusations against competitors, unrestrained dupery and duplicity against the unwary, citizen and royalty alike. Nor that mathematics is a modern innovation in cryptology and remains its weakest element due to inability of its applicators to wed it to code and hardware without recourse to alchemy and astrology favored by promoters, sales and PhDs who dream of math as golden key to natsec. QODE, QED. Kevin wrote: I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode If you feel overwhelmed by the sarcasm directed your way, there is a reason for that. Designing cryptosystems is *hard*. No, that's too mild. Is *mindblowingly* hard. It doesn't start with code. It starts with a mathematical description. No, even that is not true: It starts with years and years of study. The denisens of this list have seen a hundred cryptosystem crash and burn. Some of them were designed by very clever people. Did I mention that designing cryptosystems is hard? Don't even think of trying it, not unless you have first spent a few years studying the state of the art. Sorry to be so blunt, but I think it will save you a whole lot of grief. – Harald ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography /x-flowed ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography I agree with most of what you have said but I take issue with your one point: don't ever think of trying it... I know I'm paraphrasing that but even thinking that discourages people from bothering to secure anything. Not to sound like a crybaby but that's counter productive. It's just as counterproductive as giving everyone a pat on the back just for the sake of boosting morale, however. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
here's what you have so far: qode An encryption algorithm shall we conclude this thread now? On Wed, Jan 7, 2015 at 12:26 PM, Kevin kevinsisco61...@gmail.com wrote: On 1/6/2015 6:32 PM, shawn wilson wrote: So the practical reason behind everyone saying unless you have qualifications, etc, don't do this is because, even if you make something and say it's just for your learning or a joke or w/e, someone (no joke) *will* use it and then some Fortune 500 will fall over because of your joke code. So, yeah, don't do this - as in, it'd be best to take it down for everyone's sanity. On Tue, Jan 6, 2015 at 6:25 PM, John Young j...@pipeline.com wrote: At 04:55 PM 1/6/2015, you wrote: Yes, that is the received canon of cryptosystems: 1.Sarcasm toward unqualified efforts, 2. Designing cryptosysystems is *hard*. 3. No, that's too mild, it's mindblowingly* hard. 4. It doesn't start with code, it strts with mathematical description. 5. No, even that is not true, it starts with years of study. 6. Denizens of this list have seen a hundred cryptosystems crash and burn. 7. Some of them designed by very clever people. 8. Designing crytposystems is hard. 9. Don't even think of trying it, not unless a fewyears spent studying the state of the art. 10. Sorry to be blunt. Not to mention how often thclaims are made despite thier sounding like alchemy and astrology, cultish, religious, authoritarian, scientistic, recruitment for arcane pursuit of unsolvable mysteries, and hardly applicable to the long and varied history of cryptology suffused with bizarre claims, subterfuge, deception, betrayal, treachery, obligatory prevarication, inherent cheating, diabolical misrepresentation of trustworthiness, venomous accusations against competitors, unrestrained dupery and duplicity against the unwary, citizen and royalty alike. Nor that mathematics is a modern innovation in cryptology and remains its weakest element due to inability of its applicators to wed it to code and hardware without recourse to alchemy and astrology favored by promoters, sales and PhDs who dream of math as golden key to natsec. QODE, QED. Kevin wrote: I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode If you feel overwhelmed by the sarcasm directed your way, there is a reason for that. Designing cryptosystems is *hard*. No, that's too mild. Is *mindblowingly* hard. It doesn't start with code. It starts with a mathematical description. No, even that is not true: It starts with years and years of study. The denisens of this list have seen a hundred cryptosystem crash and burn. Some of them were designed by very clever people. Did I mention that designing cryptosystems is hard? Don't even think of trying it, not unless you have first spent a few years studying the state of the art. Sorry to be so blunt, but I think it will save you a whole lot of grief. – Harald ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography /x-flowed ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography Any company could review it and decide if it's worth using or not. Quite frankly, if you wanted to print out my code and wipe your rear end with it, that's fine by me. Use it, don't use it, laugh at it, don't laugh at it. I am not going to take it down. Freedom, boys and girls, freedom. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/6/2015 6:32 PM, shawn wilson wrote: So the practical reason behind everyone saying unless you have qualifications, etc, don't do this is because, even if you make something and say it's just for your learning or a joke or w/e, someone (no joke) *will* use it and then some Fortune 500 will fall over because of your joke code. So, yeah, don't do this - as in, it'd be best to take it down for everyone's sanity. On Tue, Jan 6, 2015 at 6:25 PM, John Young j...@pipeline.com wrote: At 04:55 PM 1/6/2015, you wrote: Yes, that is the received canon of cryptosystems: 1.Sarcasm toward unqualified efforts, 2. Designing cryptosysystems is *hard*. 3. No, that's too mild, it's mindblowingly* hard. 4. It doesn't start with code, it strts with mathematical description. 5. No, even that is not true, it starts with years of study. 6. Denizens of this list have seen a hundred cryptosystems crash and burn. 7. Some of them designed by very clever people. 8. Designing crytposystems is hard. 9. Don't even think of trying it, not unless a fewyears spent studying the state of the art. 10. Sorry to be blunt. Not to mention how often thclaims are made despite thier sounding like alchemy and astrology, cultish, religious, authoritarian, scientistic, recruitment for arcane pursuit of unsolvable mysteries, and hardly applicable to the long and varied history of cryptology suffused with bizarre claims, subterfuge, deception, betrayal, treachery, obligatory prevarication, inherent cheating, diabolical misrepresentation of trustworthiness, venomous accusations against competitors, unrestrained dupery and duplicity against the unwary, citizen and royalty alike. Nor that mathematics is a modern innovation in cryptology and remains its weakest element due to inability of its applicators to wed it to code and hardware without recourse to alchemy and astrology favored by promoters, sales and PhDs who dream of math as golden key to natsec. QODE, QED. Kevin wrote: I figured I'd start building my own open source encryption algorithm: https://github.com/kjsisco/qode If you feel overwhelmed by the sarcasm directed your way, there is a reason for that. Designing cryptosystems is *hard*. No, that's too mild. Is *mindblowingly* hard. It doesn't start with code. It starts with a mathematical description. No, even that is not true: It starts with years and years of study. The denisens of this list have seen a hundred cryptosystem crash and burn. Some of them were designed by very clever people. Did I mention that designing cryptosystems is hard? Don't even think of trying it, not unless you have first spent a few years studying the state of the art. Sorry to be so blunt, but I think it will save you a whole lot of grief. – Harald ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography /x-flowed ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography Any company could review it and decide if it's worth using or not. Quite frankly, if you wanted to print out my code and wipe your rear end with it, that's fine by me. Use it, don't use it, laugh at it, don't laugh at it. I am not going to take it down. Freedom, boys and girls, freedom. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On Wed, Jan 7, 2015 at 1:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Ok, lets run with that - as a company, show me the steps (make file, a test suite in any programming language, or just english if you prefer), explain to me the steps one would go through to verify your crypto isn't battshit crazy? There have discussions about frameworks to test crypto on this list and iirc a few exist but I haven't gone though the time to figure out how to implement something. So, if you (or anyone else) has a verification method, I'm all ears. And, I'm not the smartest one (on this list or even the smartest sysadmin) but if I don't know, I wouldn't expect at least the majority of other devs/admins to know how to verify your crypto past the simplest code review (I wouldn't have a clue how to besides fuzzing some stuff from the outside). Hence I say, it's a mistake to publish any toy you want to call crypto. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
On 1/7/2015 1:46 PM, shawn wilson wrote: On Wed, Jan 7, 2015 at 1:26 PM, Kevin kevinsisco61...@gmail.com wrote: Any company could review it and decide if it's worth using or not. Ok, lets run with that - as a company, show me the steps (make file, a test suite in any programming language, or just english if you prefer), explain to me the steps one would go through to verify your crypto isn't battshit crazy? There have discussions about frameworks to test crypto on this list and iirc a few exist but I haven't gone though the time to figure out how to implement something. So, if you (or anyone else) has a verification method, I'm all ears. And, I'm not the smartest one (on this list or even the smartest sysadmin) but if I don't know, I wouldn't expect at least the majority of other devs/admins to know how to verify your crypto past the simplest code review (I wouldn't have a clue how to besides fuzzing some stuff from the outside). Hence I say, it's a mistake to publish any toy you want to call crypto. Surely a company would pay top dollar to protect itself. Oh and let's not rule out good sense. If you feel in your gut that you can't trust something, that probably is a good instinct. As a security nut I use this policy and it works for me. -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Wandering Music Band
On Thu, Jan 08, 2015 at 03:33:24AM +1100, Dave Horsfall wrote: On Wed, 7 Jan 2015, realcr wrote: I am looking for some crypto primitive to solve a problem I have. [...] I guess, if it is really a band application as opposed to something more abstract, it boils down to what you mean by descendants. At least one founding member left? Are the offspring of same OK? Some musos can be really purist about this. i'd suggest that you can assume that there is always a majority of members who can be trusted. so you need something that can follow a trusted majority, even if they include no-one who is original. fwiw, when searching for previous work, this kind of problem is often referred to as the ship of theseus (preserving identity of the whole when all parts are replaced) - http://en.wikipedia.org/wiki/Ship_of_Theseus andrew ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
