We need a paid for supported Encryption / Decryption API for a project - AES >256?
I dont want the developers coding their own encryption / decryption even using the built in stuff. To many chances to go wrong.
Links to sites much valued.
UPDATE
Due to the fact as many have said - Its hard to understand if you are not familar with encryption, and get a small thing wrong and its busted...
I have seen answers and will be getting our own encryption/decryption from the builtin - but all the team will need to peer review.
For information BlowFish.Net is good, and performs faster than the builtin crypto routines, which when you start to look at encrypting/decrpyting data into a database can have some massive perf issues ...
http://www.codinghorror.com/blog/archives/001268.html
"even using the built in stuff"
The reason that it's built in is so that people have tested, reliable algorithms available to use that implement standards, not black box third party APIs that might not. What are the "chances to go wrong"?
Maybe you need to switch to Java, you can always opt to use third party JSSE providers there if you're paranoid about the built-in provider.
Bouncy Castle is a well respected and well developed .NET encryption library that is usually recommend for these sorts of questions. But what's wrong with using the System.Security.Cryptography Namespace? - it is extremely secure, very fast and doesn't require any external libraries. Here's an example of how to implement it.
Oh, and "using the built in stuff" will mean it is less likely to go wrong. Your developers won't be coding their own classes, just using the interfaces available which are easy to use and have been very rigorously tested.. Also, the "built in stuff" will be well supported by Microsoft, so if you want to upgrade to C# 4.0 (or C# 5.0 in the future?) you probably won't need to change your code at all.
If you were to use a 3rd party library you would most likely still run into the same issues, which basically boil down to not understanding the pitfalls of encryption.
Without a decent understanding you'll most probably make mistakes with key management, or using bad initialisation vectors or keys. These are issues you'll need to understand to tackle regardless of whether you use the inbuilt libraries (which are fine), or a 3rd party library.
If its something you feel worried about enough, the best recommendation is probably to bring in someone, or better yet - train up people to understand encryption.
Use the builtin 'stuff'. But make sure you use it in the correct mode.
Related
So I'm new to node.js, javascript frameworks, and meteor.com. I'm trying to learn how to build social networks, and I'm naive/struggling to understand why Meteor.js (meteor.com) wouldn't be able to do all the great things you see now that twitter, facebook, instagram are doing?
There's the comet technology between client/server, authentication configs, asynchronous coding for scaling and performance, and built on top of node.js.
I'm trying to learn more about long polling, comet, gridFS or how files are stored, and in general things like replication sets, and sharding to help with performance (esp since Redhat has this openshift platform that we can build our own private clouds with).
I have some computer science background, but it seems like magic, so what am I missing? If you all could think of a few buzz words that make a social network tick that Meteor.js doesn't support, what would it be?
I hear things about parallel and concurrency (webworkers fixes that in part, no?), websockets, that high level languages like python or java are better off supporting. There's only one to learn my answers, and thats by doing, but thought someone could sway me one way or the other via this thread. Thanks!
This question encompasses a really broad idea and just focusing on using meteor alone would solve this issue. Here are a few points to consider:
I don't think this framework would be a good starting point to learn long-polling, gridFS, etc etc. Meteor aims to be a framework that tends to be more of an ecosystem of packages e.g. you can certainly roll your own aformentioned strategies -- however for dynamic updates, Meteor uses its own Data Delivery Protocol (DDP) supported/implemented by (surprise) a good bunch of core packages such as Spark.
Parallel processing and concurrency can be better off done using other languages, but why not with? Since Meteor is largely based on node.js, and node.js is really good with the aforementioned stuff plus it can play very well with other languages so you could integrate smoothly. Meteor doesn't really require you purely rely on it, as other languages would say the same thing. It's all in the general engineering / planning for your project. There are already lots of really good stuff out there that rely on Meteor, join in! don't be afraid. It all boils down to planning (and the courage/perseverance to pull it off, of course).
Right now, we cannot tell if Meteor would be incapable of the usual great stuff by gigantic websites. Sure, we can do live updates, (its own kind of) publish/subscribe patterns, and powerful stuff to boost development (look at the seven core concepts of meteor to best understand this). It is not impossible to replicate what is already out there, really. We can only say it with uncertainty at the moment mainly because.. (see next point)
The framework is so young! it's still at 0.6.x at the time of writing. Please take time to look at the Meteor Roadmap to see how things are going in terms of broader support for persistence/databases, performance considerations, and the official DDP specification.
I hope I have answered your enquiry (and more, I hope). I'm really excited for meteor myself as it could easily be the next big thing. We have a couple of (for-)production projects using Meteor as well, so you're getting direct insight from a person who has done quite a bit of hacking (and tons of research and first-hand experience) in Meteor. Not that i'm saying i'm an expert or so, it's just so much fun to work with Meteor and i'm totally not kidding you.
Hope this helps!
P.S.: Fair warning though, resources and documentation is really sparse at this point. I try to contribute to the community as much as I can about it (one of my starting points is here, on SO).
Does anyone know of any semi-portable way to write console applications (e.g. basic animation) in scheme? I heard of an ncurses wrapper but I couldn't find anything.
You can't do any GUI in a portable way in Scheme -- because you only get very basic file IO.
Depends on your scheme of choice. Chicken Scheme, for instance, has good ties with C and has various Curses libraries. See their code examples:
ncurses
mojo, curses for the lazy :)
Have you checked out Guile? I've never used it myself except just to play around, but it is pretty cool, and even has a little GUI support. Not sure about portability, except it should port just fine between different Unix systems, but the same can be said about ncurses.
Don't give up hope! If you're dedicated to developing in Scheme, you can.
Has anyone done a thorough comparison of AppFabric and NCache or AppFabric and ScaleOut? We are currently looking to implement either AppFabric, NCache or ScaleOut for distributed caching in geographically distant locations and I would like to know anyone's thoughts who has compared them side by side. I appreciate that many people use one or the other and tell me why their chosen solution is great but I am really looking for a comparison of the two products. Such things as what does AppFabric not do or not do well (if anything), partially from a features point of view but also from developer's point of view. Is working with one compared to the other nicer, easier, more flexible, more powerful, etc.
There are plenty of lists of features which I can compare but am really looking for a comparison from someone who has perhaps been in a similar position to us and has performed the evaluation that we are about to launch into which will give us some food for thought whilst we do so.
Thanks in advance.
Here is a good comparison between the features of NCache and Appfabric
As a more mature product, NCache has a number of more advanced caching features that Velocity/AppFabric doesn't have -- check out their website for some "marketing" comparisons.
However, we have had a number of issues troubleshooting NCache and obtaining more visibility from their support/engineering team into certain behaviors of their application. Given that, plus the cost compared to AppFabric, I'm not sure I would recommend NCache at this point -- at least, we're in the process of re-evaluating our caching provider.
My frustration/complaint with Velocity/AppFabric is the the sluggishness in the release schedule. Seems like they were in CTP forever. Certainly Microsoft can crush NCache on price alone. There are now players like NorthScale (memcached) that are entering the fray which I think are also worth considering. A lot depends on what you want to use caching for in your application.
The most used one is Memcached. for sure.
we currently are starting using AppFabric as our dcache, as it easily integrates into our .net solutions, and has a good feature set, that we want to use.
if you just do basic dcaching, make a abstraction of caching itself (or use the .net 4 System.Runtime.Caching.ObjectCache) so you are safe if you want to do changes. or want to stress test more solutions.
Also, depending on your App architecture, think of using more entities/instances of your DCache, as different parts maybe favor different systems.
It is looking like we will need more advanced functionality than what Velocity provides so it will be either NCache or ScaleOut. There are good reasons for both, we just need to sort through these. We do not have Unix resources so memcached is out. I know there is a Windows port but colleagues who know memcached tell me that it is somewhat buggy and if you are going to bother going down the memcached path, you really should make the effort to go for the Unix version.
Some might argue that this is a biased comparison, but it's worth reviewing..
http://www.alachisoft.com/comparison/ncache-vs-appfabric.html
PDF has the full review.
http://www.alachisoft.com/downloads/comparison/ncache-vs-appfabric.pdf
I'm evaluating the Microsoft Anti-Cross Site Scripting Library (AntiXSS V3)
I have to say it seems to me that apart from providing a more comprehensive white list of acceptable characters, it's not really bringing anything to the party that a diligent programmer who encoded all his user/agent modifiable output wouldn't be doing anyway.
Am I missing a trick?
I don't think you're missing anything except for the fact that the number of programmers who are aware of proper secure coding is very small, and those that can do it properly are fewer still.
The libraries are written to make things easier for your average developer, and I would assume that any library that is written by Microsoft with the express purpose of enhancing security would be done by a coder (or team of coders) that are experts in the field, as opposed to your normal everyday developer who focuses on the needs of their company.
(I would think they would put a lot of importance on doing this right, considering how Microsoft products are always painted as being painted as "insecure" by MS-haters)
As a parallel, think about encryption. A diligent coder could come up with a secure encryption algorithm. However, OWASP guidelines tell you NOT to come up with your own algorithm, but to use tested algorithms developed by experts and well-tested.
If we have a tool by experts that does the job for it, why would we try to do this on our own? I'd say it would be good to use the Microsoft Anti-Cross Site Scripting Library for this reason alone, if it works as advertised.
After reading a bit more about how Gnutella and other P2P networks function, I wanted to start my own peer-to-peer system. I went in thinking that I would find plenty of tutorials and language-agnostic guidelines which could be applied, however I was met with a vague simplistic overview.
I could only find very small, precise P2P code which didn't do much more than use client/server architecture on all users, which wasn't really what I was looking for. I wanted something like Gnutella, but there doesn't seem to be any articles out in the open for joining the network.
RFC 4981, with its huge bibliography, could be a very good starting point.
I had to write a basic Gnutella client in C# using Web Services and I think the class notes on the P2P stuff are still available here and here.
You might have better success researching Bittorrent, I believe that the creator has written some papers, and it seems others are as well.
BitTyrant
Bittorent.org, see the developers section
I don't know what platform you are trying to use, but here is a decent article on the subject for .NET.
I've found the TheoryOrg Unofficial BitTorrent Specification to be the best online source for Bittorrent information. Also, the Monotorrent code is fairly simple and easy to understand. There's also a project called "GCT" which implements JGroups style P2P for LAN/Multicast environments, and its code is similarly easy to understand (if a bit buggy).
You can try to read Gnutella2 and try to implement messaging. For reading conceptual material you can read Distributed Systems by Andrew Tannenbaum.
You can have a look at JXTA. It's intention was to be a generic, platform agnostic p2p framework, in contrast to other p2p implementations which are usually for a very specific purpose (such as Gnutella).
Don't be fooled by it's Java appearance, there are binding available for C/C++/C#, but the core protocols are implemented in XML which should translate to any language.
You can also download a free book here.