# Re: Null integrity protection and encryption algorithms

*From*: super manidhan <super.manidhan@xxxxxxxxx>*Date*: Fri, 6 May 2011 16:29:00 -0700 (PDT)

On May 7, 4:21 am, mike clark <undefinedsp...@xxxxxxxxx> wrote:

But, I wonder why should we need to go in for an algorithm to make

'b' appear as 'b' or apply an algorithm to get a 32-bit MAC of all

zeros ?

Isn't it enough to send it directly without applying any NULL

integrity protection

or NULL encryption algorithm ?

Any guesses? What if you have a predefined protocol?

Okay.

But anyhow,

One of the reason for this query is because this algorithm inturn

consumes some processor instruction cycles and there is an

impact on performance/energy consumption. So, isn't it enough

to send without applying either the NULL integrity protection or

NULL encryption algorithm if it were to behave such that

NULL(b) = I(b) = b ?

I wonder Why should we need to go in for an algorithm to make

'b' appear as 'b' or to generate a 32-bit MAC of all zeros .

Why can't we just make a copy of 'b' to the output of the encryption

directly instead of doing the NULL encryption algorithm to get 'b'

as encrypted output ?

Also, similarly, why can't we fill the 32-bit MAC with all zeros

instead of

applying the NULL algorithm to get a 32-bit MAC of all zeros ?

By this method, we can improve the performance becuase using

an algorithm will consume a cycle . But, i wonder why they came

up with a NULL algorithm to make 'b' to appear as 'b' or to fill zeros

in 32-bit MAC ?

Thx in advans

.

**References**:**Null integrity protection and encryption algorithms***From:*super manidhan

**Re: Null integrity protection and encryption algorithms***From:*mike clark

**Re: Null integrity protection and encryption algorithms***From:*super manidhan

**Re: Null integrity protection and encryption algorithms***From:*mike clark

- Prev by Date:
**Re: Null integrity protection and encryption algorithms** - Next by Date:
**Analyses of scrypt** - Previous by thread:
**Re: Null integrity protection and encryption algorithms** - Next by thread:
**Analyses of scrypt** - Index(es):