Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
I know you should never make your own cryptography, whether it is a cipher or hashing algorithm or even a secure pseudo random number generator these things I developed over a long standardisation process. However what I'm looking for quotes or good point in order to quickly describe/argue this to the occasional developer that decides to write their own cryptographic algorithm.
You can tell this developer that existing algorithms such as AES have been analyzed by countless experts in cryptanalysis (which would certainly involve an advanced understanding of numbers and computer science) and tested in competitions, where there's a real incentive for creating secure algorithms.
You can also tell this developer that just because an algorithm is popular, it doesn't mean that it's insecure (if that was this developer's rationale). Just because lots of people know how door locks work doesn't make door locks insecure, nor is it a good justification for people to create their own door locks.
For a real world example, see this TDWTF article about Nintendo's bug in the Wii's security functions. Nintendo (a big, well-known company with plenty of programmers) tried to implement an existing algorithm and managed to screw that up. What makes this developer think that he/she has the l33t h4x0r skills to write a new, secure algorithm?
Anyone who thinks they have devised an
unbreakable encryption scheme either
is an incredibly rare genius or is
naive and inexperienced.
Unfortunately, I sometimes have to
deal with would-be cryptographers who
want to make "improvements" to PGP by
adding encryption algorithms of their
own design.
I remember a conversation in 1991 with
Brian Snow, a highly placed senior
cryptographer with the NSA. He said he
would never trust an encryption
algorithm designed by someone who had
not "earned their bones" by first
spending a lot of time cracking codes.
That made a lot of sense. I observed
that practically no one in the
commercial world of cryptography
qualifies under this criterion. "Yes,"
he said with a self-assured smile,
"And that makes our job at NSA so much
easier." A chilling thought. I didn't
qualify either.
Philip Zimmermann, Beware of Snake Oil
Just tell them that unless they have several decades of experience in math, computer science and cryptography, and then a few years to design the algorithm, it is highly unlikely that they will be able to produce a better cryptographic encryption scheme than the ones that already are in widespread use, all of which have been worked on by a lot of people, many of which almost definitely have the background I described above.
Point the non-believer to these URL's:
Security Pitfalls in Cryptography By Bruce Schneier
Cryptography from princeton.edu
Homebrew Cryptography
Wikipedia Article on Cryptanalysis
As others have mentioned, you can use just about anything that Bruce Schneier says as a quote! He frequently mentions that anyone can create a cipher that he or she cannot break. He's expounded on this in detail but I can't find the article atm, but here's some essays of his that touch on this area:
Why the Worst Cryptography is in the Systems that Pass Initial Analysis
So, You Want to be a Cryptographer
yes thats true.. but all in all encryption is scrambling and substitution. so you can make your own cipher easily.. scramble your text using basic XOR and use a dictionary for substitute.
http://en.wikipedia.org/wiki/XOR_cipher
Hope this can help
Regards.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
This is not one of the myriad of questions already on SO
What is a monad?
Monad in plain English? (For the OOP programmer with no FP background)
A monad is just a monoid in the category of endofunctors, what's the problem?
Rather it's a question on the answers themselves. As of today there are ~269,000 Google results for the query what is a monad in functional programming?, a ton of attempts to explain here and on the web with analogies ranging from burritos to love affairs. It seems that every attempt to "simply" answer turns into a labyrinth, each analogy becoming more confusing than the next. I could be wrong but it seems to me that this phenomenon is unique to monads.
Many have tried, few have succeeded
What is it about monads that makes explaining them so tempting but so elusive?
I think it's one of those few abstractions in mathematics or programming that has no clear metaphor with the real world.
For that reason, all those articles that attempt to compare monads to burritos fail because a monad is not something that corresponds to human experience.
This seems to confuse many people, because they have the built-in expectation that every abstract concept has a root in something 'real. For instance, monoids (not monads) are things that you can 'smash together', like adding or multiplying numbers, or concatenating lists.
It seems to me that monads are more like quantum mechanics or relativity theory. Any attempt at explaining them using the human experience fails, because they're outside of natural experience.
Like quantum mechanics or relativity, though, they're actually not that hard to understand. (To be fair, I only have high-school understanding of both of these, but as I recall, once you see the formulas, they aren't that hard to understand.)
My experience with teaching monads is exactly that it works best if you dispense with all attempts at making the concept digestible by comparing it to something from the real world.
Instead, I start by explaining functors, which are a little easier to get across. Once people grasp functors, I tell them that monads are just functors that you can 'flatten'. There's no metaphor or simile here - just the 'raw' abstraction.
I also tell people to do some exercises to get familiar with these abstractions, just as it helps looking at the proofs and formulas when trying to understand (basic) quantum mechanics and special relativity theory.
It still typically takes some days (or weeks) of exercises before the concept of functors and monads click for people, but in my experience, the best teaching strategy is to realise that there's no direct metaphor from the real world that helps. Rather, teaching the 'raw' formula makes things easier.
In short, monads are hard to explain because we've yet to identify anything in the human experience that corresponds to this useful abstraction. This is, in my opinion, comparable to quantum mechanics or relativity theory. Our brains are evolved to deal with what we can perceive, and just like we don't perceive picometer-scale things or speeds close to the speed of light, we don't usually experience anything reminiscent of monads.
That doesn't mean that they aren't real, though.
I don't know much about the heavy math behind cryptosystems, I get stuck when it gets bad with the Z/nZ algebra, and sometimes with all these exponent of exponents. It's not I don't like it, it's just that the information you find on the web are not easy to follow blindly.
I was wondering: how reliable can a algorithm be when it encodes a message into plain binary. If my algorithm is arbitrary and known only to me, how can a cryptanalist study an encrypted file and decrypt it, with or without having the decoded file ?
I'm thinking about not using ASCII text to code my message, and I have some ideas to make this algorithm/program.
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him, but how does he do then ?
I don't know if I understanded well, but a CS teacher once told me that codes are harder to crack that crypted ciphers.
What do you think ?
Attacking a AES or blowfish crypted file is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with is unknown to him...
What about:
Attacking an untested self written algorithm with no real research is more trivial for a cryptanalyst, than if the algorithm the file is encrypted with, is a well known and proofed one, that has been correctly used....
In short, DO NOT roll your own cryptography unless you're an expert, no unless you're part of an expert group in that field.
Nintendo failed when they implemented RSA on their own in the Wii, Sony failed too when using it in the PS3 (they pretty much used XKCD's random number function for M...)
And you really think you can win by using security by obscurity?
PS: That doesn't mean that you should take the Wikipedia entry on RSA and roll you own implementation from that one (that's exactly were Sony and Big-N failed), no use a tested, open source implementation.
You seem to be using two words interchangeably but remember that Encoding is Not Encryption
When the attacker has no idea which algorithm you used and it is safe, cryptoanalyst has a hard job. So it is unimportant if you use AES or your own cipher as long as it is as strong and safe as AES. Here is the but. Cryptography is a bit demanding and therefore you have many ways to shoot yourself in a foot without knowing it. I would suggest using standard algorithms, maybe with some safe variations.
Common wisdom is that you should not build your own algorithms, and especially not rely on these algorithms remaining secret.
The conceptual reason is that good encryption is about quantified confidentiality. We do not want our secrets to get cracked, but in a more precise way we want to be able to tell how much it would cost to crack our secrets (and hopefully show that the cost is way too high to be envisioned by any entity on Earth). This is the real advance which occurred a few years after World War II: to understand the distinction between key and algorithm. The key concentrates the secret. The algorithm becomes the implementation.
Since the implementation is, well, implemented, it exists as some code or a device, which is tangible and stored even when it is not used. Keeping an implementation secret requires keeping track of the hard disk on which the code resides at all times. If the attacker sees the binary code, he may be able to reverse-engineer it, something which depends on his wits and patience. The point here is that it is very difficult to be able to say: "it costs X dollars to recover a description of the algorithm".
On the other hand, the key is short. It can be stored safely much more easily; e.g. you could memorize it, and avoid committing it to any permanent storage device. You then have to worry about your key only at times when you use it (and not when you do not, e.g. in the middle of the night, when you sleep). The number of possible keys is a simple mathematical problem. You can easily and accurately estimate the average cost of enumerating the possible keys until your key is found. The key is a sturdy foundation for quantified security.
So you should not roll your own algorithms because then you do not know how much security you get.
Also, most people who rolled their own algorithms found out, usually the hard way, that they did not get much security at all. Designing a good encryption algorithm is hard, because it cannot be automatically tested. Your code may run, and properly decrypt data that it encrypted, but it tells you nothing about how secure the algorithm is. The design of the AES was the result of a process which took several years and involved hundreds of skilled cryptographers (most of whom had a PhD and years of experience in academic research on symmetric encryption). That a lone developer could do as well, let alone better, in the secrecy of his own workshop, looks kind of... implausible.
The biggest part of your strategy is called "security through obscurity." You're making the gamble that, since nobody knows the precise details of your little variation on an idea, they won't be able to figure it out.
I'm not a security expert, but I can tell you that you probably won't come up with something incredibly new. Cryptography has been studied by people for millenia and your idea is highly unlikely to be original. Even if you're a relatively good programmer and code something really tricky, the question will come down to who you're up against. If you're just trying to protect your data from your kid sister, then it will probably be fine. On the other hand, if you're using it to send credit card numbers across the internet, then you're doomed to fail. It will be analysed in ways you didn't think of or don't know, and ultimately cracked.
Another way to think of it: algorithms like AES have been extensively studied by professionals in the field and its level of security is pretty well understood. Anything you come up with by yourself will not have the benefit of having been attacked by the best and brightest minds out there. You will have almost no idea of how good it actually is until people start reporting identity theft.
Although I might pretend very well that I know a thing about networks or security and it might help me pass an interview or fix a bug, I don't really feel I'm fooling anyone.
I'm looking for laymen explanation of current network security concepts and solutions. The information is scattered around and I didn't find a resource for "dummies" like me (e.g experienced Java developers that can speak the jargon but have no real clue what it means).
Topics I have a weak notion about and want to understand better as a Java developer:
PGP
Public / Private keys
RSA / DES
SSL and 2 way SSL (keystore / trustore)
Protecting against Man in the middle fraud
Digital Signature and Certificates
Is there a resource out there that really explains it in a way that doesn't require a Cisco certificate / Linux lingo / know what is subnet masking or other plumbing skills?
The book Cryptography Engineering by Ferguson, Schneier, and Kohno might be something that would get you a decent way down the road to understanding the topics you listed. I read the first version of this book (Practical Cryptography) and found it to be quite good. For example, I thought the descriptions of public key/private key cryptography to be reasonably straightforward to understand.
It might not explicitly describe the specific terms in all cases that you are asking about. For example, I just looked in the index of my copy of Practical Cryptography and do not see the terms "keystore" and "truststore", but the first google hit I clicked on for those provided a definition in language I understood (largely because I read the book).
I also own Applied Cryptography mentioned by Aidan Cully, and I think it is also a very good book and certainly worth owning. However I tend to think of it more as a reference book (although somewhat dated - the copyright is 1996). In terms of real-word advice, though, I think the original title of the newer book Practical Cryptography was right on. The book seems, well, practical.
Schneier's Applied Cryptography is how I learned most of what I know. I haven't read it, but expect Ross Anderson's Security Engineering would also be a good resource.
Priactical UNIX and Internet Security will cover a lot of that stuff and give you a basic UNIX background. Also, if you have extra time Academic Earth has free video lectures from top universities.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I work with scrum about 2 months and don’t have all the experience I wish, so I would like to hear some inputs about it.
My concern is people never say about drawbacks for the two sides; company and workers.
I know the benefits of a cross-functional team but which are the drawbacks? What is hidden beside the amazing Eden Garden?
I'm confused because as a company benefits of replaceable people, for the team is good because the opportunity of having knowledge and share experience (besides all teamwork benefit).
Again, I know all the benefits but I want explore the drawbacks just because in the middle there are the ordinary people.
Normally these people dedicate heavily to gain knowledge. They buy books, courses, attending seminar and so on.
In every company when someone knows much more than everyone else, people and managers get desperate wishing or even demanding that these ordinary people share all their knowledge.
And that’s strange.. Because these are communism thoughts and we live in capitalism society and since I was born, everything was so competed and now people say about collaborative.
Can Scrum and Lean principles ruins (or making hard) the professionals' life?
Scrum and Lean, in and of themselves, cannot ruin anybody's life. Nor can they, alone, make your life.
The culture of your organization will always be a far more dominant factor than the particular product management or development management method in place. Scrum can be misused. Lean can indeed make workers feel replaceable and pressured to perform all day, all the time.
On the other hand, both tools (they are just tools) can be used to create high-performing teams where all members value each other and each others' contributions. Being on a team that delivers consistently good results at high velocity feels great.
You will also find every result in between. It depends much more on culture than process.
I believe that culture flows from the top. Therefore, look at how the company leaders treat each other, their subordinates, their vendors, and their customers. That will tell you much more about what your life will be like than which methodology the company follows.
I'm only going to address your comments about sharing knowledge reducing your own value. In an ideal team culture, knowledge itself isn't as valued as someone's ability to acquire new knowledge and solve problems they haven't seen before. When I think about the star engineers I have known, it's not because they know this or that, it's because it's obvious they could be on nearly any task, on nearly any team and they would both begin to solve the problem and raise the level of the entire team.
There are a few things I've seen from agile methodologies which I'd put against it when you're weighing it up.
From a developers perspective there are two things:
1) The short sprints often lead to short term decisions - which is as intended but can be frustrating for some developers. While delivering "just enough" is great for the project, asking a developer to do something that they know that they're going to have to very heavily refactor, if not rewrite, two sprints down the line can be demotivating.
2) Where you've got opinionated developers (and is there any other sort) I've seen conflict over prioritisation. Adding not only what should be done but how important it is and therefore when it should be done brings on a whole other level of disagreement. In theory the developers don't have a say here but hard delination never works.
From a management point of view they don't like the uncertainty. "When's it going to be ready?" "No idea, when we get to the point you say you're happy". Essentially for them it's a leap of faith - if they do it once then generally they're sold but getting them to do the first time is hard.
I will assume, that as one commentator suggested, you meant to ask: "What are the drawbacks of Scrum?"
I think that the biggest problem with Scrum is that it is easy to understand - but very difficult to implement properly. Scrum, like XP, like most methodologies is not built on individual atomic practices, each capable of improving an existing process.
Scrum requires a shift in the organizational mindset. It requires a shift from ego-centric to communal behavior. The entire organization should focus on bringing the most value, constantly, and do so over perceived self-interest.
For example, a cross-functional team member may be required to do things out of his comfort zone (the flip-side of being able to experiment with new interesting tasks), because it needs to be done by somebody.
Team Leaders and project managers need to relinquish authority when they are called to take on the role of servant-leaders, and when they are asked to stop telling team-members which tasks to pick, instead relying on the team to manage itself.
Stakeholders are forced to face the reality that they can't eat the cake, and have it whole, when they are forced to choose between having all of the scope they want or having it by the date they want it done (this is always true, but Scrum is really in-your-face about it).
Most of all, the drawback of Scrum, is its tendency to disillusion beginning practitioners. This comes from people expecting something from it that it can't deliver: A solution to their problems!
That's right! Scrum does not solve an organizations problems. It highlights them. It is up to the organization to step up to the bat and do something about them. Incidentally, this is done with what I consider to be the single most important ceremony of Scrum - The Retrospective! If you do nothing else in Scrum - do the retrospective:
Find out what you did well, and continue doing it.
Find out what you need to improve and do something to improve it.
Rinse and repeat!
In a presentation by Ken Schwaber to Google on Scrum, he once said that Scrum isn't necessarily good for the organization. It could tell you early on that your project is doomed to fail. If you avoid Scrum, you may have a few more months of ignorant bliss to prepare you for the day you lose your job. Funny, but true. Think on that.
Hope it helps,
Assaf.
I'm no expert in any particular methodology (Agile, Scrum, etc.) but I empathize with your feelings. One of the biggest issues I've seen is that a team that really isn't interested almost unanimously in the methodology will tend to have problems. A few outliers isn't a problem, but if 1/3 or more of the team isn't interested, it becomes a nightmare. Writing good software is important and a company should hire professionals that help them meet that goal, but if the team is forced to meet that objective without finding the experience rewarding the quality will soon drop off.
No, I don't think it will ruin your professional life, but it can be pretty miserable if a company is pig-headed and doesn't realize that they need an environment where their workers are finding rewarding work.
I'm not totally sure of the question because it was kind of hard to follow.
Basically... no? I fail to see how an agile principle could 'ruin a professionals' life'... if implemented incorrectly it could waste some of their time, meaning a small lack of experience gained. Other than that, if the methodology fits the business and is implemented correctly, then is is a powerful tool that is useful to everybody.
Any methodology only works if the people are competent.
Silly question imo.
I've certainly seen things packaged as Scrum and Lean make the development process more difficult. Usually the result of managers picking and choosing the aspects that support their purpose, without buying in to the underlying spirit. Any process can work if properly applied, and process can fail if applied poorly.
Cross-functionality isn't a means to make people replaceable. It's a means to solve flow bottleneck problems that decrease productivity.
Cross-functionality doesn't mean that everyone can do everyone else's job, it means that people are capable of assisting with the work step that come (immediately) before their work or (immediately) after their work.
A better term for this is "Local Generalization", or "Special Generalization". And again, the goal has nothing to do with making people more removable from the organization. Creating the kid of people who can use Local Generalization to their advantage costs a lot of money in teaching and guidance. Once an organization makes such an investment in a worker, they're even less motivated to remove them. And organizations tend to only make such investments in people that they already want to keep around.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
There are a lot of good solutions for audio and video conferencing, task, calender and document management. We got specs, uml diagrams, code generators, etc.
But still companies pour tons of cash so that people can be physically there even in the times of recession and i wonder why?
Nothing beat a face to face meeting. Period.
I work with a remote development team every day and I can only support other responders in saying that NOTHING beats working face-to-face. You need the subtle cues of body language, facial expression, and the ease of communication when you're physically present such as doodling on a whiteboard. Video conferencing is a close second but the organizational issues are difficult to overcome (meeting rooms, webcams, bandwidth...).
Communication through documentation works to some extent, but is often perceived as unnecessary overhead by developers who drank the Agile kool-aid. I try to use the phone, skype, MSN or e-mail as much as possible, but it works better with those people of the team that I've actually worked with in-person for at least a few days.
Distance isn't to much the problem, to be honest. You're either co-located or you're not.
We use a combination of Skype IM, Skype Voice, mobile phones and email to keep in touch. We haven't really got into webcams properly, but even then, there's something about face to face contact you can't really replicate with technology.
I think most companies see splitting up their workforce as a step-change. A company that started out with homeworkers is better able to find and establish an office to move them into than the other way round. Money is only one consideration - it really does change the way the team works, and if you get it wrong, you don't have a team, you have a bunch of solo developers who actually take longer to do things.
Of course, it's also easier to recruit and mentor new members of the team if there's an office for everyone to work in.
Many people do better face-to-face. Many people do just as well at a distance. However, people in management tend to more focused on interpersonal relations, which generally means they're face-to-face people. So, as a general rule, people in management tend to dislike or distrust meeting at a distance.
Furthermore, meetings are very often unproductive. This applies to meetings at a distance and face-to-face meetings. Indeed, it's significantly easier to get off-topic, unprofessional, and unproductive when meeting face to face. However, when an at-a-distance meeting is unproductive, it's almost always seen as such because it was at a distance. It can be exceptionally frustrating to deal with the technology and limitations of remote meetings, and it's infinitely easier to blame the situation and the technology for your lack of productivity.
To sum up: people are a problem.
I have a few cynical and contrary opinions on this, based on my experience working for a large Australian organisation with branches all over the country and my current remote work for a US company.
Cynically - face to face works so you can do deals off the record. This may not be as corrupt or as underhand as it sounds but an astounding amount of management-level decision making happens where people negotiate relative tradeoffs involving influence, favors accrued and owed and stuff which is hard or embarrassing to quantify. Even when an organisation has a commitment to using teleconferencing, groups emerge who negotiate off-camera and thus acquire a competitive advantage.
At the purely technical level, I think face-to-face is nowhere near as important as cited. The political issue is in drawing this distinction - if you label your stuff as non-political and safe to do via remote comms, you are explicitly labeling the other negotiations as somehow not safe. Another aspect is that people looking to move up to management need to become visible and a known player in the face-to-face discussions.
Developers, including myself, are notoriously poor at picking up the non-verbal cues cited above (just ask my wife!). In a relaxed atmosphere of trust, they can use emoticons and in-jokes explicitly in IM sessions without worrying about translating someone else's expression, especially across cultures.
IM sessions, with the ability to search the transcript, are far more efficient than verbal or video conversations, when discussing projects. If you don't pick up some nuance at the time someone says it, you can go back and examine the exact sentence in context.
I use video chat infrequently and the main use of voice chat is so I can talk to my boss in his spare time whilst he's driving. Those are good conversations to give me a general feel for how things are going but usually inadequate for technical.
Here's a podcast that talks about distributed software development: Managing Commercial Software Projects. Here's a blurb from the show page:
Andy Singleton is an entrepreneur who
has long studied and practiced the art
of distributed software development.
Influenced by the open source and
agile movements, he has arrived at
some startling conclusions about how
to manage commercial projects. Among
them: don't interview people, don't
estimate schedules, and don't spend
time in teleconferences. In this
conversation with host Jon Udell he
explains why not to do these things,
and what to do instead.
I thought it was pretty interesting.
Face to face meetings provide a lot of visual feedbacks which you do not get in other means. This is must if you want to discuss important subjects like architecture, reviews etc, which tend to be slow or useless if done over phone, email, twiki etc.
Typically status updates can be done via other means, we normally use Skype, Twiki, Email, Phone keep in sync.
I really like communication via IM, email or phone. It's totally ok and I really appreciate using it.
Now comes the big "but" (with a single 't'):
You are not able to "just walk over" your colleague and ask him** a short question. For sure, you can IM him or mail him. But it will take some times till he answers your question.
The other point is drinking coffee. You cannot just drink a cup of coffee with him and talk about your problems.
If you let your brain release your thoughts, problem will disappear. And that's one reason behind drinking coffee with colleagues.
I really need personal communication. I need it. About 70% of the communication can be replaced by IM or whatever, but the 30% are very important.
** him = him/her
Some 80% communication is non-verbal, video conferencing helps a bit, but is not good enough.
There have been studies done over success rate of business negotiation and project cooperation depending on type of communication used. It was ranging from 90% success face to face, to less then 10% with email and text only IM.
For example one of such studies, conducted by Harvard Business School professor Kathleen L. Valley yielded for example such results:
"among 24 four-person decision making
groups interacting via computer, there
were 102 instances of rude or
impulsive behavior. Another 24 groups
that interacted in person yielded only
12 remarks of that nature."
Related Wired article: "The Secret Cause of Flame Wars"