Encrypting/Decrypting Password from a Config File
michael.s...@gmail.com
I am looking for a way to encrypt a password in a configuration file
that is being read by a Java program. Currently, I read-in the
password from the text file, but that leaves the password sitting right
out in the open if someone were to look at the config file.
I was thinking of building a simple class where user could type in
their desired password, get an encrypted version of the password, then
paste the encrypted version into the configuration text file. Then the
application would read encrypted password, decrypt the password back
into a string, and move on.
I am having trouble with the string-->encrytped bytes-->string
conversions.
I am using the built-in java security classes to implement this code.
Here is some sample test code:
// Reads password from config file
String password = ScriptConfig.getString( "password" );
// Generate Key
KeyGenerator kg = KeyGenerator.getInstance("DES");
Key key = kg.generateKey();
// Create Encryption cipher
Cipher cipher = Cipher.getInstance( "DES" );
cipher.init( Cipher.ENCRYPT_MODE, key );
// Encrypt password
byte[] encrypted = cipher.doFinal( password.getBytes() );
// Create decryption cipher
cipher.init( Cipher.DECRYPT_MODE, key );
byte[] decrypted = cipher.doFinal( encrypted );
// Convert byte[] to String
String decryptedString = new String(decrypted);
System.out.println("password: " + password);
System.out.println("encrypted: " + encrypted);
System.out.println("decrypted: " + decryptedString);
// Read encrypted string from config file
String encryptedPassword = ScriptConfig.getString( "encryptedPassword"
);
// Convert encryptedPassword string into byte[]
byte[] encryptedPasswordBytes = new byte[1024];
encryptedPasswordBytes = encryptedPassword.getBytes();
// Decrypt encrypted password from config file
byte[] decryptedPassword = cipher.doFinal( encryptedPasswordBytes );
System.out.println("encryptedPassword: " + encryptedPassword);
System.out.println("decryptedPassword: " + decryptedPassword);
The config file has the following variables:
password=password
encryptedPassword=[B@2a4983
When I run the code, I get the following output:
password: passwd
encrypted: [B@2a4983
decrypted: passwd
javax.crypto.IllegalBlockSizeException: Input length must be multiple
of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.DESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
at com.sapient.fbi.uid.TestEncryption.main(TestEncryption.java:48)
Any help on the error, structure, or process I am using to do this
would be great. Thanks.
Oliver Wong
<michael.s...@gmail.com> wrote in message
news:1130960757.0...@g44g2000cwa.googlegroups.com...
If you actually included an SSCCE, I could find out which line is line
48, and it'd be easier for me to help you.
SSCCE: http://www.physci.org/codes/sscce.jsp
My guess is it has something to do with not padding the results
correctly. As the message implies, the decryption algorithm expects the
length to be a multile of 8, and "[B@2a4983" is of length 9.
- Oliver
Jack
>I was thinking of building a simple class where user could type in
>their desired password, get an encrypted version of the password, then
>paste the encrypted version into the configuration text file. Then the
>application would read encrypted password, decrypt the password back
>into a string, and move on.
but any bad guy who has access to the config file would also have
access to the decryption routine, yes?
so you might instead do this: once the user creates their password,
the software creates something like an MD5 hash of it and stores the
hash. Thereafter, whenever the user wants to logon again, the software
converts his entered pwd to MD5 and compares that to the list of
stored, hashed pwds. That way, no one but the user ever can know the
actual password.
You probably have seen websites where, if you've forgotten your pwd,
they can send you a new one - that's because they are using a scheme
like that.
Luc The Perverse
news:hfnim19bi92divka0...@4ax.com...
You may want to use SHA-256 though, since MD5 is considered broken.
--
LTP
:)
Jack
<sll_noSpamli...@cc.usu.edu> wrote:
>
>You may want to use SHA-256 though, since MD5 is considered broken.
can you elaborate? :)
Luc The Perverse
Sure.
The purpose of a hash is ideally to create a number from an input that
cannot be reversed and cannot be forged. (Reversed means an attacker with
the hash output can "go backwards" and get the input.) (Forged means an
attacker with the output can make up another made up pass phrase which
generated the same hash.) Of course, asking just for the hash, is not good,
because someone not knowing the passphrase could easily just send the same
hash along.
Most of these problems (except reversing) can be fixed by adding a
negotiated preamble (IE random number) to the passphrase before hashing.
But this only works if the server is seperate from the user and knows the
passphrase. (For a local file on a local machine, this is an
impossibility)
MD5 has been broken, in that it is now known how to generate an input which
will cause a certain hashed output.
It just depends on how hard you want to make it. Every system has a
weakness. A very tech savvy person could reverse engineer your program,
find out your encryption, remake a new hash from a new password and drop it
into your file, effectively changing the password without ever knowing what
your old password was.
You need to decide what your threat model is. The dilema that you will
always come back to is this: If the computer is not secure then the
password is not secure. If the computer is secure, then what are you
worried about?
So if the only thing you are trying to do, is keep it from exceptionally
amateur hack attempts, then a simple file encoding would work (maybe a
simple XOR bit mask on every byte.)
If you don't want to compromise the users password to slightly more advanced
attacks, (since you know people are using the same password for everything)
then using a hash is a good idea. And in this model MD5 or SHA-256 would be
fine. I prefer SHA-256 because it feels 1337er to me. Same reason I use
Serpent instead of Rijndael ;)
Just remember that there is always a way around security. Even the
infallible Compusec HSM (http://www.ce-infosys.com.sg/CeiProducts_HSM.asp)
can be easily taken over with a simple hardware keylogger, fingerprint
forgery and simple mugging (for the smart card) or just walk in while the
person is going pee.
--
LTP
:)
jonck
> would be great. Thanks.
Perhaps you will find the following article helpful:
http://www.devx.com/Java/10MinuteSolution/21385/0/page/1
Oliver Wong
news:436992fe$0$8298$3a2e...@news.csolutions.net...
>
> MD5 has been broken, in that it is now known how to generate an input
> which will cause a certain hashed output.
A technique was always "known": Brute force.
But I guess what you're referring to is some mathematical flaw in the
MD5 algorithm being discovered. I had read an article on that too, but from
my recollection, the weakness was rather theoretical and had little
practical impact. E.g. instead of using pure brute force and expecting to
crack the password in 20 billion years, you could use the weakness they
discovered and crack the password in 10 billion years. (Those were just
numbers off the top of my head, but they illustrate what I meant by 'little
practical impact').
In other words, if you're just doing amateur level security for local
programs, don't worry too much about "MD5 being broken" yet. As Luc alluded
to, suceptibility to reverse engineering is probably a far bigger risk for
you at this point.
- Oliver
Oliver Wong
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
message news:p9ajm1dlsmoafb4og...@4ax.com...
> On Wed, 2 Nov 2005 21:32:09 -0700, "Luc The Perverse"
> <sll_noSpamli...@cc.usu.edu> wrote, quoted or indirectly
> quoted someone who said :
>
>>I prefer SHA-256 because it feels 1337er to me.
>
1337er = leeter = more leet = more elite.
- Oliver
Dag Sunde
news:Y2qaf.74534$S4.9917@edtnps84...
Yeah... And there is nothing more removed from being
elite that using that 14-year old "WaReZ kIdZ" speak...
LOL...
--
Dag.
Daniel Dyer
wrote:
"In 1996, a flaw was found with the design of MD5; while it was not a
clearly fatal weakness, cryptographers began to recommend using other
algorithms, such as SHA-1 (recent claims suggest that SHA-1 was broken,
however). In 2004, more serious flaws were discovered making further use
of the algorithm for security purposes questionable."
[From http://en.wikipedia.org/wiki/Md5]
Collisions can be found in a matter of hours with a modest PC.
Or you can look up a hash in an online database such as this one:
Dan.
--
Daniel Dyer
http://www.dandyer.co.uk
Monique Y. Mudama
It's a form of humor. Using "1337" in otherwise well-formed and
comprehensible text is a way of both mocking the script kiddies and
yourself, just a bit, at the same time. Obviously Luc is mocking
himself when the only reason he gives for using one over the other is
"it feels 1337er". He's acknowledging that he doesn't have a better
reason.
As with all jokes, it's not funny if you have to explain it.
In short, if every third word you type uses numbers in place of
letters, etc, then you look dumb. If you very rarely use a select
l33tspeak word for emphasis, you are identifying yourself as part of a
particular community.
--
monique
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Juha Laiho
>On Thu, 03 Nov 2005 15:30:27 -0000, Oliver Wong <ow...@castortech.com>
>wrote:
>
>> "Luc The Perverse" <sll_noSpamli...@cc.usu.edu> wrote in
>> message
>> news:436992fe$0$8298$3a2e...@news.csolutions.net...
>>>
>>> MD5 has been broken, in that it is now known how to generate an input
>>> which will cause a certain hashed output.
>>
>> MD5 algorithm being discovered.
>
Hmm.. was this "free-form" collisions, as in I give you just any hash,
and you provide data matching that hash within hours, or cases where
you first generate the data and hash yourself, and then manipulate the
initial data in such ways that you have another piece of data which
produces the same hash as the first one?
I know the latter can be done, but I'm still unclear whether the former
has been successfully demonstrated. For some uses even the latter case
is enough to not use md5, and of course it does take some credibility
from the algorithm, but mostly I wouldn't panic - yet.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
Dag Sunde
news:slrndmkj7...@home.bounceswoosh.org...
Oh, I got it... I've got two kids at 11 and 16 that speak the lingo...
:-)
Monique Y. Mudama
> "Monique Y. Mudama" <sp...@bounceswoosh.org> wrote in message
> news:slrndmkj7...@home.bounceswoosh.org...
>> On 2005-11-03, Dag Sunde penned:
>>>
>>> using that 14-year old "WaReZ kIdZ" speak...
>>>
>>> LOL...
>>
>> It's a form of humor. Using "1337" in otherwise well-formed and
>> comprehensible text is a way of both mocking the script kiddies and
>> yourself, just a bit, at the same time. Obviously Luc is mocking
>> himself when the only reason he gives for using one over the other
>> is "it feels 1337er". He's acknowledging that he doesn't have a
>> better reason.
>>
>> As with all jokes, it's not funny if you have to explain it.
>>
>> In short, if every third word you type uses numbers in place of
>> letters, etc, then you look dumb. If you very rarely use a select
>> l33tspeak word for emphasis, you are identifying yourself as part
>> of a particular community.
>
> Oh, I got it... I've got two kids at 11 and 16 that speak the
> lingo...
>:-)
>
Okay, then I won't comment on the irony of someone using "LOL" to
laugh at l33tspeak =)
Dag Sunde
> On 2005-11-03, Dag Sunde penned:
>> "Monique Y. Mudama" <sp...@bounceswoosh.org> wrote in message
>> news:slrndmkj7...@home.bounceswoosh.org...
>>> On 2005-11-03, Dag Sunde penned:
>>>>
>>>> Yeah... And there is nothing more removed from being elite that
>>>> using that 14-year old "WaReZ kIdZ" speak...
>>>>
>>>> LOL...
<snipped>
>>> l33tspeak word for emphasis, you are identifying yourself as part
>>> of a particular community.
>>
>> Oh, I got it... I've got two kids at 11 and 16 that speak the
>> lingo...
>>:-)
>>
>
> Okay, then I won't comment on the irony of someone using "LOL" to
> laugh at l33tspeak =)
>
Context? Usenet/NG vs. chatrooms/IRC? Social culture in the one
vs. the other? ...and where we communicate now?
LOL belongs here (together with AFAIK, YMMV, IANAL et.c.)
1337, 1am3r et.c does not?
I don't see the irony...
:-)
--
Dag.
Oliver Wong
"Daniel Dyer" <d...@dannospamformepleasedyer.co.uk> wrote in message
news:op.szobq...@cgl0517.chaucer.co.uk...
>
> "In 1996, a flaw was found with the design of MD5; while it was not a
> clearly fatal weakness, cryptographers began to recommend using other
> algorithms, such as SHA-1 (recent claims suggest that SHA-1 was broken,
> however). In 2004, more serious flaws were discovered making further use
> of the algorithm for security purposes questionable."
>
> [From http://en.wikipedia.org/wiki/Md5]
>
> Collisions can be found in a matter of hours with a modest PC.
>
> Or you can look up a hash in an online database such as this one:
>
> http://www.md5lookup.com/
This is not to say that I doubt your claims, but I found it amusing that
md5lookup.com reports that the database is down for maitenance and will be
back up on October 31st ("now" being November 3rd, 2005). I guess it isn't
exactly a lie, as they haven't specified October 31st of what year!
I then proceeded to go down the list of "MD5 Crackers" listed on
Wikipedia and none of them worked. http://md5.crysm.net/ kept timing out for
me, http://gdataonline.com/ reported the password as being "?????" for every
hash I tried (which is either a stunning coincidence, or this is their way
of saying they don't know the password), and
http://passcracking.ru/index.php I couldn't figure out how to use, as it was
in Russian (no matter what hashes I tried, it would return a blank page).
http://passcracking.com/ was the most promising of the bunch, but apparently
there was a queue of 31504 hashes to crack before me (I was too impatient to
wait).
Conclusion: Cracking MD5s isn't as easy as some people make it sound,
sometimes for as pragmatic reasons as the fact that the webservers are being
overloaded with work and cannot respond in time.
- Oliver
Luc The Perverse
news:slrndmkj7...@home.bounceswoosh.org...
Thank you! I couldn't have described it better myself.
--
LTP
:)
Joan
"Dag Sunde" <m...@dagsunde.com> wrote in message
news:I5vaf.7396$qE.16...@juliett.dax.net...
shouldn't this be "iANAL"
Luc The Perverse
> Conclusion: Cracking MD5s isn't as easy as some people make it sound,
> sometimes for as pragmatic reasons as the fact that the webservers are
> being overloaded with work and cannot respond in time.
The difference using the Java cryptography toolkit is the difference of a
single string!
When using a safer algorithm is trivial, I don't see why you wouldn't.
While I am unfamiliar with any such program, it is at least theoretically
possible that an intelligent hacking program could be enlisted to search all
CLASS files for use of the MD5 checksum algorithm, and then be delivered to
a programmer somewhere to develop exploits (perhaps as part of an ambitious
but unrealistic "hack every java program" venture)
There is a level of responsibility that comes when you give the user the
illusion that some functionality that he or she is using has been secured.
--
LTP
:)
Oliver Wong
> "Oliver Wong" <ow...@castortech.com> wrote in message
> news:U7vaf.74398$y_1.8262@edtnps89...
>> Conclusion: Cracking MD5s isn't as easy as some people make it sound,
>> sometimes for as pragmatic reasons as the fact that the webservers are
>> being overloaded with work and cannot respond in time.
>
> The difference using the Java cryptography toolkit is the difference of a
> single string!
>
> When using a safer algorithm is trivial, I don't see why you wouldn't.
If design A is better or equal to design B in all aspects, and is better
than design B in at least one aspect, then you should always take design A.
That's agreed. I never meant to imply "always use MD5 in your Java
applications" or anything like that. The only message in the conclusion you
quoted above is that there exists at least one person in the universe who
claims that cracking MD5 hashes is easier than it actually is. By itself,
that's a rather weak statement, but I supported it with a repeatable
experiment in which I tried cracking a hash of my name on the "MD5 cracking
websites" listed on the Wikipedia article on MD5, and pointing out that the
results I got were that every single site failed to crack the hash.
> While I am unfamiliar with any such program, it is at least theoretically
> possible that an intelligent hacking program could be enlisted to search
> all CLASS files for use of the MD5 checksum algorithm, and then be
> delivered to a programmer somewhere to develop exploits (perhaps as part
> of an ambitious but unrealistic "hack every java program" venture)
Yes, although I also feel that some people make decompilation of Java
bytecode sound easier than it really is, in principle, you could look for
references to Sun's cryptography API, and the string that references MD5 (is
it "MD5"?) in the constant pool, and you'd be able to assume that the class
file you've got probably uses Sun's implementation of MD5.
> There is a level of responsibility that comes when you give the user the
> illusion that some functionality that he or she is using has been secured.
True. However, most users out there really don't care about security.
I've never checked the source code for my PGP binaries for example. Many
people tell their significant other their passwords. They also use the same
password for everything. Etc. Those that actually care probably will refuse
to use a program written by someone else unless it's open source, in which
case they can directly see what algorithms you're using.
- Oliver
Luc The Perverse
> True. However, most users out there really don't care about security.
> I've never checked the source code for my PGP binaries for example. Many
> people tell their significant other their passwords. They also use the
> same password for everything. Etc. Those that actually care probably will
> refuse to use a program written by someone else unless it's open source,
> in which case they can directly see what algorithms you're using.
You're absolutely right!
Most naive users believe the government can crack ANY encryption scheme, and
don't care what anyone says to the contrary (I blame movies). Other than
them, they are not really concerned. Hackers and viruses are slowly gaining
"acceptance" as viable threats, but most people continue on oblivious.
This is of particular interest to me wishing to develop [for profit]
encryption systems. The public sentiment will work against it, but I
believe that through proper marketing it may be possible to penetrate a
not-too-narrow "paranoid" market.
And there are LOTS of people out there who want to keep secrets from their
spouses/children/parents/roommates etc.
The trick is just making the software easy enough to use that people are not
intimidated by it.
I consider this a challenge!
I imagine financially the project will fail, but I hope to learn a lot.
Only having been in this group briefly, which prompted me to start [again]
studying Java - I have been convinced to write my app in Java. (Well,
rewriting my SHA-256 checksum duplicate file finder in Java from C is
probably what really convinced me.)
--
LTP
:)
Roedy Green
>When using a safer algorithm is trivial, I don't see why you wouldn't.
Consider that the Homeland Security, FBI, NSA and CIA etc. are not
exactly going to hand over their code cracking algorithms as open
source. You have to presume those types are orders of magnitude more
advanced and have special purpose hardware.
Personally if I wanted to send messages I did not want that sort of
group snooping on, One Time Pad would the only thing I would consider.
A way to crack AES would be a state secret.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green
>Most naive users believe the government can crack ANY encryption scheme, and
>don't care what anyone says to the contrary (I blame movies).
Jalal Feghi, author of Digital Certificates, Applied Internet Security
says the military in 1997 could crack a 40 bit keys in milliseconds,
a 56 bit key (e.g. DES) in seconds, a 64 bit key in minutes, an 80 bit
key in centuries, and a 128 bit key in millennia.
Luc The Perverse
> Personally if I wanted to send messages I did not want that sort of
> group snooping on, One Time Pad would the only thing I would consider.
I think sources like random.org are likely polled and recorded for all their
output. You would need your own trusted entropy source.
> A way to crack AES would be a state secret.
Remember, US code breakers broke a one time pad because they found it wasn't
truely random.
I say, OTP + AES (well as I previously mentioned, I use Serpent instead of
AES, but same idea.)
I actually quite trust secret key algorithms like AES. What I think the
government really can crack virtually immediately are the asymmetrical
ciphers (RSA, Elliptical Curves etc.) ~IF~ there is an agency which can
crack things like AES, it is the NSA not the FBI - and I never do anything
that would endanger national security.
The FBI has its own methods. While I don't think they have exotic code
breaking algorithms/systems - I do think that they have exceptionally
advanced surveillance equipment, which they can easily use to get your
keyrings/passwords etc. And if suddenly you start sending a bunch of
encrypted messages, either they will break it if they can, or suddenly your
secret keys become not so secret.
I will just say, I have no desire to try to defeat the government. If my
president suceeds in overthrowing the current government and establishing a
theocracy, I will flee to a more liberal country. Until then I will just
try to get by.
--
LTP
:)
Roedy Green
>Remember, US code breakers broke a one time pad because they found it wasn't
>truely random.
The key to doing One Time Pad is you must implement the algorithm
yourself or at least go over the source with a fine tooth comb and the
compiled version as well, to make sure there is no code there that
does not need to be.
The easiest way to crack one time pad would be to offer free
implementations that snoop.
Similarly for your random source. If you bought a black box, for all
you know inside is a computer generating pseudo random numbers.
You want to be able to take it apart and make sure it is truly what it
claims. See http://mindprod.com/jgloss/truerandom.html
Luc The Perverse
>>I will just say, I have no desire to try to defeat the government. If my
>>president suceeds in overthrowing the current government and establishing
>>a
>>theocracy, I will flee to a more liberal country. Until then I will just
>>try to get by.
>
> feel quite the opposite. I want those agencies foiled. They are for
> the most part up to no good.
>
> Routine surveillance is big brotherish. If someone is a high risk for
> terrorism they deserve a court order wiretap and bugging.
It's not terrorists that I am concerned about - nobody wants them scott
free.
A child was taken away from his parents when he kissed his girlfriend at
school (both in elementary school)
There are certain counties in my state where I cannot buy alchohol ever.
Pharmacists can legally confiscate plan B emergency contraception
prescriptions.
Don't get me started on the abstinence until marriage compaignes.
The best one of all! The president tries to ammend the constitution to
prohibit gays from marrying. This IS a new development right? I've
never heard of 100 years ago propositions for ammendments prohibiting blacks
or jews from marrying. Maybe those just aren't in history books - I don't
know.
There is something SERIOUSLY wrong with this country - when the whole
country is in an uproar because Clinton lied about a blowjob - but don't
care where CIA integrity is undermined, when the president tried to add
discrimination to the constitution, spead his own theological beliefs under
the guise of international anti AIDS campaigne, intervene in the Terri
Schiavo case.
Bush should be impeached for starting a war with Iraq over a vendetta.
This is my opinion. Maybe that is what you meant by "mistrust"
--
LTP
:)
steve
(in article <436cd3de$0$8296$3a2e...@news.csolutions.net>):
thats why I live in China.
Because I know exactly where i am , as regards the government.
Oliver Wong
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
> On Sat, 5 Nov 2005 08:00:20 -0700, "Luc The Perverse"
> <sll_noSpamli...@cc.usu.edu> wrote, quoted or indirectly
> quoted someone who said :
>
>>Remember, US code breakers broke a one time pad because they found it
>>wasn't
>>truely random.
>
> The key to doing One Time Pad is you must implement the algorithm
> yourself or at least go over the source with a fine tooth comb and the
> compiled version as well, to make sure there is no code there that
> does not need to be.
That assumes you trust the compiler. So you'd have to write your own
compiler. You can't write your own compiler in Java though, 'cause you'd
have to compile that compiler, and you don't trust the compiler. You can't
write it in assembly language though, 'cause you'd have to trust the
assembler/linker. Maybe use a hex editor and write it directly in machine
code. But then you'd have to trust the hex editor.
So your best bet is to build a read-only USB key from scratch, where the
data on the USB key is the executable for your assembler, from which you can
write your one time pad algorithm in assembly.
That of course assumes you trust your CPU. Just because you send it one
set of instructions doesn't mean it might not execute a different set.
And even then, there's lots of devices in between your USB key and the
CPU that could nefariously insert malicious code along the way. The USB host
device, the data/control BUS, the offboard cache, etc.
While building your USB key, you can't buy ready made transistors and
such from radioshack, as they might be under control of the goverment too.
Oh, and you can't trust your senses. You may think you're sitting in
your basement, smelling dampness, and touching screw drivers and electronics
parts, but this might all be an drug induced hallucination as the men in
black peer into your dreams to try to find out your secrets.
At some point, you're going to have to trust something. As I mentioned
elsewhere in this thread, I haven't read the source code for my PGP
binaries, nor have I compiled them from source; I just downloaded the
binaries and use them. I trusted them. Maybe I was naive.
- Oliver
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> That assumes you trust the compiler. So you'd have to write your own
>compiler.
No, you don't have to write your own compiler, just check the output.
The runtime is another matter. You can't very well check it out, but
you can check out that your copy of the runtime is the same as
everyone else is getting. This means the bad guys out to get you a
have control of Sun's distribution, and they think you are important
enough to put a hook in it. All you have to do then it use a OLD jvm
written before you wrote your code. It would have a heck of a time
spoofing code it has never seen.
The way the bad guys would most easily foil you is via taking over
your OS and putting in keystroke loggers, screen loggers etc to spy on
the decoded text. To help defeat that your machine must be a virgin
that has never seen the Internet.
Since windows is so insecure, if you were serious you would use the
smallest hardware that could still tackle the job, perhaps an old
Apple ][ where there is little place to hide code.
Oliver Wong
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
> On Mon, 07 Nov 2005 18:41:22 GMT, "Oliver Wong" <ow...@castortech.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> That assumes you trust the compiler. So you'd have to write your own
>>compiler.
>
> No, you don't have to write your own compiler, just check the output.
Hmm, good point. But how do you check the input? A hex editor? You'd
have to trust the hex editor then. And you'd have to trust the OS that when
you request the contents of the file, it really does give you the contents
of the file.
Using an open source OS doesn't help that much, because even if you see
the source, you'll still have to compile it, at which point you have to
trust the compiler so you're back at square one.
> The runtime is another matter. You can't very well check it out, but
> you can check out that your copy of the runtime is the same as
> everyone else is getting. This means the bad guys out to get you a
> have control of Sun's distribution, and they think you are important
> enough to put a hook in it. All you have to do then it use a OLD jvm
> written before you wrote your code. It would have a heck of a time
> spoofing code it has never seen.
Difficult, but theoretically possible. My post was pretty
toungue-in-cheek, and I was concerned more about the theoretical security
holes than the practical ones.
> The way the bad guys would most easily foil you is via taking over
> your OS and putting in keystroke loggers, screen loggers etc to spy on
> the decoded text. To help defeat that your machine must be a virgin
> that has never seen the Internet.
>
> Since windows is so insecure, if you were serious you would use the
> smallest hardware that could still tackle the job, perhaps an old
> Apple ][ where there is little place to hide code.
You'd still have to trust the hardware though, e.g. make sure any ROM
doesn't have unwanted behaviour hardcoded into it. Or even making sure that
just the way the components were wired together don't introduce some sort of
secret behaviour, even if each of the individual components behave exactly
as expected.
And there's still the issue of trusting your own senses. Or trusting
your own mind.
- Oliver
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> Using an open source OS doesn't help that much, because even if you see
>the source, you'll still have to compile it, at which point you have to
>trust the compiler so you're back at square one.
Did you ever see Gene Hackman in The Conversation?
Oliver Wong
"Roedy Green" <my_email_is_post...@munged.invalid> wrote in
> On Wed, 09 Nov 2005 15:49:18 GMT, "Oliver Wong" <ow...@castortech.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> Using an open source OS doesn't help that much, because even if you
>> see
>>the source, you'll still have to compile it, at which point you have to
>>trust the compiler so you're back at square one.
>
> Did you ever see Gene Hackman in The Conversation?
No, but scenes from the movie "Memento" came to mind as I wrote my post.
- Oliver
Chris Uppal
> No, but scenes from the movie "Memento" came to mind as I wrote my
> post.
Reminded me more of Ken Thompson's classic "Reflections on Trusting Trust".
http://www.acm.org/classics/sep95/
-- chris