Use large random IDs for service objects

[martinmcclure]

To use RSR in a natural fashion as part of an object-capability system, object references must be unforgeable. The sequential fountains currently used by RSR make object IDs easy to predict.
Security could still be assured by never registering sensitive service with an RSR connection, but an additional layer of security would be welcome. This could fairly easily be done by replacing the sequential fountains with fountains of large random integers. These integers must satisfy all of these criteria:

1. Be assigned in a sequence that is random enough to be effectively unguessable
2. Be selected from a large enough pool to make IDs impractical to find by brute-force
3. Be selected such that the probability of the two sides of a connection selecting the same ID for different objects is very small

[kurtkilpela]

This doesn't seem to solve the problem. If a Service is registered with the peer Connection, it is likely registered with the local Connection as well. Can't I avoid the work of a brute-force attack against the Service ID by looking in the local Connection's registry? The only time this would make notable difference is if the local Connection has dropped the local object and the peer Connection has not yet garbage collected.

Am I missing something?

[martinmcclure]

You're right, as long as IDs are not assigned at registration, but only upon first replication.
If that is the case, then you can't send a message to any object that you haven't actually been given. Which, in an object-capability system, is the requirement.
If object IDs are assigned upon registration, it would be easier for a badly-designed server to unintentionally open itself to an ID-guessing attack by registering a sensitive object that it has not yet decided to replicate to the client.

[kurtkilpela]

I don't think it makes a difference because once replicated, the Service ID has been assigned. In the case of malicious code, once the token has been given (replicated), the malicious code is able to access it via the Registry.

[martinmcclure]

If an object has been replicated, then the recipient is authorized to use it, by definition. The threat that prompted this issue was the ability to send messages to objects that had not been replicated.