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)
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 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
We all know that randomness is required for good crypto, but what is the a measurable difference in the quality of the crypto if using a Linux PRNG (or in our case the Java SecureRandom PRNG)? How much easier is it to crack an encrypted file done with such weaker PRNGs compared to the hardware RNGs, especially if it's so hard to determine the quality of the randomness. On Tue, Aug 20, 2013 at 4:10 PM, James A. Donald jam...@echeque.com wrote: On 2013-08-21 7:33 AM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? __**_ You cannot test and evaluate a supposedly random number stream. True randomness and cryptographically strong pseudo randomness are not directly observable qualities. You have to look at the underlying generation mechanism and deduce randomness, or the lack thereof. If you apply a whitening expander to the source stream 000 the output stream will look convincingly random, but will be completely non random to anyone who knows the whitening expander and knows or suspects that the source stream is completely non random __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Interesting Webcrypto question
The entire idea that such countries don't have strong crypto because of the export restrictions is goofy. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] any reason to prefer one java crypto library over another
DIY may be okay for those who are very skilled, but the general rule is to use proven libraries and not write your own. If you code in Java like we do, we really like the BouncyCastle library (for over a decade) and have no issue with their JCE since we do the installations and it's not a big deal to add the JCE policy files for strong encryption in our case. I am sure it can be an issue if you had to deal with users doing the installation, but that's not our case. Good luck! On Thu, Feb 7, 2013 at 2:58 PM, travis+ml-rbcryptogra...@subspacefield.orgwrote: On Wed, Jan 30, 2013 at 12:01:24PM +0300, ianG wrote: So my message is: DIY crypto rocks [5]. JCE/provider crypto is so not the answer I've forgotten what the question is. With Java in particular, life is very bipolar, there is such a gulf between the bureaucracy of the Oracle and the anarchy of DIY that neither side recognises the other. Well, an entertaining story and reasonable if you have a single app and crypto-programmer expert such as yourself willing to do write the code. I certainly understand the frustration of not having any library which conforms to one's preferred design, and have rewritten many a library in my time, though perhaps not as many as you :-) Unfortunately, I have hundreds of apps to worry about, I don't trust the average developer to write crypto code (hot glass looks just like cold glass to an outside observer), and I don't have the time to do it myself. Standardizing on custom crypto for every app of our hundreds isn't going to scale, either; I wouldn't even have the time to review all the code, even if it were written correctly the first time with no instruction. So I suppose I'm stuck with the lesser of N evils (or perhaps the evil of N lessers). Which of course brings me to the question of which evil that actually is. And perhaps another meta question is, why are there no satisfactory libraries? Is it a technical reason or a market-based reason, or does everyone just have divergent tastes in how their crypto is served? -- http://www.subspacefield.org/~travis/ Nil nisi clavis deest ___ 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
