AltME groups: search

is the client paying you to use a machine specific id and some secret 
encryption scheme?

It's equivalent to Rugby but without encryption. R/Services is much 
higher level. If someone is interested, I can search my older backups 
for the whole thing.

I don't need the encryption as it will be used as localhost

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

Encryption ports ...

BrianH .. a public license means that everyone gets ssl, odbc, oracle, 
encryption today without waiting for a new build.

You get SSL, ODBC and encryption for free in 2.7.7.

Have I read the blog correctly ? SSL ODBC and encryption added to 
REBOL/View Standard ? This is a nice news !

http://www.rebol.com/docs/encryption.html

thanks doc, I swear I was googling for rebol encryption but didn't 
find it

Point of Information;  The user.r 2009 roty vote code.

vote: func [name] [

    enbase/base encloak head change head insert/dup copy "" " " 16 form 
    name "roty" 64
]


Please use that function, capture the output and post your vote to 
    user.r Chat


Due to encryption issues please use   'doc, 'brianh, 'henrik, for 
Nenad Rakocevic , Brian Hawley and Henrik Mikael Kristensen.

Can someone explain me, why is Carl using such an 'encryption' and 
why not just to use it as const char like I do here:

https://github.com/Oldes/R3-extension-FMOD/blob/master/main.c#L417

Is it because he wants to be compatible with some old compilers?

Need some more lower level encryption before HTTPS, I think. I think 
also that it belongs in the same category as SSH, SFTP, etc.

BSD or MIT... yes that is exactly what I proposed... it it VERY well 
coded and exceptionally small the whole putty app is in fact smaller 
than rebol.exe IIRC :-)


it has a LOT of goodies beyond a full SSH2 encryption set and EVERYTHING 
is stand-alone it relies on no external dll or libs.

Carl once admitted that is was possible but not "enabled".   AFAIK, 
he never told anyone the trick.  maybe its unstable and didn't want 
to put time on it.


theoretically, one could build an https server protocol in R2... 
the encryption algorithms are all there AFAIK in /pro licenses.  
its just knowing the handshaking protocols and all that... I look 
briefly at the RFC once and its not "obvious" to implement... at 
least not for the bg I have.

MD5 checksums, a parser for the files (easy), and whatever they use 
for encryption.

but encryption occurs at a higher level than tcp

A great discussion with an even greater outcome. I'm hardly able 
to follow, but I love the pure elegance of the proposed solution 
with selfish objects and selfless functions and alike. I'm deeply 
impressed by the security implications your drawing and in general 
all the situations both of you, Ladislav, Brian, with the help of 
Carl and Gabriele, are considering when it comes to answer a question 
which is easy to ask but hard to answer in a satisfying way. So, 
first of all, this is just a note to let you know how much your work 
is appreciated. 


On the other - off topic - hand, it has made me curious especially 
for the security concerns one has to deal with in REBOL. Not the 
kind of security issues you always have to deal with like SQL injections, 
everything related to proper encryption and proper password handling, 
but the kind of rebolish security you have to deal with when, let's 
say, executing arbirtray code. What are the appropiate measures you 
have to take in order to protect yourself from harm, that kind of 
stuff. Are there any documents on this subjects somewhere beyond 
Ladislav's articles?

but yes brianh you got the point when you relay on hardware then 
you have to choose what technology you support i know rebol main 
target is to be hardware / OS / driver abstracted .. but then you 
have a toy language anyone laught about that  can't bring anyway 
the same thing on every OS computer a part some very basic features 
like networking, encryption etc...

There are two ways of hiding values. The tricky way is to use PROTECT/hide 
on a publically visible context. The more common, easier way is to 
use contexts that aren't publically accesible. There is no way that 
a reflector can tell if a bound context is not accessible, but the 
unbind trick prevents that kind of hack. And since inaccesible contexts 
might contain private information like encryption keys that might 
not belong to the person running the R3 process, there is no security 
setting that can make this safe to not do.

Ideally we should have an encryption port so we can also compute 
SHA2 on large files as we can with R2

Whole functionality of encryption ports should be imo added into 
R3, if not already there ...

bug fixing mode right now, and Carl is looking into encryption and 
SSL.

really, if we have to choose between encryption and threads... there 
is no contest.... all the "usability" stuff we can code as extensions 
and indeed, the cURL binding is a good example of this.


we need threads to be done... they have an over-arching effect on 
every aspect of REBOL... we can't put this off until later... its 
going to change the design of things for sure.  I can't understand 
why Carl is side-stepping this again.

I thought so - so it is a RMA stuff. And Carl most probably taking 
an easy route of finish R3? I hope this is not going to be an extension, 
but that encryption ports are part of kernel?

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.

Maxim: "but is it really need since we have the internal OSX pdf 
reader." - I would like to say that, but unfortunately I have had 
to process some absolutely nasty PDF forms that would not work in 
anything, but Adobe Reader, due to various custom elements, encryption, 
etc. Where were they from? Our dear government, of course.

We plan to do encryption and signing. We aren't far enough along 
in the plan to know how we will do these.

I can't say if that will be the case with the encryption or signing 
though.

Certificate use is something R3 doesn't do well yet, afaik (which 
isn't far). We will likely have to do a lot of infrastructure work 
before we can do encryption or signing.

the other issue is that Carl uses checksum/secure to turn the passphrase 
into a binary encryption so tricky to get another tool to decrypt 
using that binary key

I'm not even sure that the encryption needs a binary encryption key

encryption port needs ...

Well, I used the encryption key as a string instead and encrypted 
to 256 bits using Rijndael and successfully decrypted with Rebol. 
 But aescrypt was not able to decrypt the file :(

I'm able to consistently produce this in 2.7.7:

---------------------------
REBOL Error
---------------------------
REBOL Internal Error: Invalid series width 1 was 16 (type 39)

Program terminated abnormally.
This should never happen.
Contact www.REBOL.com with details.
---------------------------
OK   
---------------------------


Will need to dig a little. Not sure if it's an encryption part, debase 
part or what it is yet, but it occurs, when loading enbased, encrypted 
data.

Is Rebol's RSA encryption still standard ?  Can I use that for encrypting 
sensitive health data ?

I need a public key encryption method though

RSA is significantly slower than symmetric key encryption algorithms, 
and a single encryption or decryption operation can only process 
an amount of data up to the size of the RSA key. For encrypting or 
decrypting large amounts of data RSA is usually used in combination 
with symmetric key algorithms or secure checksums as follows:

so I would use AES to encrypt the data,and then use RSA to encrypt 
the AES encryption key I guess

Yes you would use AES to encrypt the data and then RSA to encrypt 
and send somebody the encryption key.

It would seem from the docs at http://www.rebol.com/docs/encryption.html#section-3
that there is no way to specify the block size with Rebol.

If you only need to encrypt data at a single source, you could easily 
call a command line tool such as OpenSSL to perform the encryption 
for you. (It could well be quicker than REBOL too).

What would be cool would be to implement all the low-level encryption 
routines in Red/System.

REBOL provides all the low-level encryption routines required, but 
they are coded in C.  REBOL SSL implementation is also done in C 
(by Holger IIRC).

IIRC, Cyphre once said, that idea for R3 was to add some port or 
other low level encryption functionality, and that https etc would 
be done in REBOL level, using thow low-level facilities ...

AFAIK, SSL and SSH are different communication protocols that rely 
on common hashing and encryption algorithms on the low-level layer.