For algos see this like first

http://slideplayer.com/slide/5157979/
Then read this once
Hash_RC6 Variable length Hash
algorithm using RC6
here, we present a hash algorithm using RC6 that can generate hash value of variable
length. Hash algorithms play major part in cryptographic security as these algorithms are
used to check the integrity of the received message. It is possible to generate hash
algorithm using symmetric block cipher. The main idea behind this is that if the
symmetric block algorithm is secure then the generated hash function will also be secure
[1]. As RC6 is secure against various linear and differential attacks algorithm presented
here will also be secure against these attack. The algorithm presented here can have
variable number of rounds to generate hash value. It can also have variable block size.

Are hash algorithms with variable length output?

I understand that for example MD5 produces a 128 bit hash value from a given text of
variable size. My question is if there is a hash-like algorithm that will produce a hash
value where one can specify the length of the outcome? So one would specify that that
given any input the hash value (output) should be say 1000 bits.
For example, I would like to produce a hash value of the same length as the input. One
way that I had thought of doing this would be to just encrypt the input somehow, but this
would probably be easy to break, since one would just decrypt.
Another way I had thought about would be to divide the input up into say 128 bit chunks
and then do MD5 (or some other hash) on each part and then just create one long string
with the hashes of all the strings. However, I can see that a change in the input in one
byte only would change 128 bits of the output.
also

you can use the output of any conventional hash function to key a stream cipher (or a
block cipher in a streaming mode like CTR), and then take the output of the cipher as
your digest.
However, there has been a trend in modern hash function design to support arbitrarylength output directly, without the need for additional layers. For example,
the cryptographic spongeconstruction has this feature built in: you absorb the input into
the sponge and then squeeze as much output out of it as you want.
Out of the five SHA-3 finalists, two Skein and Keccak support arbitrary output
lengths. Keccak does this by virtue of being a sponge hash; Skein instead internally uses
a system very similar to D.W.'s CTR-mode construction, reusing its Threefish tweakable
block cipher for both input compression and output generation.
The SHA-3 competition is still running, even if the original schedule called for the winner
to have been announced a few months ago. Still, the fact that all the finalists have
survived so far does indicate that they're most likely all more than secure enough for
practical purposes.
Actually, the SHA-3 schedule is "by the end of 2012" so it's about where one would expect. Jon CallasAug 21
'12 at 19:19
Note that the arbitrary output length unfortunately is not considered by NIST, so it remains to be
seen if this feature will receive as much scrutiny as the use of specific size hashes. And if a finalist
actually contains the feature, then it may not be present in many implementations, as the method of
generating a random output is not defined. Maarten Bodewes Aug 25 '12 at 16:30
1

As a note to future readers, here we are a year after most of the answers to this question were
written, and the SHA-3 contest has now been decided. Keccak was selected.

Again
Sure. If you want a bb-bit hash of the message mm, then use the first bb bits of AESCTR(SHA256(mm)). That'll do the trick.
In other words, compute SHA256(mm) and treat the resulting 256-bit string as a 256-bit
AES key. Next, use AES in counter mode (with this key) to generate an unending stream
of pseudorandom bits. Take the first bb bits from this stream, and call it your hash.
(Make sure you don't treat the IV as part of this stream, as the IV won't be

pseudorandom. You may need to manually remove the IV first before taking the
first bb bits.)
Security. This should be secure as long as b160b160 or so. In particular, a collision
attack is expected to take about 2min(b,256)/22min(b,256)/2 steps of computation, given
our current knowledge of AES and SHA256. So, as long as you don't choose a value
of bb that is too small, you should be good. Choosing a value of bb larger than 256
does not give you greater security against collisions, but that's irrelevant: the level of
security will already be way more than enough for any reasonable application, so you're
good.
his might be a silly question, but can you pass a zero-filled buffer as plain-text (of size b bits) to an AES block cipher (say
CBC or whatever), use the SHA-256 hash to derive the key and initialization vector, and then take the first b bits of
cipher-text to be used as your output? Is this just as secure? Seegist.github.com/4600432 for Node.js
implementation. BMiner Jan 23 '13 at 0:35
@BMiner, it depends upon the mode. For CBC mode, this will work as long as you
make sure to first remove the IV (since the IV won't be random), and take the
first bb bits of the remaining ciphertext. I would expect something similar to hold for
other reasonable modes too but I haven't thought about it carefully. D.W. Jan 23 '13 at
9:30
thanks for your response. What did you mean by, "make sure to first remove the IV?" In
Node.js, if you pass a "password" into the Cipher's constructor, a key and IV is derived
using EVP_BytesToKey. This means that the IV won't be random, but isn't that the idea?
If the IV was random, you wouldn't get consistent, predictable hash
results? BMiner Jan 24 '13 at 15:51
1

@BMiner, sometimes some crypto libraries will generate the IV for you and include the
IV in the ciphertext. In other words, when you encrypt, you pass in a key and a message,
and you get back a ciphertext, where the ciphertext includes the IV somewhere in it. If
your library is like that, you need to remove the IV (and make sure that the IV always
starts at 0). This gets easier if you implement AES-CTR yourself, so you can force it to
start at IV 0 and make sure that the output only includes the generated pseudorandom
stream (and not the IV). D.W. Jan 24 '13 at 19:11

@curious, that's a different question, which is probably best answered separatately, but
the concise answer is: treat the output of SHA256(m) as a 256-bit integer, reduce it
modulo 360, and use the remainder a syour random number. D.W. Mar 18 '14 at 17:41

Again
In general, each combination of a (secure) hash function for input with a (deterministic)

pseudo random number generator for output will work here - one "state of the art"
example is the one given by D.W. (using AES-CTR as PRNG and SHA-256 as hash).
Another way is similar to what PBKDF-2 does to have output with the right length: hash
the input (or a hash of the input) multiple times, each with a different prefix, and
concatenate these outputs:
output = H(1 || M) || H(2 || M) || H(3 || M) || ...

(One could say that this is a special case of the general case before, at least when H is
already a hash of the original message.)
There are some hash functions with a "arbitrary output length" mode, such as Skein (one
of the SHA-3 candidates). (This mode of Skein internally works just like the scheme
above, but it is hidden in one standardized primitive, you don't have to build this
yourself.)
Again

Yes, there are hash-like algorithms that are able to produce variable-length outputs
without any extra efforts. This is something "sponge functions" do. One such sponge
construction isKeccaK which is one of five finalists in the SHA-3 competition.
shareimprove this answer

answered Aug 16 '12 at 11:14

sellibitze
21117

What is the hash value of SHA-3? or how big a hash value do sha3 prod

1 SHA3 is not yet standardized, the resulting digests are therefore not ava
and 1599 bits in theory with a single "squeeze" Richie Frame
Again

I'm curious about your purpose. Generally the primary operation involving a message
digest is ultimately to compare two digest values. Hashing passwords allows comparing
the digest values instead of carrying the super secret password around the systems.
Hashing messages allows the transmitter and sender to verify the data was correctly
received without resending the whole message. Encrypting a hash with a private key
allows them to be decrypted with the public key and then compared to verify the signer's
identity. Even hashing strings in a database allows an efficient indexed search by
comparing and sorting digest values.
In every case of comparison, having the digest values be of equal size enables the
comparison - unequal sizes would never result in an equal result.
If it's a size constraint, a cryptographically secure digest value can always be truncated
with the understanding that there is a corresponding loss in fidelity. (A non secure digest
algorithm might not have the bit dispersal properties that would make such an
assumption safe.)
But you've said you want a "larger" digest. When I think about the meaning of digest, to
me that is a "summary", which is always smaller than that which it summarizes. What are

you hoping to gain by making it larger? Is it a matter of not trusting in the anti-collision
properties of 2^256 possibilities? You have piqued my curiosity.

Thanks for the answer. Since you asked: The reason for my questions wasn't deep at all. I had thought about
padding of keys/passwords, and was thinking that instead of padding key, one could just generate a hash of a
specific length of a key. Thereby all key lengths should be "allowed", but I don't know if this is secure. I will
probably ask a question about this later after I have thought more about it. Thomas Aug 20 '12 at 23:21
I see what you were going for. Random bytes are now
generally used for key padding instead of a fixed value,
to avoid providing a crib to an attacker. The key
attribute to those bytes is unpredictability so they can't
be used against you. I can see why a hash could be
something you'd consider using instead of random
values, but it would still have to be the hash of
something random so the attacker couldn't use it.
When you get that deep, cryptographically random
bytes are already a very good solution to this
problem. John Deters Aug 26 '12 at 5:15

Are variable-length crypto hash functions still susceptible to

collisions?
I just recently learned that the SHA-3 finalist Keccak allows for variable length output. As
the only answer to this question states, "[it] need to have an output length at least equal
to the input length," which I understand just fine. However, I'm curious if this guarantees
against collisions.

Is there any work done to show or prove collision resistance gained by increasing
digest length? If so, how dependent is this resistance on the hash function itself?
(I'm guessing the answer to this is "highly" or "entirely".)

What are the other benefits of allowing variable and arbitrary length output?
If the math on these points is still fuzzy, is variable length output just based on the
intuition that "larger problem space = harder to attack"?
Note my crypto and math expertise is very low, so please add a 'for dummies' section to
any answer you write and I thank you in advance.
hash collision-resistance sha-3

2 Answers
Is there any work done to show or prove collision resistance gained by increasing digest
length?

Actually, as CodesInChaos has mentioned, the variable length versions of Keccak

("SHAKE128" and "SHAKE256") are known not to have any collision resistance beyond
their security level, independent of how long we make the output.
So, what's the point? So, as you ask:
What are the other benefits of allowing variable and arbitrary length output?
That's because collision resistance isn't the only property we want from a randomlooking function. One such alternative use is a Key Derivation Function; this is a function
that takes as input some secret data (e.g. DH shared secrets) and some public data (e.g.
nonces) and converts that into session keys; these are a series of encryption and MAC
keys (and as we might have several such keys, and they're of variable length, this set of
session keys is long and of variable length). Now, a number of KDFs are in use by real
protocols (such as TLS), however these constructions are ad hoc, and actually rather
ugly looking. It would be nice to use a single function that's designed to do that; a
"variable length hash" (or XOF, that's what NIST dubs it) may be cleaner.
3 Answer

Yes. Even if you choose an output length equal to the input length, you expect some
collisions from even an ideal PRF. E.g., if my test code
works: SHAKE256('6',8)=SHAKE256('8',8)SHAKE256('6',8)=SHAKE256('8',8).
Is there any work done to show or prove collision resistance gained by increasing digest
length?
Yes, up to the security bound. According to FIPS 202, the SHA-3 draft, the variable
length SHAKE functions claim the following collision resistance:
SHAKE128: min(d/2, 128)
SHAKE256: min(d/2, 256)
where 'd' is the output length in bits.
The collision resistance depends on the output length, but for SHAKE256 can go higher
than the collision resistance of the corresponding SHA3-256 function, which is limited to
128 bits due to its 256-bit output.
This is because the 512-bit capacity used in SHA3-256 is higher than required for 128bit collision resistance, so that it can have the higher 256-bit preimage resistance
matching other hash functions. This c=2nc=2n was not always to be the case: at one

point they planned for c=nc=n which would have given e.g only 128-bit preimage
resistance for SHA3-256.
If so, how dependent is this resistance on the hash function itself?
The proofs for SHAKEs go back to the sponge construction that Keccak uses. It is not
applicable in general to functions that use other constructions.
Fast Hashing of VariableLength Text Strings

Hash Functions

Basic Cryptography

Cryptographic Algorithms Revealed

Definition - What does RC6 mean?

RC6 is a fast block cipher. It was developed based on RC5 and does its job quicker than RC5
due to more registers. RC6 uses integer multiplication in its algorithmic computation. RC6 is also
rotation-dependent on every word bit, as opposed to the insignificant bits with RC5

explains RC6
RC6 is a derivative of RC5 and is a block cipher designed for RSA Security(

RSA Security is a United States-based organization that

creates encryption, network and computer security products.
Ron Rivest Adi Shamir, and Len Adleman founded RSA as an independent
company in 1982.RSA derives from the initials of each of the founders
names. RSA was acquired by EMC Corporation in 2006 and operates as
a corporate division of that company.

RSA provides more than 30,000 customers around the world with the essential security capabilities to
protect their most valuable assets from cyber threats. With RSAs award-winning products,
organizations effectively detect, investigate, and respond to advanced attacks; confirm and manage
identities; and ultimately, reduce IP theft, fraud, and cybercrime.

Specialties
Security, Identity Assurance, Encryption, Key Management, Advanced Threats, Network Monitoring,
Network Forensics, Security Analytics, Adaptive Authentication

Website

http://www.rsa.com

Industry

Computer & Network Security

Type

Public Company

Headquarters

174 Middlesex Turnpike Bedford,MA 01730 United States

Company Size

1001-5000 employees

Founded

1984

).

{ RSA products:

RSA makes the public key infrastructure (PKI) encryption standards by

which much of the Internets secure communication are run. Other RSA
products include hardware tokens,software tokens, SecurID, Besafe and
enVision.
RSA encryption is based on use of a public and a private key. Typically
a key fob (such as an RSA SecurID security token) is used by employees in
security-sensitive companies. The token generates a public key that
changes every minute. This string is combined with a users password to
make a hybrid one-time use password.
On secure websites, a digital certificate with the public key is made
publicly available. The private key is never sent over the Internet and is
used to decrypt text that is encrypted with the public key. The senderss
identity can also be verified using the public key. Both of these keys are
created at the same time by the RSA algorithm.

RSA controversy:
In December 2013, Reuters reported that the RSA had accepted a 10
million dollar payment to place a backdoor for the NSA in their Dual
Elliptic Curve random number generation system. In interview, the
companys chief technologist, Sam Curry, declined to answer whether that
allegation was true. The NSA actively promoted the compromised security
product in its role as security consultants. Reuters also reported that the
companys website security tool Extended Random made the seemingly
strong encryption 10,000 times faster for the NSA to crack
}
RC6 uses four working block size registers in its algorithmic computations, whereas RC5 uses
only two. Thus, RC6 is faster. RC6 was designed as part of the Advanced Encryption Standard
(AES) competition, where it was a finalist. It is a propriety algorithm patented by RSA Security.

Reconfigurable Computing for RC6

Cryptography
Here we present an emerging reconfigurable hardware that potentially delivers flexible
high performance for cryptographic algorithms. MorphoSys, a dynamic reconfigurable
architecture that sustains implementations that can yield into equally or even better
performance results than custom-hardware and yet preserves all the flexibility of
general-purpose processors. With today's great demand for secure communications
systems, networks and the Internet, there is a growing demand for real-time
implementation of cryptographic algorithms. As a case study, this paper presents the
mapping and performance analysis for one of the five AES finalists cryptographic
algorithms, namely RC6. Being an important and secure cryptographic algorithm, RC6 is
considered well chosen to be mapped in order to test and evaluate the suitability of
dynamic reconfigurable computer (RC) systems such as MorphoSys.
Examples Data

Security and Privacy in Cloud Using RC6

and SHA Algorithms
Here we describe a new security designed data privacy and security in cloud storage system. The
security algorithm is taken in different approaches to provide security in many cloud provider for cloud
server. In cryptographic cloud implementation algorithms are Caesar cipher, RSA Algorithm, Vinegere
Cipher, Homomorphic Encryption, RC Block Cipher, DES Algorithm etc.,. The cryptographic Encryption
and Decryption taken as Client and server side processes. In Encryption process takes in Client side
using an RC6 (Block Cipher Algorithm) and SHA3(Secure Hash Algorithm) before data store in the cloud
server or cloud storage. The server side decryption is taken in Authentication methodology. The access
data in cloud categorized in (Public, Hybrid and Private Cloud) Public cloud access in open access
documents to view not download, the Hybrid User can access the document with authentication code
from the cloud server system, Private User can Access all type of secured data get Authenticate from the
client system or client Email code verification in the Cloud Data. Authentication process to prevent the
intruder, malicious attacker, Inside Attacker, Outside Attacker

Keywords
Cloud Computing, RC6 Algorithm, SHA3 Algorithm, Cryptography, Encryption, Decryption, Security.