Reputation
Top tag
Next privilege 250 Rep.
View close votes
Badges
1 9
Newest
 Caucus
Impact
~2k people reached

  • 0 posts edited
  • 1 helpful flag
  • 25 votes cast
Jun
23
awarded  Caucus
Jun
23
awarded  Constituent
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?