Consider the following family of polynomials in $K[x,y]$, where $K$ has characteristic zero:

$f_n(x,y)=(x+y)^n+(x-1)y^n,$

for $n\geq 3$.  I can prove that $f_n(x,y)$ has an irreducible factor of degree $n-1$ in $x$. I also know that the galois group of $f_n$ over $K(y)$ is the symmetric group of degree $n-1$, but am having trouble proving this.

Here is an alternative form for $f_n$: make the substitution $x\rightarrow xy$ and divide by $y^n$.  this gives:

$g_n(x,y)=(x+1)^n+yx-1.$

Substituting $-n$ for $y$ in $g_n(x,y)$ we get:

$g_n(x,-n)=x^2h(x),$

where $h(x)$ is separable (EDIT: $h(x)$ is the subject of this question).

Alternatively, substituting $x\rightarrow x-1$ into $g_n(x,y)$ gives us a polynomial which factors as:

$(x-1)(x^{n-1}+x^{n-2}+\ldots +x^2+x+y+1)$

It seems as though it shouldn't be hard to show that some specialisation of $y$ into this gives a polynomial with galois group $S_{n-1}$ over $K$...but I'm well and truly stuck.

Any advice much appreciated! 


Question: Is my session-less authentication system secure?
Answer: Your basic concept is not new: you want to have some state associated with the user, but you do not want to store that state yourself. Instead, you store it on the client (in a cookie). Since you want to protect against alterations of such a state (e.g. a client building a cookie from scratch), you need an integrity check, such as a Message Authentication Code. Your construction with a hash function is a crude MAC. It so happens that it is a weak MAC with the usual hash functions, because of the length extension attack.

If you want a MAC, use a strong one, and that means HMAC. It is standard and widespread.

Of course, storage of the secret key (for MAC computations) is a tricky point. Something embedded in the "source code" of the application exists as a file, which (by nature) the application can read, making it vulnerable to exploits which obtain illegal read access to arbitrary files. It would be better (but harder) to arrange for the MAC key to be obtained dynamically by the application through some local communication protocol (the application contacts a local server, which gives the key only to the application); that way, the key would only exist in the RAM of the application, not as a file readable with the access rights of the application. It would not be absolute protection (if your server gets thoroughly hacked, well, that's it) but it would be stronger in practice.

I see that you include the hashed password in the data which is MACed. This is a bit weird; you already have the MAC as authentication: the MAC proves that the cookie data is genuine, thus there is no need for further authentication.

Blowfish is not a hash function; it is a block cipher (or a type of fish) and, as such, cannot be used for hashing unless it is considerably modified, which would mean homemade cryptography, and that's not a good idea.



If you are offloading state on the client, you might want to offload state which the client himself should not know. This means that you may also need encryption. Combining encryption and MAC securely is not as easy as it seems; there are modes for that. I recommend EAX.



Be warned that not maintaining state makes you inherently weak against replay attacks. That's unavoidable. You can minimize the damage by using short validity ranges (e.g. a cookie expires within 15 minutes).