Using a hash (like SHA-256) vs AES as the source for pseudo-random values in Feistel network? This question is in relation to Wikipedia article on Format Preserving Encryption 

It says the following


  It is also possible to make a FPE algorithm using a Feistel network. A Feistel network needs a source of pseudo-random values for the
  sub-keys for each round, and the output of the AES algorithm can be
  used as these pseudo-random values.


However I was taking a look at an implementation of FPE (Botan Crypto library).   It is based on the scheme FE1 from the paper "Format-Preserving Encryption" by Bellare, Rogaway, et al

In the implementation I think it is using the SHA-256 hash to generate the pseudo-random values.  

How does this compare (with respect to security) to the alternative of using the AES algorithm to generate the pseudo-random values?

Are both equally valid methods?
A Feistel network is a way of constructing an invertible permutation from a (possibly non-invertible) function. If the function used is pseudorandom and has a large domain, then 3-4 rounds yields a pseudorandom permutation (3 rounds suffice if the adversary can only ask "compute" queries, and 4 rounds are needed if the adversary can ask "invert" queries). This is the famous Luby-Rackoff result. In the format-preserving constructions, more rounds are needed since the domain of the function can be small and this means that collisions are likely, etc.

In any case, these constructions can use ANY pseudorandom function. Thus, AES truncated to the appropriate output length is fine. HMAC is also very reasonably considered a pseudorandom function. Is plain SHA256 a pseudorandom function? Well, it depends exactly on what you do. If you compute $F_K(x) = SHA256(K || x)$ then this is certainly not pseudorandom due to extension attacks (given $F_K(x)$ it is possible to compute $F_K(x||y)$ for some $y$). However, if you know that you are only using a fixed length, or you encode that length, then it's a reasonable assumption. Personally, I prefer the HMAC assumption if you wish to base yourself on a hash function. However, I think that AES is the best choice (it's also much faster...).