dm-crypt, new IV and standards

dm-crypt, new IV and standards

[Carl-Daniel Hailfinger]

Hi,

after having read what I believe to be all dm-crypt related mails on lkml,
I have a question which I could not find an answer for:
(and I noticed Andrew Morton worrying about backwards compatibility)

Would it be sensible (AFAICS there is not technical limitation) to reserve
512/1024/2048/whatever bytes at the beginning of every backing device for
dm-crypt so that the dm-crypt device could get some info about the used
methods automatically?

So this meta-information superblock could contain the following:
- A magic string like CRYPTSPACE (like SWAPSPACE2)
- The key used to encrypt the device (the key would be encrypted with the
password)
- The IV algorithm used
- The cipher used
- The way the password was hashed
- If some conversion was underway last time the dm-crypt device was accessed

This way, the following benefits would appear:
- New dm-crypt devices can be differentiated from old cryptoloop ones
- Since the password is independent of the key, you can change the
password without reencrypting the entire device.
- Since the key is independent of the password, you can change the key,
reencrypt the entire device and still keep your old password.
- You can change the default IV to something more secure than the current
default one without having to fear userland breakage.
- There are multiple ways to hash a password and with the current scheme
we have to try all of them if we do not know which version of the tools
was used to create the file.
- If the device is currently being reencrypted and is halfway through and
the power fails, we would know that some part of the device is old
encryption and some part is new encryption.
- New (more secure) crypto algorithms/ IV generation schemes/ passphrase
hashing schemes could be added (or even made default) without violating
the principle of least surprise.

I am not an expert in crypto, so if you tell me this would reduce security
or cause other problems, I will accept that. I am aware that the more
information an attacker has, the easier it is for him to break the encryption.


Regards,
Carl-Daniel

Re: dm-crypt, new IV and standards

[Christophe Saout]

Am Do, den 19.02.2004 schrieb Carl-Daniel Hailfinger um 23:06:

> Would it be sensible (AFAICS there is not technical limitation) to reserve
> 512/1024/2048/whatever bytes at the beginning of every backing device for
> dm-crypt so that the dm-crypt device could get some info about the used
> methods automatically?

All this can be done in userspace by the setup tool. It then tells the
kernel to start the device at a certain offset. It also has the
advantage that you can change your password without needing to reencrypt
your data (you keep your master key in the "superblock" encrypted with
the passphrase).

> So this meta-information superblock could contain the following:
> - A magic string like CRYPTSPACE (like SWAPSPACE2)
> - The key used to encrypt the device (the key would be encrypted with the
> password)
> - The IV algorithm used
> - The cipher used
> - The way the password was hashed
> - If some conversion was underway last time the dm-crypt device was accessed

Exactly. I like the format LVM2 uses. It basically puts the metadata
into a text file with a magic header string there.

> This way, the following benefits would appear:
> - New dm-crypt devices can be differentiated from old cryptoloop ones
> - Since the password is independent of the key, you can change the
> password without reencrypting the entire device.
> - Since the key is independent of the password, you can change the key,
> reencrypt the entire device and still keep your old password.
> - You can change the default IV to something more secure than the current
> default one without having to fear userland breakage.
> - There are multiple ways to hash a password and with the current scheme
> we have to try all of them if we do not know which version of the tools
> was used to create the file.
> - If the device is currently being reencrypted and is halfway through and
> the power fails, we would know that some part of the device is old
> encryption and some part is new encryption.

I've started to write a userspace program for reencryption. I don't know
if this is very clever because I have to lock the part that is currently
beeing reencrypted (deadlocks & co). Perhaps as another dm target like
dm-mirror for pvmove? We'd have to keep a log or something because we
don't *exactly* know what has been successfully written. This would mean
a lot of seeks. It's complicated if it has to be safe against crashes
and power outages.

> - New (more secure) crypto algorithms/ IV generation schemes/ passphrase
> hashing schemes could be added (or even made default) without violating
> the principle of least surprise.

Yes.

> I am not an expert in crypto, so if you tell me this would reduce security
> or cause other problems, I will accept that. I am aware that the more
> information an attacker has, the easier it is for him to break the encryption.

Other people are already doing this. And I'm not a crypt expert either.
I was just interested in device-mapper and just copied the mechanism
cryptoloop used... (but I'm not completely stupid either ;))

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

If others on the list care to do this, I'll give recommendation on how to 
implement the security (hmac, salt, iteration counts, etc).  But I think
this may break backward compatibility.  Can anyone speak to this?

JLC


On Thu, Feb 19, 2004 at 11:20:37PM +0100, Christophe Saout wrote:
> Exactly. I like the format LVM2 uses. It basically puts the metadata
> into a text file with a magic header string there.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[James Morris]

On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:

> If others on the list care to do this, I'll give recommendation on how to 
> implement the security (hmac, salt, iteration counts, etc).  But I think
> this may break backward compatibility.  Can anyone speak to this?

Please focus your recommendations on security, not backward compatibility
with something that is new to the kernel tree, broken and maintainerless.

Thanks,


- James
-- 
James Morris
<jmorris@redhat.com>

2.6.3 adaptec I2O will not compile

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1478 bytes --]

when attempting to compile in support for the adaptec 2100/3100 series
Raid card I get the following errors. I have attached my config

  CC      drivers/scsi/aic7xxx/aic7xxx_pci.o
  CC      drivers/scsi/aic7xxx/aic7xxx_osm.o
  CC      drivers/scsi/aic7xxx/aic7xxx_proc.o
  CC      drivers/scsi/aic7xxx/aic7xxx_osm_pci.o
  LD      drivers/scsi/aic7xxx/aic7xxx.o
  LD      drivers/scsi/aic7xxx/built-in.o
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
root@dlang:/usr/src/linux# make  bzImage
make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
  CHK     include/asm-i386/asm_offsets.h
  CHK     include/linux/compile.h
  CC      drivers/scsi/dpt_i2o.o
drivers/scsi/dpt_i2o.c:32:2: #error Please convert me to
Documentation/DMA-mapping.txt
drivers/scsi/dpt_i2o.c: In function `adpt_install_hba':
drivers/scsi/dpt_i2o.c:977: warning: passing arg 2 of `request_irq' from
incompatible pointer type
drivers/scsi/dpt_i2o.c: In function `adpt_scsi_to_i2o':
drivers/scsi/dpt_i2o.c:2118: structure has no member named `address'
include/scsi/scsi_host.h: At top level:
drivers/scsi/dpt_i2o.c:165: warning: `dptids' defined but not used
make[2]: *** [drivers/scsi/dpt_i2o.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

David Lang

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan


[-- Attachment #2: Type: TEXT/PLAIN, Size: 20880 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
# CONFIG_STANDALONE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
# CONFIG_MODULES is not set

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET_EMULATE_RTC is not set
CONFIG_SMP=y
CONFIG_NR_CPUS=8
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_EDD is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set
# CONFIG_PM_DISK is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set
CONFIG_ACPI_BOOT=y

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_USE_VECTOR is not set
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
CONFIG_PARPORT_SERIAL=y
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_IDEDMA_PCI is not set
# CONFIG_IDE_CHIPSETS is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
CONFIG_SCSI_DPT_I2O=y
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_BOOT=y
CONFIG_FUSION_MAX_SGE=40

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Macintosh device drivers
#

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
CONFIG_IP_NF_NAT_NEEDED=y
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=y
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
CONFIG_ADAPTEC_STARFIRE=y
# CONFIG_ADAPTEC_STARFIRE_NAPI is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
# CONFIG_EEPRO100_PIO is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
CONFIG_EPIC100=y
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_UINPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=2048
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_JFS_FS=y
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_SECURITY is not set
CONFIG_XFS_POSIX_ACL=y
CONFIG_MINIX_FS=y
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_EXPORTFS is not set
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_GSS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_NEC98_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_TEST=y

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_PC=y

Re: dm-crypt, new IV and standards

[Carl-Daniel Hailfinger]

Jari,

since mainline cryptoloop/dm-crypt implementation is being changed right
now and you were complaining about it in the past, can you participate in
the discussions (there's also a parallel thread titled "[PATCH/proposal]
dm-crypt: add digest-based iv generation mode") so you don't have to
complain afterwards?

James Morris wrote:
> On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:
> 
> 
>>If others on the list care to do this, I'll give recommendation on how to 
>>implement the security (hmac, salt, iteration counts, etc).  But I think
>>this may break backward compatibility.  Can anyone speak to this?
> 
> 
> Please focus your recommendations on security, not backward compatibility
> with something that is new to the kernel tree, broken and maintainerless.


Thanks,
Carl-Daniel

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Fri, Feb 20, 2004 at 04:26:04PM -0500, James Morris wrote:
> On Fri, 20 Feb 2004, Jean-Luc Cooke wrote:
> 
> > If others on the list care to do this, I'll give recommendation on how to 
> > implement the security (hmac, salt, iteration counts, etc).  But I think
> > this may break backward compatibility.  Can anyone speak to this?
> 
> Please focus your recommendations on security, not backward compatibility
> with something that is new to the kernel tree, broken and maintainerless.

Ah!  Ok.  :)  Here are my recommendations.

Well, CTR mode is not recommended for encrypted file systems because it is very
easy to corrupt single bits, bytes, blocks, etc without an integrity check.
If we add a MAC, then any mode of operation except ECB can be used for
encrypted file systems.

Also, current encrypted loop back FS's don't have integrity checks.  So we'll
need a place to store this information and update it every time a block is
updated.  For this we'll need to implement the OMAC authentication mode of
operation (I will do this now).  This will slow down the encryption process
of scatter-lists since we will now need to process the data twice (once for
confidentiality, and a second time to compute the message authentication code
- MAC).

At the head of the file system we'll need to store the following:
 - what block cipher is used
 - what mode of operation is used (ECB, OFB, CFB, CBC, CTR)
 - what password hashing algorithm is used, not MD5 (see [4])
 - what the password salt value is - 128 bit in length (see [1])
 - how many HMAC iterations are used to generate the key from the
   salt+password - 32 bit (see [2])

Some data will need to be stored with each block (or at least accessible
every time you encrypt/decrypt a block):
 - the IV - 128 bit in length (see [3])
 - the OMAC value - 128 bit in length

The hash algorithm:    Hash(data)
The HMAC algorithm:    HMAC(key, data)
The Encrypt algorithm: Enc(key, data)
The Decrypt algorithm: Dec(key, data)

Here is how I propose we compute the key (see [1][2]):
 K = HMAC(salt, password):
 for (i=0; i<iteration; i++)
   K = HMAC(salt, K);

Here is how I propose we compute the IV (see [3]):
 Reading a block:
  thisIV = readFromBlock(blockNum);
  /* ... decrypt the block with thisIV ... */

 Writing a block:
  thisIV = readFromBlock(blockNum);
  nextIV = INCMODP128(thisIV); /* nextIV = (thisIV + 1) mod 2^128 */
  /* ... encrypt the block with nextIV ... */

I'm sure there are implementation issues here, please let me know what they
are and we'll see what we can do.

I'll start writing OMAC now.

JLC

[1] Why have a salt?
You want to have salt of adequate size to make precomputing a dictionary of
Hash(...) outputs and thus quickly find the password.  This is common
practice in things like /etc/shadow so I shouldn't get much argument of this
implementation.
Adding a N-bit salt increases the space complexity of an attack by 2^N.

[2] Why iterate the password so many time?
If an attack requires 1 day to iterate though all 8 alphanumeric passwords,
adding a N-iteration hashing will push the attackers time complexity out by a
factor of N.  A iteration value of 2^16 (65536) should be adequate for our
purposes.

[3] Why not use IV == block number or IV == firstIV + block number?
Certain modes of operation (like CTR) begin to leak information about the
plaintext if you ever use the same Key-IV pair for your data.
The IV will need to be updated every time you update the block.
The IV generation does need not be from a cryptographicly strong PRNG,
it need only be different from the previous IV.
So incrementing the IV by 1 mod 2^128 every time you write to the block will
suffice.

[4] What not MD5?
MD5 has been deprecated by every cryptographer of good repute because it is not
being cryptographicly secure against collision attacks (read www.md5crk.com for
more information - shameless plug I know).  Though in this case we're using salted
HMACs, there is no exposure to collision attacks.  It's just good to push people
to use forward-looking algorithms since it's so easy to do so.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Sat, Feb 21, 2004 at 11:48:21AM -0500, Jean-Luc Cooke wrote:
> > Please focus your recommendations on security, not backward compatibility
> > with something that is new to the kernel tree, broken and maintainerless.
 
> I'll start writing OMAC now.

FYI OMAC spec:
  http://crypt.cis.ibaraki.ac.jp/omac/omac.html

As you can see, there is a fixed output no matter how large the input it, the
output is always 128 bits.

So how will this fit into the cipher.c interface?

        case CRYPTO_TFM_MODE_CTR:
                ops->cit_encrypt = omac_compute;
                ops->cit_decrypt = nocrypt;
                ops->cit_encrypt_iv = nocrypt_iv;
                ops->cit_decrypt_iv = nocrypt_iv;
                break;


But now the user will have to call cit_encrypt(tfm, dst[0], src[i], nbytes);
Notice how dest will always have to be dst[0].  Unless we use the hash interface.

Thoughts?

static int omac_encrypt(struct crypto_tfm *tfm,
                       struct scatterlist *dst,
                       struct scatterlist *src,
                       unsigned int nbytes)
{
        return crypt(tfm, dst, src, nbytes,
                     tfm->__crt_alg->cra_cipher.cia_encrypt,
                     omac_process, 1, tfm->crt_cipher.cit_iv);
}

JLC - has CTR mode implemented and will post once he has OMAC done as well.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Andreas Jellinghaus]

Sorry, I know next to nothing about dm-crypt or crypt loop so far.

But I wonder: will it be possible to store some generic data in that place?
Password+Hash mechanism+Salt seemt to be pretty tied to passwords.

I would like it very much, if some rsa encrypted data could be stored instead,
so I can use a smart card with an rsa key to decrypt it.

Regards, Andreas

Re: 2.6.3 adaptec I2O will not compile

[Adrian Bunk]

On Fri, Feb 20, 2004 at 01:52:24PM -0800, David Lang wrote:
> when attempting to compile in support for the adaptec 2100/3100 series
> Raid card I get the following errors. I have attached my config
> 
>   CC      drivers/scsi/aic7xxx/aic7xxx_pci.o
>   CC      drivers/scsi/aic7xxx/aic7xxx_osm.o
>   CC      drivers/scsi/aic7xxx/aic7xxx_proc.o
>   CC      drivers/scsi/aic7xxx/aic7xxx_osm_pci.o
>   LD      drivers/scsi/aic7xxx/aic7xxx.o
>   LD      drivers/scsi/aic7xxx/built-in.o
> make[1]: *** [drivers/scsi] Error 2
> make: *** [drivers] Error 2
> root@dlang:/usr/src/linux# make  bzImage
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
>   CHK     include/asm-i386/asm_offsets.h
>   CHK     include/linux/compile.h
>   CC      drivers/scsi/dpt_i2o.o
> drivers/scsi/dpt_i2o.c:32:2: #error Please convert me to
> Documentation/DMA-mapping.txt
> drivers/scsi/dpt_i2o.c: In function `adpt_install_hba':
> drivers/scsi/dpt_i2o.c:977: warning: passing arg 2 of `request_irq' from
> incompatible pointer type
> drivers/scsi/dpt_i2o.c: In function `adpt_scsi_to_i2o':
> drivers/scsi/dpt_i2o.c:2118: structure has no member named `address'
> include/scsi/scsi_host.h: At top level:
> drivers/scsi/dpt_i2o.c:165: warning: `dptids' defined but not used
> make[2]: *** [drivers/scsi/dpt_i2o.o] Error 1
> make[1]: *** [drivers/scsi] Error 2
> make: *** [drivers] Error 2
>...
> #
> # Automatically generated make config: don't edit
> #
>...
> CONFIG_BROKEN=y
>...

You've disabled
  Code maturity level options
    Select only drivers expected to compile cleanly

> CONFIG_SCSI_DPT_I2O=y
>...

This driver is known to not compile in 2.6 .

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.3 adaptec I2O will not compile

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]


Adrian Bunk wrote:

>On Fri, Feb 20, 2004 at 01:52:24PM -0800, David Lang wrote:
>  
>
>>when attempting to compile in support for the adaptec 2100/3100 series
>>Raid card I get the following errors. I have attached my config
>>
>>    
>>
>  
>
I am currently working on this, so far I've managed to sort out the irq
problems and only have some dma stuff that does not compile.  I don't
think I'm going to bother getting it to compile though and rather
directly convert to the new DMA-mapping stuff.  If anyone has any
pointers and tips and pitfalls I need to look out for, please don't
hessitate to mail me (It will be greatly appreciated).

Jaco
-- 
Once I finally figured out all of life's answers, they changed the questions.
===========================================
This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
===========================================


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3174 bytes --]

Re: 2.6.3 adaptec I2O will not compile

[David Lang]

I received a post from Mark Salyzyn with a new driver that does compile,
he said that he has submitted the patches (I didn't get a chance to try
the new kernel yet, I expect to do that shortly and will report any
problems)

David Lang

 On Thu, 26 Feb 2004, Jaco
Kroon wrote:

> Date: Thu, 26 Feb 2004 00:02:04 -0800
> From: Jaco Kroon <jkroon@cs.up.ac.za>
> To: Adrian Bunk <bunk@fs.tum.de>
> Cc: David Lang <david.lang@digitalinsight.com>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: 2.6.3 adaptec I2O will not compile
>
>
> Adrian Bunk wrote:
>
> >On Fri, Feb 20, 2004 at 01:52:24PM -0800, David Lang wrote:
> >
> >
> >>when attempting to compile in support for the adaptec 2100/3100 series
> >>Raid card I get the following errors. I have attached my config
> >>
> >>
> >>
> >
> >
> I am currently working on this, so far I've managed to sort out the irq
> problems and only have some dma stuff that does not compile.  I don't
> think I'm going to bother getting it to compile though and rather
> directly convert to the new DMA-mapping stuff.  If anyone has any
> pointers and tips and pitfalls I need to look out for, please don't
> hessitate to mail me (It will be greatly appreciated).
>
> Jaco
> --
> Once I finally figured out all of life's answers, they changed the
> questions.
> ===========================================
> This message and attachments are subject to a disclaimer. Please refer
> to www.it.up.ac.za/documentation/governance/disclaimer/ for full
> details.
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig.
> Volledige besonderhede is by
> www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
> ===========================================
>
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: 2.6.3 adaptec I2O will not compile

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

David Lang wrote:

>I received a post from Mark Salyzyn with a new driver that does compile,
>he said that he has submitted the patches (I didn't get a chance to try
>the new kernel yet, I expect to do that shortly and will report any
>problems)
>
>D
>
Somebody just mailed me a patch too, but I found the following discrepancy:

/*
 * scsi_unregister will be called AFTER we return. 
 */
static int adpt_release(struct Scsi_Host *host)
{
    adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
//  adpt_i2o_quiesce_hba(pHba);
    adpt_i2o_delete_hba(pHba);
    scsi_unregister(host);
    return 0;
}

This is used to release the host, now read the comment, and then the
line just before the return.  This line was added by the patch, which
also commented out the quiesce line.  Is it possible to get any
confirmation on how this is supposed to function?

Jaco

===========================================
This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
===========================================


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3174 bytes --]

Re: 2.6.3 adaptec I2O will not compile

[David Lang]

Mark, do you have any comments on this?

On Thu, 26 Feb 2004, Jaco Kroon wrote:

> Date: Thu, 26 Feb 2004 01:28:14 -0800
> From: Jaco Kroon <jkroon@cs.up.ac.za>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: Adrian Bunk <bunk@fs.tum.de>,
>      Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: 2.6.3 adaptec I2O will not compile
>
> David Lang wrote:
>
> >I received a post from Mark Salyzyn with a new driver that does
> compile,
> >he said that he has submitted the patches (I didn't get a chance to try
> >the new kernel yet, I expect to do that shortly and will report any
> >problems)
> >
> >D
> >
> Somebody just mailed me a patch too, but I found the following
> discrepancy:
>
> /*
>  * scsi_unregister will be called AFTER we return.
>  */
> static int adpt_release(struct Scsi_Host *host)
> {
>     adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
> //  adpt_i2o_quiesce_hba(pHba);
>     adpt_i2o_delete_hba(pHba);
>     scsi_unregister(host);
>     return 0;
> }
>
> This is used to release the host, now read the comment, and then the
> line just before the return.  This line was added by the patch, which
> also commented out the quiesce line.  Is it possible to get any
> confirmation on how this is supposed to function?
>
> Jaco
>
> ===========================================
> This message and attachments are subject to a disclaimer. Please refer
> to www.it.up.ac.za/documentation/governance/disclaimer/ for full
> details.
> Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig.
> Volledige besonderhede is by
> www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
> ===========================================
>
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: dm-crypt, new IV and standards

[dean gaudet]

On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:

> Well, CTR mode is not recommended for encrypted file systems because it is very
> easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> If we add a MAC, then any mode of operation except ECB can be used for
> encrypted file systems.

what does "easy to corrupt" mean?  i haven't really seen disks generate
bit errors ever.  this MAC means you'll need to write integrity data for
every real write.  that really doesn't seem worth it...

it seems like a block is either right, or it isn't -- the only thing the
MAC is telling you is that the block isn't right... it doesn't tell you
how to fix it.  that's a total waste of write bandwidth -- you might as
well return the bogus decrypted block.


> [3] Why not use IV == block number or IV == firstIV + block number?
> Certain modes of operation (like CTR) begin to leak information about the
> plaintext if you ever use the same Key-IV pair for your data.
> The IV will need to be updated every time you update the block.
> The IV generation does need not be from a cryptographicly strong PRNG,
> it need only be different from the previous IV.
> So incrementing the IV by 1 mod 2^128 every time you write to the block will
> suffice.

is CTR the only mode which is weak with simple IV / block number
relationships?

if you absolutely need this IV update for every write then you should
consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
grouped near their data blocks, to reduce seek overhead.

i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
IV+MAC, followed by 15 data...

-dean

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Wed, Mar 03, 2004 at 12:35:07AM -0800, dean gaudet wrote:
> On Sat, 21 Feb 2004, Jean-Luc Cooke wrote:
> 
> > Well, CTR mode is not recommended for encrypted file systems because it is very
> > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > If we add a MAC, then any mode of operation except ECB can be used for
> > encrypted file systems.
> 
> what does "easy to corrupt" mean?  i haven't really seen disks generate
> bit errors ever.  this MAC means you'll need to write integrity data for
> every real write.  that really doesn't seem worth it...

The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
attacker knew enough about the layout of the filesystem (modify times on blocks,
etc) they could flip a single bit and change your $1Mil purchase order
approved by your boss to a $8Mil order.

Extraneous example to be sure.  But this is why you want MACs.  CBC mode is
more difficult to tamper with, but not immune.

> it seems like a block is either right, or it isn't -- the only thing the
> MAC is telling you is that the block isn't right... it doesn't tell you
> how to fix it.  that's a total waste of write bandwidth -- you might as
> well return the bogus decrypted block.

A block cipher can be viewed as a huge lookup table.  Converting a 128 bit
block of data (in the case of AES) into another using a single key as the
rule-set for this transformation.  This alone is not secure (think of the
attacks on ECB which does exactly this for all your data).  That's why we
have 6 modes of operation in common use in the industry.

ECB, CBC : block-mode
CFB, OFB : stream-moe
CTR      : block- and/mode stream-mode
OMAC     : 128bit keyed Message Authentication Code
CCM      : CTR + CBC-MAC defined by IEEE 802.11i 

> > [3] Why not use IV == block number or IV == firstIV + block number?
> > Certain modes of operation (like CTR) begin to leak information about the
> > plaintext if you ever use the same Key-IV pair for your data.
> > The IV will need to be updated every time you update the block.
> > The IV generation does need not be from a cryptographicly strong PRNG,
> > it need only be different from the previous IV.
> > So incrementing the IV by 1 mod 2^128 every time you write to the block will
> > suffice.
> 
> is CTR the only mode which is weak with simple IV / block number
> relationships?

CTR, ECB, and CFB are vulnerable.

> if you absolutely need this IV update for every write then you should
> consider a disk layout which mixes IV (or IV+MAC) blocks so that they are
> grouped near their data blocks, to reduce seek overhead.
> 
> i.e. 1 block containing 15 IV+MAC, followed by 15 data blocks, followed by
> IV+MAC, followed by 15 data...

CBC mode doesn't absolutely need macs.  But the IV changes *are* required for
all modes of operation. Christophe and I's scheme of IV = firstIV + blockNum
for initial setup and IV = IV + 2^64 for IV updates will work fine as long as
there are less then 2^(128-64) block in the file system and less then 2^64
updates to any one block.  This scheme will keep CBC, OFB, CTR, and CCM modes
secure from eavesdropping but not Necessarily^[[1~^[[1~ from tampering.

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[David Wagner]

Jean-Luc Cooke  wrote:
>Christophe and I's scheme of IV = firstIV + blockNum
>for initial setup and IV = IV + 2^64 for IV updates will work fine

That's not ideal.  I'd suggest IV = HMAC_k(firstIV, blockNum) or somesuch.
Sequential IV's aren't a good choice with CBC -- they can leak a little
bit of information about the first block of plaintext, in some cases.

Re: dm-crypt, new IV and standards

[dean gaudet]

On Wed, 3 Mar 2004, Jean-Luc Cooke wrote:

> The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
> attacker knew enough about the layout of the filesystem (modify times on blocks,
> etc) they could flip a single bit and change your $1Mil purchase order
> approved by your boss to a $8Mil order.

ah ok i was completely ignoring the desire to prevent data tampering.

you have to admit it's still a bit more effort than flipping 1 bit like
you suggest since you need to tweak the encrypted data enough so that the
decrypted data has only 1 bit flipped.  (especially if you use CBC like
you mention.)

something else which i've been wondering about -- would there be any extra
protection provided by permuting block addresses so that the location of
wellknown blocks such as the superblock and inode maps aren't so
immediately obvious?  given the lack of known plaintext attacks on AES i'm
thinking there's no point to permuting, but i'm not a cryptographer, i
only know enough to be dangerous.  (you'd want to choose a permutation
which makes some effort to group blocks into large enough chunks so that
*some* seek locality can be maintained.)

-dean

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Wed, Mar 03, 2004 at 05:48:46PM -0800, dean gaudet wrote:
> On Wed, 3 Mar 2004, Jean-Luc Cooke wrote:
> 
> > The difference between "$1,000,000" and "$8,000,000" is 1 bit.  If an
> > attacker knew enough about the layout of the filesystem (modify times on blocks,
> > etc) they could flip a single bit and change your $1Mil purchase order
> > approved by your boss to a $8Mil order.
> 
> ah ok i was completely ignoring the desire to prevent data tampering.
> 
> you have to admit it's still a bit more effort than flipping 1 bit like
> you suggest since you need to tweak the encrypted data enough so that the
> decrypted data has only 1 bit flipped.  (especially if you use CBC like
> you mention.)
> 
> something else which i've been wondering about -- would there be any extra
> protection provided by permuting block addresses so that the location of
> wellknown blocks such as the superblock and inode maps aren't so
> immediately obvious?  given the lack of known plaintext attacks on AES i'm
> thinking there's no point to permuting, but i'm not a cryptographer, i
> only know enough to be dangerous.  (you'd want to choose a permutation
> which makes some effort to group blocks into large enough chunks so that
> *some* seek locality can be maintained.)

I think there is not value in "security though obscurity" when you're
developing an open source application.  :)

Like you said, CBC is not trivial to temper with - though it is do able.  CTR
is trivial on the other hand.  Which is why NIST and every cryptographer will
recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
compute the N+1-th block without needing to know the output from the N-th
block, so there is the possibility for very high parallelizum).

JLC

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

Re: dm-crypt, new IV and standards

[Pavel Machek]

Hi!

> > > Well, CTR mode is not recommended for encrypted file systems because it is very
> > > easy to corrupt single bits, bytes, blocks, etc without an integrity check.
> > > If we add a MAC, then any mode of operation except ECB can be used for
> > > encrypted file systems.
> > 
> > what does "easy to corrupt" mean?  i haven't really seen disks generate
> > bit errors ever.  this MAC means you'll need to write integrity data for
> > every real write.  that really doesn't seem worth it...
> 
> The difference between "_1,000,000" and "_8,000,000" is 1 bit.  If an
> attacker knew enough about the layout of the filesystem (modify times on blocks,
> etc) they could flip a single bit and change your _1Mil purchase order
> approved by your boss to a _8Mil order.

Hmm... long time ago I created crc loop device to catch
faulty disks. If cryptoloop can do that for me... very good!
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: dm-crypt, new IV and standards

[David Wagner]

Jean-Luc Cooke  wrote:
>Like you said, CBC is not trivial to temper with - though it is do able.  CTR
>is trivial on the other hand.  Which is why NIST and every cryptographer will
>recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
>compute the N+1-th block without needing to know the output from the N-th
>block, so there is the possibility for very high parallelizum).

I'm worried about the potential for confusion, so let me clarify: Good
cryptographers will recommend using a MAC, whether you use CTR, CBC,
or CFB.  The need for a MAC is not specific to CTR; CBC is not exempt.

Re: dm-crypt, new IV and standards

[dean gaudet]

On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:

> recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
> compute the N+1-th block without needing to know the output from the N-th
> block, so there is the possibility for very high parallelizum).

for disk crypto there are other opportunities for parallelism using
bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
<http://www.cs.utexas.edu/users/atri/papers/spaa.ps>).  there's a
latency/throughput tradeoff though...

-dean

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

On Thu, Mar 04, 2004 at 05:19:26PM -0800, dean gaudet wrote:
> On Thu, 4 Mar 2004, Jean-Luc Cooke wrote:
> 
> > recommend using a MAC with CTR.  (Why still have CTR?  Unlike CBC, you can
> > compute the N+1-th block without needing to know the output from the N-th
> > block, so there is the possibility for very high parallelizum).
> 
> for disk crypto there are other opportunities for parallelism using
> bitslicing to encrypt/decrypt multiple blocks in parallel (for example see
> <http://www.cs.utexas.edu/users/atri/papers/spaa.ps>).  there's a
> latency/throughput tradeoff though...

Humm.  Though AES uses GF's a lot, I think on 32bit processors bit slicing
AES just isn't worth it.

Though 512 byte fs blocks would only take 16 "transforms".  It's really hard
to implement ShiftRow() in bitwise SIMD...and x86 cpus simply don't have
enough registers (aliased or otherwise) to do this I think.  Fun read though!

JLC - bit-slicing MD5() will not improve things either, tried that for MD5CRK

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6

DM for detecting bad disks was: dm-crypt, new IV and standards

[Mike Fedyk]

Pavel Machek wrote:
> Hi!
> 
> 
>>>>Well, CTR mode is not recommended for encrypted file systems because it is very
>>>>easy to corrupt single bits, bytes, blocks, etc without an integrity check.
>>>>If we add a MAC, then any mode of operation except ECB can be used for
>>>>encrypted file systems.
>>>
>>>what does "easy to corrupt" mean?  i haven't really seen disks generate
>>>bit errors ever.  this MAC means you'll need to write integrity data for
>>>every real write.  that really doesn't seem worth it...
>>
>>The difference between "_1,000,000" and "_8,000,000" is 1 bit.  If an
>>attacker knew enough about the layout of the filesystem (modify times on blocks,
>>etc) they could flip a single bit and change your _1Mil purchase order
>>approved by your boss to a _8Mil order.
> 
> 
> Hmm... long time ago I created crc loop device to catch
> faulty disks. If cryptoloop can do that for me... very good!

Yes, a crc, or some other very low overhead DM target would be great for 
this.  I haven't looked at DM too much. :( Does it already have 
something like this already?

Re: dm-crypt, new IV and standards

[Jean-Luc Cooke]

Agreed.  Good catch David.

JLC

On Wed, Mar 03, 2004 at 09:40:05PM +0000, David Wagner wrote:
> Jean-Luc Cooke  wrote:
> >Christophe and I's scheme of IV = firstIV + blockNum
> >for initial setup and IV = IV + 2^64 for IV updates will work fine
> 
> That's not ideal.  I'd suggest IV = HMAC_k(firstIV, blockNum) or somesuch.
> Sequential IV's aren't a good choice with CBC -- they can leak a little
> bit of information about the first block of plaintext, in some cases.

-- 
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6