198 reputation
8
bio website
location Peoria, IL
age
visits member for 3 years, 3 months
seen Jul 1 at 19:27

Once Upon a time a magical company called MagicDollars (for the sake of brevity for the rest of the answer we will refer to this company by its stock ticker M$) and this company made the most widely used, operating system, internet browser, office productivity suite, and various other products. M$ had this great idea to just integrate all of its software so that they would all work together seamlessly. This would be great for users of this software since this would make doing things like importing a webpage in a Ward processing (because in magicland we have wards instead of words) document, seemlessly and natively.

But this would evidently make the software too good. And we cant have people getting software that is too good. Because then if another company came along with their own version of good software people will be too dumb to install and use that if they have the already integrated versions that were included. So the Neanderthal Union decreed that M$ was using its magical abilities to make things too difficult for smaller developers to create super complex applications that they must give away for free. And said you will no longer make things work together seemlessly.

And instead of extending their middle wand to the NeU and saying fine we shall no longer make software that can be used in the NeU... M$ bowed before the luddites and said ok. So now you can not rename a file from inside of your office productivity suite in Magicland.


Sep
24
awarded  Autobiographer
Feb
4
revised Is the number of creatable torrents limited?
deleted 4 characters in body
Feb
4
awarded  Teacher
Jan
2
comment Why programming languages don't provide simple encryption methods?
And now it turns out that the AES has a back door that the NSA has access to. And if the NSA has a tool for it that tool is in the wild somewhere.
Jan
2
comment Is the logic for how the enigma machine worked documented somewhere?
Thank you that is exactly what i was looking for
Jan
2
accepted Is the logic for how the enigma machine worked documented somewhere?
Jan
23
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@e-sushi - "Software solutions will not be able to reach the same quality and security." That is my belief too. Though I was hoping someone with a more knowledge in the field would be able to do a better job of communicating why exactly that is.
Jan
20
comment Is it possible to figure out the public key from encrypted text?
Why would I Want to determine the public key when I can just ask for it and get it as part of the standard? The private key is the unknown.
Jan
13
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@e-sushi - So where this fails then would be that it needs to be able to be generated programmatically for my requirements. We are looking to determine if it would be possible to create a completely secure and easy to use method inside the base programming language. So relying on a satellite or specific technology that could fail would not be acceptable. It would need to be able to be generated though computer logic entirely.
Jan
10
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@DavidSchwartz - Maybe not but I know your key was between 0 and 41... and I know that the encrypted number was <= 42. I have reduced the pool of potentials by ~59%
Jan
10
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@e-sushi I know how to accept it. I am saying that this does not really meet the criteria since we can not programmatically generate a truly random one time pad.
Jan
9
comment Why programming languages don't provide simple encryption methods?
@EthanHeilman - The difference is if the protocol breaks the community can choose a new one and that is the new standard. But the AES standard is not simple to implement. And that is part of what makes it secure. With a program I can crack the method that creates the IV and the AES Becomes non-trivial but not essentially crack proof. So, yes you must understand how to make an IV, while not trivial it is not an overly complex problem either.
Jan
9
comment Why programming languages don't provide simple encryption methods?
@EthanHeilman - If we create a default crypto solution and all languages implement that or even if it is just for a single popular method then any comprimise of that solution be it a weakness in the crpto or the implementation of the crypto means that an attacker can exploit a vast majority of applications written in that language. By not having a default implementation there are some apps that are less secure but an attacker would still need to figure out how what is there is implemented adding a hopefully non trivial step for a well secured app.
Jan
9
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
I agree with your answer but am not able to accept it because we do not have a method to generate a true random one time pad in a computer program.
Jan
9
revised Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
I have changed the requirement of infinite computing power to more than power than we can ever expect to have available
Jan
6
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@EthanHeilman - I am confused you indicated that the Rijndael was too complex to be considered simple in the other thread.
Jan
6
comment Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
@EthanHeilman - The problem is computing power is continually increasing and new processor types like GPU's create new functionality that basically trivializes some encryption cracking. So any standard and secure encryption that could be built in would need to be able to withstand brute force.
Jan
6
asked Is it possible to create an easy to use encryption/decryption method that will never be comprimised?
Jan
6
comment Why programming languages don't provide simple encryption methods?
@EthanHeilman - The solution that the OP finds difficult is not a roll your own encryption it is creating a method to leverage System.Security.Cryptography. Any canned solution is going to be compromised eventually. So the framework would have to be patched... we already have enough problems with servers not being patched for vulnerabilities with out adding another avenue for hackers to attack.
Jan
5
comment Why programming languages don't provide simple encryption methods?
@EThanHeilman - I am also not trying to address "How SHOULD programming languages implement encryption?" _ The question is "Why programming languages don't provide simple encryption methods?" (Specifically C# according to the text) The other question is out of my scope.