I know what this is. But I'm getting no helpful suggestions on this.
You're getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.
If you want to keep casual eyes away from your code, the very first
answer to your question:
Override require.
was spot on. Implementing any sort of obfuscation in your own
`require` will keep 99% of the audience out of your code.
If, on the other hand, you want to securely keep the other 1% who are
determined in one way or the other to get at your code out, you can't
do it in software.
Keeping your sensitive *data* encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you're using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the `openssl` ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.
The general feeling I get is it can't be done... Does anyone have any
suggestions how to secure ruby (or other) code.
Nobody is denying that it can be done to some extent. You can keep out
casual attackers by implementing some trivial protection (rot13,
obfuscation, loading your code from a zip file ...) or even keep out
professionals with some resources to invest by executing in tamper
proof hardware. But you seem to want something `in between`, and are
convinced the only way to do it is to compile your encryption key in
C.
-tim
···
On 5/19/06, Eric Hodel <drbrain@segment7.net> wrote:
No code is secure against determined attackers. Please remember that
when you post from Ruby Forum, you're actually posting to a mailing
list read by thousands of people. It would be useful if you kept
context (as I have done) to keep your posts meaningful.
-austin
···
On 5/22/06, Kris Leech <krisleech@interkonect.com> wrote:
In any case how would you go about securing ruby code or do you think it
is not possible? Is no code secure?
The use case can't be changed, it would need to be secure code...
Then the prerequisite would be secure hardware. It's not possible to
safely encrypt code purely in software.
You've not explained why you think that code hidden inside a compiled
binary is safe. It might be just a tad more difficult to extract than
from a script, but it doesn't make sense to distinguish between sorta
safe and a little bit more safe.
Maybe you need to describe the `use case ` in more detail.
Oh, anything can be done... but is it worth it, and have you really
accomplished anything?
It would be a layer of protection that would at least prevent casual
attacks.
That's the source of the resistance you perceive. Most of us don't
want or need what you describe.
Because you dont want it you resist its development..
I venture to say there are numerous people here who might put in
some hours and achieve what you want. But the people who really
understand cryptography (and I am not one) will not spend their
time on an STO scheme.
As for coding... Most people are motivated only two ways to write code:
1. They're paid
2. The project seems cool to them
You're not paying (are you?) and people aren't convinced this is cool.
I'm not asking anyone else to do it.
Actually I remember *someone* making an obfuscator of some kind 3-4
years ago... I played with it awhile and couldn't break it. Others
could, though. Or I could given a few hours.
The best suggestion yet was to keep the code off the client machine
and make a web service. That is relatively secure.
But that makes huge limits on profit. My feeling is web software can't
be sold like desktop software is. Either boxed or a pre-installed
server.
I know what this is. But I'm getting no helpful suggestions on this.
You're getting plenty of helpful suggestions: it makes no sense to go
to great lengths to encrypt code and expect it to be secure.
But it is more secure than open source.
If you want to keep casual eyes away from your code, the very first
answer to your question:
Override require.
was spot on. Implementing any sort of obfuscation in your own
`require` will keep 99% of the audience out of your code.
Agreed. It is something I am looking at.
If, on the other hand, you want to securely keep the other 1% who are
determined in one way or the other to get at your code out, you can't
do it in software.
Keeping your sensitive *data* encrypted on the other hand can be done
in software and with proper encryption, there is no need to obscure
the encryption routine, only the keys you're using (granted, you need
to find a secure way of destributing encryption passwords to users).
You could use the `openssl` ruby library to do the encryption, for
example. Openssl, by the way, is open source, yet quiete a few banks
trust it to protect their homebanking sites.
How do those banks prevent the keys being found by their own staff or
server admins?
···
On 5/19/06, Eric Hodel <drbrain@segment7.net> wrote:
The general feeling I get is it can't be done... Does anyone have any
suggestions how to secure ruby (or other) code.
Nobody is denying that it can be done to some extent. You can keep out
casual attackers by implementing some trivial protection (rot13,
obfuscation, loading your code from a zip file ...) or even keep out
professionals with some resources to invest by executing in tamper
proof hardware. But you seem to want something `in between`, and are
convinced the only way to do it is to compile your encryption key in
C.
-tim
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...
The ruby obsufcator looks good but it may never work with Rails... it
doesn't at the moment.
I'm no expert, but I know encryption keys aren't present in the source
code of the program. Wheter a given encryption program is secure or
not doesn't have anything to do with wheter it is open source or not.
A lot of encryption protocols involve keys generated on the spot from
other information, for example.
···
On 5/23/06, Kris <kris@alternativefocusmedia.com> wrote:
> Keeping your sensitive *data* encrypted on the other hand can be done
> in software and with proper encryption, there is no need to obscure
> the encryption routine, only the keys you're using (granted, you need
> to find a secure way of destributing encryption passwords to users).
> You could use the `openssl` ruby library to do the encryption, for
> example. Openssl, by the way, is open source, yet quiete a few banks
> trust it to protect their homebanking sites.
How do those banks prevent the keys being found by their own staff or
server admins?
It would be a layer of protection that would at least prevent casual
attacks.
Casual attacks aren't your worry. Trust me on this. If you treat your
users like you trust them, you will usually be rewarded. If you don't,
you'll get exactly what you deserve because users don't like being
treated prima facie like probable criminals. This isn't 100% accurate,
but it's close enough.
> That's the source of the resistance you perceive. Most of us don't
> want or need what you describe.
Because you dont want it you resist its development..
No. We don't resist, we don't need. There's a difference. You're
welcome to develop this sort of thing yourself. Just understand that
merely hiding code isn't going to help you at all.
> Actually I remember *someone* making an obfuscator of some kind 3-4
> years ago... I played with it awhile and couldn't break it. Others
> could, though. Or I could given a few hours.
>
> The best suggestion yet was to keep the code off the client machine
> and make a web service. That is relatively secure.
But that makes huge limits on profit. My feeling is web software can't
be sold like desktop software is. Either boxed or a pre-installed
server.
No, web software can't be sold like desktop software. It can be sold
as a subscription service (which is what my company does). We also
sell our software to companies who want to implement their own version
of it, and we are usually required to place our souce code in escrow
in the event that we go under.
Think a little differently and you'll find different ways to profit.
Commercial software sales has bad margins anyway at this point.
That doesn't really explain why you want to encrypt code:
* if people copy your software illegally, they can do so whether the
source code is available or not.
* if the code you want to release is so incredibly ingenius that
people will want to illegally steal your IP to integrate into their
own software, you can a.) sue them b.) get a patent (US only) c.) a
little bit of obfuscating won't keep them out anyhow.
-tim
···
On 5/22/06, Kris Leech <krisleech@interkonect.com> wrote:
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...
The ruby obsufcator looks good but it may never work with Rails... it
doesn't at the moment.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Which obfuscator are you referring to? We've never even tried obfuscating rails apps with ours, and neither have you.
···
On May 22, 2006, at 9:44 AM, Kris Leech wrote:
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...
The ruby obsufcator looks good but it may never work with Rails... it
doesn't at the moment.
--
_why: zenspider's most intense moments of solice are immediately following the slaughter [...]
_why: that topknot's the only thing keeping a lid on the righteous anger
bricolage: yeah, that and his flagrant obsession with dvorak
On 5/23/06, Kris <kris@alternativefocusmedia.com> wrote:
> Keeping your sensitive *data* encrypted on the other hand can be done
> in software and with proper encryption, there is no need to obscure
> the encryption routine, only the keys you're using (granted, you need
> to find a secure way of destributing encryption passwords to users).
> You could use the `openssl` ruby library to do the encryption, for
> example. Openssl, by the way, is open source, yet quiete a few banks
> trust it to protect their homebanking sites.
How do those banks prevent the keys being found by their own staff or
server admins?
I'm no expert, but I know encryption keys aren't present in the source
code of the program. Wheter a given encryption program is secure or
not doesn't have anything to do with wheter it is open source or not.
A lot of encryption protocols involve keys generated on the spot from
other information, for example.
An open source project compiled (open at design time) and software that
has interpreted open source (open at run time) are different. And
interpreted is less secure than compiled. Not much more secure in
skilled hands, but even so. Its easier to write anti-tamper with
compiled. Or better still as suggested using hardware.
Its an application that deals with highly sensitive data, I dont want
insiders to be able to write a bit of ruby and dump the data to
file/screen...
Tim Becker wrote:
···
On 5/22/06, Kris Leech <krisleech@interkonect.com> wrote:
Mainly I want to be able to sell ruby/rails applications without doing a
hosted only solution (like basecamp), if I was 37signals I would want to
sell the application as you would desktop software...
That doesn't really explain why you want to encrypt code:
* if people copy your software illegally, they can do so whether the
source code is available or not.
* if the code you want to release is so incredibly ingenius that
people will want to illegally steal your IP to integrate into their
own software, you can a.) sue them b.) get a patent (US only) c.) a
little bit of obfuscating won't keep them out anyhow.
The keys are not embedded in the program but are secured using the
operating system. Private keys (certificates) are "signed" (encrypted)
by a third party known to be reliable by both bank and client. Each
private key is just a file on a harddrive, protected by the operating
system. Someone who had physical access to that harddrive can get the
key (if they can bypass the operating system) but we assume the bank
keeps it physically secure.
This is pretty similar to my SSH example at the beginning - keys are
held in files apart from the source code, secured by the OS. With SSH
you can also have a "key to a key" where the key file is itself
encrypted and the user has to type a password to decrypt it before it
can be used.
Les
···
On 5/23/06, Guest <krisleech@interkonect.com> wrote:
Tim Becker wrote:
>> How do those banks prevent the keys being found by their own staff or
>> server admins?
>
> That's a different problem, typically solved by using secure hardware.
> The point is, only the key needs to be secret, not the implementation.
>
> -tim
Agreed, but how do you hide the key from people with access to the
server?
How so? I don't think I've ever read anything about this before. Sure,
it's easier to change interpreted code, but if the attacker already
has enough access to make those alterations in the first place, it
doesn't matter wheter the program is compiled or interpreted, and you
have a deeper problem in your hands.
···
On 5/23/06, Guest <krisleech@interkonect.com> wrote:
An open source project compiled (open at design time) and software that
has interpreted open source (open at run time) are different. And
interpreted is less secure than compiled.
