Generally no.
In cryptography, the appearance of "random" strings of numbers is generally quite suspect --- what if there are certain "weak" choices of numbers that yield the entire construction insecure? How do you know the designer didn't use their freedom in choosing these numbers to embed a backdoor? Note that this does happen, famous examples are:
Note that there are certain "arbitrary constants" that are seen as less suspect --- common choices are the digits of $\pi$, or things of this sort (say the digits of $\sqrt{2}$ or $\sqrt{3}$). These are often called nothing up my sleeve numbers, and can be reached for when the designer just needs some arbitrary numbers that satisfy some minimal constraints that "most" numbers should satisfy.
Anyway, returning to RIPEMD.
It was initially specified in the 1995 paper "Integrity primitives for secure information systems." (I found this info via this link).
In particular, the specification is contained in this document.
I draw your attention to page 75 of the document (on page 7 of the pdf).
The four constants used in these operations are not randomly chosen; they
are the integer part of $2^{30}\sqrt{2}, 2^{30}\sqrt{3}, 2^{30}\sqrt[3]{2}, 2^{30}\sqrt[3]{3}$ respectively. However, there is no specific reason for this choice.
This explains the constants in the added constants part of the file you linked --- they are nothing up my sleeve numbers.
Unfortunately, the particular table you ask about is not satisfactorily explained.
The authors state that they reproduce a modification of the compression function of MD4 (including the table you noticed), but simply state that they include modifications of B. den Boer, which they cite as Personal Communications (so their particular reason for the modification is unknown).
Unfortunately, other material on the cipher is not enlightening either.
Consider this attack on the hash.
The authors mention (as is readily apparent) that the "selection of message word" indices must specifically be a permutation (this was mentioned in the initial specification as well), but it is not clear why those particular permutations were chosen.
The last thing that I will mention is that sometimes you are in a situation where there are many possible choices of some structured object (like a permutation, so you cannot hope the digits of $\pi$ will suffice), and you need to pick one.
One strategy you can do (rather than pulling it out of thin air) is:
- try to "rank" the structured objects according to some efficiency metric, and then
- choose the "first" (in some natural ordering) of the "most efficient" objects.
This is vague, so a particular example may be useful.
The design of AES requires arithmetic over $\mathsf{GF}(2^8)$. Any irreducible degree 8 polynomial over $\mathbb{F}_2$ defines a "different" (but all mutually isomorphic) copy of $\mathsf{GF}(2^8)$.
Given that this is the case, which polynomial do you choose in the design of AES?
The AES designers justify this choice (and others which you may find interesting) in section 7 of their proposal.
The polynomial $m(x)$ ... for the multiplication in $\mathsf{GF}(2^8)$ is the first one of the list of irreducible polynomials of degree 8, given in [LiNi86, p. 378].
So they appeal to some ordering by authors other than them.
I have also seen (and thought I had for AES in particular) the choice to:
- collect all irreducible polynomials
- sort them by hamming weight (the efficiency metric)
- of those of minimal hamming weight, choose the lexicographically first one.
Of course, this is unfortunately not useful for your particular table.
