Re: [cryptography] QODE(quick offline data encryption)
On Tue, Jan 6, 2015 at 4:12 PM, Kevin wrote: > I figured I'd start building my own open source encryption algorithm: ... 'cos that can only end well? > https://github.com/kjsisco/qode The entire contents of which is: --- qode An encryption algorithm > > -- > Kevin > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. Phew. Well, that's a relief... W > 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] QODE(quick offline data encryption)
yeah thx bra! On Tue, Jan 6, 2015 at 3:25 PM, Warren Kumari wrote: > On Tue, Jan 6, 2015 at 4:12 PM, Kevin wrote: > > I figured I'd start building my own open source encryption algorithm: > > ... 'cos that can only end well? > > > https://github.com/kjsisco/qode > > The entire contents of which is: > > --- > > qode > > > An encryption algorithm > > > > > > > > > > -- > > Kevin > > > > > > --- > > This email is free from viruses and malware because avast! Antivirus > > protection is active. > > Phew. Well, that's a relief... > > W > > > 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 > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
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
Re: [cryptography] QODE(quick offline data encryption)
On 6 Jan 2015 16:12 -0500, from kevinsisco61...@gmail.com (Kevin): > I figured I'd start building my own open source encryption algorithm: > https://github.com/kjsisco/qode To borrow a very apt quote from Bruce Schneier: "Who the hell are you?" [1] [2] Nobody is perfect. Even very clever people make mistakes when designing encryption algorithms. Sometimes they are unaware of particular attacks which turned the believed-secure algorithm into a trivially breakable entropy-reducing mess. Other times cryptographic advancements make previously infeasibly breakable algorithms feasibly breakable. Yet other times pure computing power did. Sometimes those same smart people come up which believed secure schemes that are trivially breakable by anyone with the right knowledge. [3] Which leads us back to the question: who are you? What are your credentials in the field of cryptography? Why should we trust _your_ algorithm over something designed by people with an established track record in the field? And also, _what problems_ do you see with current algorithms which you are attempting to solve, and _how_ do you intend to solve those problems? This is not meant to be sarcastic at all. Homegrown algorithms tend to fall very quickly to even a modicum of competent analysis. If you want the community to take your algorithm proposal (whatever it might be) seriously, then you need to show why the community should take it seriously. I once believed I had come up with a great encryption algorithm. Thankfully, it never saw any use beyond a few toy programs which I never distributed to anyone else. [1] https://www.schneier.com/crypto-gram-0608.html#7 [2] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html [3] http://ftp.pgpi.org/pub/pgp/2.x/doc/pgpdoc1.txt section "Beware of Snake Oil" -- 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] QODE(quick offline data encryption)
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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
Are you going to do this using recognised and proven primitives and procedures (within the bounds of current knowledge) or create something entirely new ? Very different beasts... On 07/01/2015 04:12, Kevin wrote: > I figured I'd start building my own open source encryption algorithm: > https://github.com/kjsisco/qode > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
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 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 > > > > ___ > 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)
If it's so foolish to build your own crypto, how foolish would a Fortune 500 company be to deploy it? Too bad there's not a crypto hacker service to test out various crypto algorithms. We're always told to trust the government-sponsored crypto like AES when we know full well that governments are not trustworthy. All crypto looks secure ;-) On 1/6/15 1: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 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 ___ 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
The confidence in AES comes from its designation process during which many publicly tried and failed to convincingly reduce its security claim and the fact that it has (publicly still) stood the test of time : ten years later all we have are the bicliques which gains us 2 bits. It doesn't have much to do with the fact that it is state sponsored ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] QODE(quick offline data encryption)
Just use XXTEA. It's the only good cipher that allows for blocks of size equal to that of a disk sector. Additionally, maybe use XXTEA in CTR mode to provide additional confidentiality so that blocks with all zeroes won't output to the same value. On Tue, Jan 6, 2015 at 1:12 PM, Kevin wrote: > I figured I'd start building my own open source encryption algorithm: > https://github.com/kjsisco/qode > > -- > 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 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(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 ___ 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)
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 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 ___ 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)
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 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 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 >>> >>> >>> ___ >>> 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 Wed, Jan 7, 2015 at 1:26 PM, Kevin 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 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] QODE(quick offline data encryption)
On 2015-01-07, at 12:26 PM, Kevin 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 smime.p7s Description: S/MIME cryptographic signature ___ 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 wrote: > On 2015-01-07, at 12:26 PM, Kevin 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 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:05 PM, shawn wilson wrote: On Wed, Jan 7, 2015 at 2:40 PM, Jeffrey Goldberg wrote: On 2015-01-07, at 12:26 PM, Kevin 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 wrote: > On 1/7/2015 2:40 PM, Jeffrey Goldberg wrote: >> >> On 2015-01-07, at 12:26 PM, Kevin 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 ___ cryptogra
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 wrote:
On 1/7/2015 2:40 PM, Jeffrey Goldberg wrote:
On 2015-01-07, at 12:26 PM, Kevin 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)
;random number
$formula = $salt+$br+$x+$y+10+
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
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] 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(quick offline data encryption)
On 7 Jan 2015 20:31 -0500, from kevinsisco61...@gmail.com (Kevin): > Great! You see at the verry least, we're getting some practice with > these algorithms. I believe that this list is great for this. You didn't answer my questions. -- 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
