A Cipher with 2 methods for encryption/decryption
forString

As discussed already in comments, your forString method is not needed because map is available to Scala Strings.  But if you do need to construct such a method, your design is not best practice.  Specifically, you create a local var, append to it repeatedly from within a for block and return that.  

This block

    var newStr = ""
    for(c &lt;- str) { newStr += f(c) }
    newStr


can be written simply as

    for (c &lt;- str) yield f(c)


Updating an external var from within a for block is a stateful, potentially error-prone, very non-FP practice which you should use with care.  It is not needed here.  Leave the compiler to construct and return the string - it will be more efficient and your code is cleaner as a result.

(It will be more efficient because in the for-yield block, the compiler knows it is creating a sequence one item at a time and begins each step with a ready pointer to the end of the collection.  In contrast, when your code explicitly appends to the end of a sequence each time, it has to traverse the entire sequence each time.  No handy reference to the end of the string is cached. Appending to strings is expensive.)

wrap

Both the original version and the modulo alternative in your answer use if... else if... then chains.  These are a bad smell.  All three of your options depend upon the value of the input parameter, but nothing about an if-elseif-then chain forces you to cite that parameter in each successive condition.  Pattern matching would at least ensure that the same object is being assessed for each action.  That would look something like this:

n match {
    case _ if (n &gt; cHARMAX) =&gt; (cHARMIN + (n - cHARMAX) % cRANGE)
    case _ if (n &lt; cHARMIN) =&gt; (cHARMAX - (cHARMIN - n) % cRANGE)
    case _ =&gt; n
}


However, although I am still not sure why you have this function in there, I think this is what you are trying to do:

n match {
    case _ if (n &gt; cHARMAX) =&gt; cHARMIN + ((n - cHARMIN) % cRANGE)
    case _ if (n &lt; cHARMIN) =&gt; cHARMAX - ((cHARMIN - n) % cRANGE)
    case _ =&gt; n
}


Key length

Repeating the key until it is as long as the message is a waste of resources (more so, the longer the message becomes).  Just leave the key in its original size.  There are several ways to iterate through the message and (effectively or literally) use modulo arithmetic to fetch the corresponding character from the key.


Create an endlessly repeating Stream from the key (fast and efficient).  Then you can just iterate through both in step (for example, using zipped) 
for (i &lt;- message.indices) yield myFunction(message(i), key(i % key.length)) (reasonably fast and efficient)
Use zipWithIndex and map to turn the message into a list of tuples (each character bundled with its index) and then iterate through that, using modulo arithmetic on the index to fetch the right key character (less efficient, slower).


Option 1 is best

Cipher class design

The most curious thing about your Cipher class is that its Apply method takes a message as a parameter.  This is not good OO design and it also inverts the meaning of the word (OK, cipher can mean an encrypted text but more commonly it means one particular encryption method with one particular key choice).  It would make more sense for a cipher object to have the key (and possibly some other parameters like, for example, the range of valid characters) as a field.  So you could create a cipher instance containing the key "MyAmazingSecretCode" and then use that object to encrypt or decrypt as many messages as you want.  As things stand, Cipher is mostly a java-like utility class containing static methods, offering no way to maintain any state.

Having the two different encryption options in one class is also less good.  Are you going to rewrite this class every time you add another variant on the encryption method? 

Consider, instead, a basic Cipher class or trait or even interface, which describes the key interface methods (setting the secret, encrypting, decrypting).  If it is a class or trait, you could also design an "encryption strategy" trait from which specific encryption methods (your simple offset and your substitution key, as two examples) could be derived.  You could then mix the appropriate strategy trait into the Cipher class to provide a working cipher.  If you choose to make Cipher an interface, then your two strategies could be separate classes which each incorporate that interface.  Which to choose depends on larger design considerations.