Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

I'm doing research about "Cryptographic attack methods in Web Application" so I have some questions to ask you guys:

  1. Block Cipher vs Stream Cipher, which is more common used in Web Application?
  2. How and Where is Stream Cipher implemented in Web Application?

Hope to get your response soon :)

share|improve this question
4  
This is a very broad question - web applications are used for all kinds of things. Could you be more specific about some uses that you're interested in? –  archie Nov 22 '13 at 5:39
    
Hi @archie, I already know Stream Ciphers are best for cases where the amount of data is either unknown, or continuous. And I think the kinds of data are not common in Web Applications. Is this correct if I say that Block Cipher is more common than Stream Cipher in Web Applications? –  hanhtw Nov 22 '13 at 7:57
    
The choice of cipher in most cases is driven by factors other than the type of application, whether it's a web app or not - i.e. performance, availability, standards compliance. Both block and stream ciphers have a lot of overlap in what they're good for, and both can be used for continuous/unknown length data streams. Searching this site for block cipher vs stream cipher, or reading the Wikipedia articles that describe them should give you a good background. –  archie Nov 22 '13 at 8:35
    
Web applications typically use HTTPS. Which encrypts the TCP stream using SSL/TLS. SSL can use both stream and block ciphers. In principle they're both fine for this, but SSL made some dumb design choices that weaken block ciphers. On the other hand it only supports a decent stream cipher (AES in GCM mode) in TLS 1.2 which isn't widely supported yet. –  CodesInChaos Nov 22 '13 at 10:48
add comment

closed as too broad by D.W., hunter, figlesquidge, e-sushi, Gilles Feb 18 at 13:42

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

up vote 3 down vote accepted

Very few cryptosystems actually use a block cipher directly (i.e. in "ECB mode") to encrypt data — and those that do usually only do so because whoever designed them didn't really understand how a block cipher should be used.

Rather, the main use of block ciphers in cryptography is as versatile building blocks for other cryptographic components, such as stream ciphers, message authentication codes, hash functions, KDFs etc. In particular, the usual way to use a block cipher to encrypt free-form data is by using a mode of operation such as CBC, CFB, OFB or CTR (or an authenticated mode like EAX, GCM, OCB or SIV) which actually uses the block cipher to construct a kind of stream cipher.

Thus, the actual distinction, insofar as there is one, is not between block ciphers and stream ciphers as such, but between stream ciphers based on block ciphers (like AES-CTR or AES-CBC) and "primitive" stream ciphers not based on block ciphers (of which the most common is probably RC4).

I don't really have any reliable statistics on how much those are respectively used in web applications, but my gut feeling would be that the majority (say, 95%) of (symmetric) encryption schemes used in such systems are probably based on block ciphers (mostly AES, some 3DES, occasionally rarer types like Serpent, Blowfish or old single DES). Their main competitor is RC4, with a small but non-negligible share (say, 5%), while all other "primitive" stream ciphers (like the eSTREAM ciphers) are probably marginal (< 1%), mostly because few crypto libraries support them.

(The share of RC4 probably goes up a bit if its use in SSL / TLS is included in the total, particularly since many websites switched to it after the BEAST attack exposed weaknesses in the TLS 1.0 implementation of AES-CBC.)

share|improve this answer
1  
A nitpick: I fail to see how the CBC mode of operation of a block cipher can be classified as a stream cipher, which to me implies a linear relation between plaintext and ciphertext for a given key. CTR and OFB have this property, ECB and CBC do not, CFB has it only locally. I upvoted nevertheless. –  fgrieu Feb 18 at 9:57
add comment
  1. I don't think stream ciphers are implemented in Web applications ( Actually they are not approved because of weak security) However the protocols like IPsec, SSL and PGP etc do make use of various block ciphers( e.g AES ). Web application security is totally dependent upon the security at individual OSI layers.
share|improve this answer
1  
[downvoted] A significant portion of TLS connections use RC4 –  figlesquidge Feb 17 at 22:51
    
1) RC4 is unfortunately common. 2) There is no reason to believe that stream ciphers are weaker in principle than block ciphers. For example Salsa20 or Keccak in duplex mode are believed to be secure. 3) You can build stream ciphers from block ciphers, e.g. AES in CTR mode is a stream cipher. This proves that if you know of to build a secure block cipher, then you can also build a secure stream cipher. –  CodesInChaos Feb 18 at 9:12
    
My experience is that there is a movement away from traditional block cipher modes like CBC towards stream cipher modes. For example AES-GCM is based on the AES-CTR, a stream cipher mode. Google will probably add TLS suites based on the stream cipher ChaCha soon, and I believe some SSH implementations already did add similar suites. –  CodesInChaos Feb 18 at 9:15
add comment

Maybe you have a more specific class of applications in mind, but in my experience there is fairly limited use of cryptography in web applications. The cases I can think of:

  • SSL, in which case the encryption is done by the web server and not by the application (though maybe you don't consider that distinction relevant). The type of encryption is then determined by the browser and server configuration.
  • Password verification: Correctly done, this doesn't use encryption.
  • Credential storage: The application needs to store the credentials it uses to access some back-end server. Some frameworks have built-in support for this, here is ASP.Net.

You might have data stored on an encrypted volume, but then that's not application-level cryptography. If there is a need to encrypt data beyond that list, I think/hope that developers realize that key management is a hard problem to solve and so defer to something provided by the platform, e.g. DPAPI.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.